7 ms·
I am in the middle of writing a blog post that is similar to this. My post even also references The Great Divide. However, my conclusions are different. I thin
by dimmke 4y ago
I am in the middle of writing a blog post that is similar to this. My post even also references The Great Divide.
However, my conclusions are different. I think the main problem with front-end today is the complexity of the tooling and the lack of specification updates to implement successful concepts that would allow the removal of frameworks and tooling. I think many of the tasks he describes in this post would cease to exist entirely if we began focusing on implementing things directly into specs and aggressively sunsetting the use of frameworks and tooling.
We have to get away from everything is Javascript and an abstraction land. If a front-end developer didn't have to learn frameworks and how to debug Webpack configurations, they might have more bandwidth to learn how to write HTML properly.
I think he sets up kind of a straw man here. There are a lot of front-end developer roles that are just straightforward JavaScript programming with some domain specific knowledge of Web APIs and frameworks. Then there are front-end developer roles that include the more nuanced stuff he talks about, but I don't think there are a lot of companies plopping all of this disparate stuff into one person's lap.
The real problem is that in 2014-2015, Front-End Developer stopped meaning "A person with an eye for design and detail who can write clean markup and CSS and add some interactivity to a webpage with JavaScript" to "Classical software engineer who writes code in JavaScript". This transition happened because of the mass move to single page applications. But organizations still need people who can do what the previous incarnation of front-end developer did, even if they don't know it. They just don't have a standardized name for the role.
And as someone who has been both versions of front-end developer (I successfully transitioned when I saw the writing on the wall but one look at my personal site should tell you I'm of the old guard.) I think there is a possible version of Front-End Developer in the future that is somewhere in the middle. Truly balanced. Right now things are just too heavily weighted in one direction. I don't think the right move is to necessarily create a bunch of other roles. If that was going to catch on, I think it would have already.
- lucideer 4y agoThis. I hope you write your blogpost - I don't actually fully agree with your post entirely but my differings are only in the detail, the general thrust is right on point. > many of the tasks he describes in this post would cease to exist entirely if we began focusing on implementing things directly into specs and aggressively sunsetting the use of frameworks and tooling Nitpick: If you look at the tasks he describes one-by-one, this isn't really true as they're mostly spec/implementation domain/sdlc/ related, rather than framework/tooling apis. However... while he makes the list sound as complicated and insurmountable as possible, it isn't. These are mostly tasks I know how to do. And most are reasonably easy to know how to do. The problem is that FE devs don't learn these things, they expend their time gaining other much less portable / long-lasting knowledge (related to frameworks & tooling). The other sleight of hand the author pulls is listing way more tasks than one would ever have to do on one product or team - quite a few of them are niche insofar as most devs would leverage an abstraction library to provide them with generic versions of these features; building from first-principles would be a rarer special-case for narrowly domain-focused product teams.
- dimmke 4y ago>while he makes the list sound as complicated and insurmountable as possible, it isn't. This is a really great point, and ties into what I was saying. I made the transition when I had to. I am not a genius/wunderkind. I just sucked it up and did it. I have a hypothesis about this, actually. JavaScript used to really suck. Like, people don't even know who weren't around in the 2000s. It was not at all the language it is today. And there was no StackOverflow or Github or MDN with perfect documentation or coding bootcamps or Udemy courses or any of the other numerous resources on learning how to code. Your options were W3Schools and posting questions on the #javascript channel in Freenode IRC. I think a lot of people doing front-end development simply decided they just couldn't do "real" programming because the resources weren't there to assist them and they didn't have a normal CS background. I definitely had that idea in my head for a long time. The people who were decent at writing JavaScript in the 2000s were software engineers with computer science degrees who probably mostly wrote Java. And they were doing it holding their noses. When you look at people that had such an immense impact on how the look and feel of websites developed, like Jeffrey Zeldman and Chris Coyier. Those were just guys. They weren't software engineers. But they are hugely important figures that I worry will eventually be lost to time. He wants the other skills to be as highly valued as the programming skills - but they just aren't. You aren't going to get paid $250k a year to tighten up sloppy CSS. That CSS is probably CSS-in-JS shit anyways with a framework added to it like Tailwind. A lot of companies probably don't even realize what they lost in this transition. They perhaps weren't even cognizant of it happening. >I hope you write your blogpost Oh, it's for sure happening. I've sunk too much time into it. However, I'm going into extreme detail in several areas. It's more of a manifesto/conceptual framework I guess so it's taking a long time to put together.
- deleted 4y ago[deleted]
- quickthrower2 4y agoThe rate of change in computer tech is so fast: in terms of standards, paradigms, hardware capabilities and so on that I think any attempt to be really organised about it can be disrupted by other companies innovating. And there are so many platforms and languages to learn, in addition to the front end does it all. Probably you need more people whose role is “X that codes”. Designer that codes, SEO specialist that codes, etc. It matters less if they write any code on the job than they get what it is all about. Then they can have productive discussions with engineers. After all any concern that isn’t just straight coding feels like requirements analysis. People can specialize in this. You can have a marketing specialist who talks to coders and SEO and marketing team and can put together what is needed. But tech is dynamic and changing every 6 months so I think it comes with the territory. Not even a problem necessarily. If it is then the actual managers need to address it. It just comes down to skills, roles and responsibilities after all.
- agumonkey 4y agoThere are other issues with frontend and WebApps. No metalevel. We keep reinventing terminal features that can't be manipulated as objects (in the abstract sense, not java). Very often users are stuck with rest based flows and process that would be better if they could adapt / batch them on their own.
- solardev 4y agoFWIW I don't think the article was a strawman. That's always been my experience with smaller companies I started out writing HTML and CSS back in the late 90s, but the job has changed and grown so much since then. Two jobs ago, I had to do HTML + CSS plus Filemaker, AppleScript, Maria, Redis, Varnish, CDN, DNS, SMTP, SPF, and so much more. Two years later, at a new job, I still had to do much of that, then add in Drupal, Babel, Webpack, Docker, Figma, Illustrator, Imagick, Nginx, Parcel, GraphQL, React, Next, OpenLayers, Google Tag Manager, Data Studio, Analytics, and so much more. Two more years later, add in Typescript, Jest, Selenium, CI/CD, Miro, Bun, web workers, MapGL, WebAssembly, Ramda, REDUX, Rxjs, Redux Observables, React Router, Appcues... That's just one person, in half a decade. The ecosystem as a whole is even more complex. I think integrating useful things into the base Ecmascript would be a great start, but not the whole story. There is still a ton of dev ops, network admin, sys admin, email admin, graphic design, marketing, advertising, etc. crossover. Maybe huge tech companies have specialized roles, but smaller ones have tiny web teams that are expected to get the job done no matter how the technologies change. The devs can't even keep up with the tech, much less the managers or HR or execs. It's part of the fun, for now, but yeesh... I'm going to age out at some point, brain can't keep up much longer lol