My hot take has always been that the emergence of the Front-End Developer role came about backwards and that the correct expectation was that designers learn to code.
HTML & CSS seem a world apart from traditional programming (and computer science, etc.) and were initially much more about things that were the designer's realm--another tool for layout, format, hierarchy, etc. I remember so many frustrated PHP et al. devs who really didn't love writing HTML being thrilled when I would ask to contribute to the UI layer of a given CRUD app. I was happier doing it that way too (still am).
Javascript--especially before being engineered into its current oblivion--was fuzzier territory, but I'd advocate that it should be a shared responsibility between the designer and [back-end?] developer, meeting somewhere around accessing the API.
The ability to both design and implement the interaction layer of a website or application is a superpower and, on average, results in a higher-quality product. The current division of labor makes for weird silos and loading spinners everywhere that one layer of responsibility ends and the next begins.
Note that this is the path I took and prefer (dev who designs; designer who devs), which I suppose makes me both less-common and very biased towards it. :)
I agree. For a while now, I've been working on a programming language specifically for designers. The idea is to incorporate the same verbiage and mental models that designers use in their daily lives. I think html and css are nice, but they can't be transferred over to other platforms. Designers need a platform-agnostic language.
>HTML & CSS seem a world apart from traditional programming (and computer science, etc.) and were initially much more about things that were the designer's realm--another tool for layout, format, hierarchy, etc.
This was the problem. HTML was for a very specific idea about design and page layout but designers wanted more options then the primitives provided by HTML.
So to fix they created CSS. Then started endlessly tacking things onto CSS until it's the mess that it is today.
A well designed API happens in layers. You have pixel primitives at the bottom layer and then progressing higher and higher to textual and graphic design primitives at a top most layer. What we have in the front end world today is HTML at the bottom layer and pixels inside the canvas layer. The whole thing is duck taped together in ways that don't make sense.
HTML & CSS seem a world apart from traditional programming (and computer science, etc.) and were initially much more about things that were the designer's realm--another tool for layout, format, hierarchy, etc. I remember so many frustrated PHP et al. devs who really didn't love writing HTML being thrilled when I would ask to contribute to the UI layer of a given CRUD app. I was happier doing it that way too (still am).
Javascript--especially before being engineered into its current oblivion--was fuzzier territory, but I'd advocate that it should be a shared responsibility between the designer and [back-end?] developer, meeting somewhere around accessing the API.
The ability to both design and implement the interaction layer of a website or application is a superpower and, on average, results in a higher-quality product. The current division of labor makes for weird silos and loading spinners everywhere that one layer of responsibility ends and the next begins.
Note that this is the path I took and prefer (dev who designs; designer who devs), which I suppose makes me both less-common and very biased towards it. :)