8 ms·

The web is a harsh manager

75 points by headalgorithm 4y ago

DerekBickerton 4y ago
Or in other words, this is piling complexity on top of complexity on top of complexity, on top of various abstractions.
- jerf 4y ago
  I think one of the reasons I like working on the backend more is that every once in a while, you get to do a clean sweep and throw away layers of abstraction. You can work on some app with Ruby on Rails and then load librarys on top of that and then load libraries on top of those that monkeypatch the original libraries... but nothing stops you from grabbing one particular critical API call and reimplementing it in a raw http.Handler in Go that spews simple SQL straight to your DB, sweeping away half-a-dozen layers of abstraction in one fell swoop, or whatever similar story you like to tell. The backend's responsibility ends with delivering the correct bytes in response to some HTTP message and it doesn't matter how you get there. The frontend... well... the equivalent is technically there, if you are willing and able to work with the grain of the browser. When I'm left to my own devices I can successfully front-end a lot of things with just some basic Javascript and some simple HTML. But it doesn't tend to scale, and it really doesn't scale if you've got some manager who loves that prototype of the calendar selector you did (that was just the browser widget), but really needs these three bullet points that are impossible to do with the native widget so now you're pulling in a library to provide a framework that provides the backbone of the actual widget that does the job and there's simply no other practical alternative because, what, are you going to spend six weeks implementing it yourself instead? No. Of course not. It's not that the front end never drops a layer of abstraction. jQuery was pretty successfully dropped, to cite one specific example. But you don't ever get that clean sweep, because that's just... too clean a sweep to satisfy any manager or designer.
  - zerocrates 4y ago
    I think the basic issue is that we're neither implementing new widespread patterns in the browser (new widgets, elements, etc.) nor really making it so we provide lower-level building blocks for interaction. Where we did add elements (like the calendar for example) they're so broadly specified that the browsers disagree on them so much you'll find yourself hard-pressed to actually use them. I think type=email is the only "new" element that is uncontroversially useful. You mostly have the "free" decades-old elements, and when you step a toe beyond them you're incurring a huge amount of work to try to emulate what the browser was giving you, or probably a library or framework to do it. On the very simplest end, I'm still baffled that there's no combobox element. `datalist` is kind of a mess and isn't quite the same.
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 ago
  This. 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.
brundolf 4y ago
> the unending list of topics to learn and the vast swings of urgent demands puts you in a state of constant stress and reinvention At least all these tasks use (mostly) the same tools, and stick to the same (couple of) languages. A full-stack workflow usually adds an entirely different set of tooling and languages, and then DevOps adds an entirely different set of tooling, languages, concerns, domain, and mindset.
pclmulqdq 4y ago
I am a systems programmer with very little experience writing html, but I have written some very basic frontends for a blog and a startup website. What real web developers can do with the tooling they have is amazing. There is a gigantic mountain of abstractions here, and they almost feel arbitrary, but when you read about them, you learn that each absurdly general tool was put into a standard or a framework to do a specific thing. To me, web development feels about the same as the time I made a processor in minecraft: you have so many weird and arbitrary constraints placed on you by the framework of HTML + CSS (let alone adding a JS framework), and then on top of that you have n + 1 different tools and methodologies to do the same thing, each of which has subtle tradeoffs. It amazes me that anyone can actually develop code in that environment!
cutler 4y ago
> What’s one change we could make to eliminate 80% of the work? Hotwire/Turbolinks or its equivalent.
iamcrazyyounus 4y ago
It's a good point. I'm not sure if I ever internalized it completely. For example, "You believe in design, and you're paying for it, but you are not getting your money's worth because of the gap between engineering and design," could be used in a compelling PowerPoint presentation for a C-level audience. I've definitely seen it. It's comparable to a restaurant that pays people to find and buy sushi-grade fish because they believe in doing so, but it turns out that the cook is simply deep frying it without anyone seeing it. Shame. The knowledge of and distribution of talent are out of sync.
- hyperman1 4y ago
  My first reaction is: This will never work. A C-level PowerPoint needs a problem statement AND a clear action AND estimates of timings, money, people, in simple words, everything in tiny baby steps. Without action, it's just underlings complaining. With action, they say make it so and come back a few months later and ask what the results are in simple terms of time and money. But this is a strange reaction. I claim to think that people will solve things if they understand the problem. What makes the suits different? Somehow, I excluded the execs from actual peoplehood. They are out there, making ignorable sounds like a radio, or doing random damage to infrastructure like a bad storm, but always without any real thinking going on. A bit like Eliza. Spending their time doing political feuds against other execs. Gathering more underlings or budget. Reorganizing people to other random corners of the buildings. Eating big dinners while talking to other execs. Creating a new C-suite job for someone they like. Oh well, I'm probably cliche level wrong. Or maybe the AI people should target exec-level consciousness as a stepping stone to real-people consciousness ;-)
  - 20after4 4y ago
    It's because c-level management jobs are largely occupied by psychopaths and narcissists.
soulofmischief 4y ago
I understand the increased complexity is nauseating and churning out an awful lot of really narrow developers, but I will be honest... All of the bullet points listed are why I enjoy web development. I am able to amass a seemingly unbounded amount of knowledge, work on an unbounded number of interesting, varied problems, and have the blessing of being compensated appropriately for my investment in myself. Modern web development is, within all this complexity, an open door to anywhere in the world for those with patience. I didn't even want to be a web developer when I was young. I wanted to be a game developer. Complexities and salaries were somewhat equivalent back then. Then around 2015 it became clear that web development was becoming a cutting-edge marriage of a wealth of amazing technologies and applications. I really love being a part of this industry, whether or not I despise 80% of it.
- qudat 4y ago
  Same, and I wrote a blog article about it because front end development has a lot of unique challenges. https://erock.prose.sh/my-love-letter-to-front-end-web-development https://erock.prose.sh/my-love-letter-to-front-end-web-devel...
  - soulofmischief 4y ago
    I enjoyed your article, thanks for sharing. > Modern javascript code is compiled and that's not going away anytime soon Absolutely, I think most opponents of this change in the workflow have failed to understand the requirements being placed on developers to push a cutting-edge, performant and platform-neutral service ecosystem.
  - aragilar 4y ago
    I agree the need to keep things small is a key part of front-end tooling, but it is worth noting that the choice by the ecosystem to effectively statically link everything (vs having a versioned stdlib which could be cached in a privacy-preserving way) does mean that sometimes size is traded off in detrimental-to-user ways (e.g. dropping support for older/unpopular browsers ASAP, worse implementations are chosen over better ones due to file size). I do wonder what's going to happen with the use of WASM, I doubt it's going to produce libraries any smaller than ELF, so are people going to try and use caching tools like indexeddb to avoid repeated downloads (and is that the next key bit of tooling to arrive), or are we going to burn our mobile data just so people can avoid building native apps? As a side note, I find the numpy comment quite interesting: I'm guessing the ~30MB is based on the wheel? It looks to me (based on the size of numpy in Debian) that ~1/2 of that is shared libraries (e.g. BLAS) which isn't part of numpy. There's also things like: f2py (which helps wrap Fortran libs for use in python), which is just over 1MB; tests including test data, which looks to be about ~5MB; and SIMD support which is almost 2MB. I suspect there's other things you could strip out which would make the size smaller to make things more comparable to front-end work (I've noticed on shared systems that the size of people's conda installs is comparable to my container with a full dev environment, both doing similar things with python). I do think you'd struggle to get it under a few MBs though, as for comparison the FFTW shared lib on my system alone is 2.1MB (with the static one sitting at 4.3MB), and I'd be concerned if there was a different FFT codebase which was much smaller than that (as you'd start wondering what's been left out/incorrectly implemented).
5350-uiop-1130 4y ago
it's pretty stark for me: in 2010: > pull files from ftp or visual source safe > edit html/css files > upload ...then jquery came, helped normalise js cross browser. then sass, and simple build tools like gulp which i found useful and easy to manage. in 2022: > install git > setup git credentials > install node > install npm, yarn, npx....probably missing other package managers > run npm install > it fails for obscure reasons: deprecated packages, missing packages, incompatible node versions etc etc > try to fix all the myriad npm issues > npm install > npm run dev: failed docker not found... > install docker: cannot install > sudo install docker > not on sudoers list will be reported > create IT ticket for sudo access > 2 days later, install docker > run npm dev > make the edit > commit failed, you are 10 commits behind > try to merge, cannot automatically merge this is just a contrived example of all the added stuff we have to deal with which is NOT directly a part of what i need to do, edit some css or html or maybe tweak some js. javascript has completely changed the meaning of front-end. front end is really full stack javascript developer who can also build responsive for almost unlimited browsers/os's....whilst also being good at js/react/vue/redux state management performance and building fancy animations and transitions with css/svg, accessibility, typography....on and on it is a lot...the work itself might not be so hard based on your own exp, but the expecations on us are very high.
- bryanrasmussen 4y ago
  > install git > setup git credentials pretty much every developer job requires this nowadays, but of course the setup git credentials is often more complicated today than it was a few years ago with generate new ssh key and write in form field.
  - fragmede 4y ago
    which, it really shouldn't be. Developers on GitHub have keys at https://github.com/<username>.keys https://github.com/<username>.keys, so I just add that to my server in the right places and new developers are off to the code mines (next to me).
- hyperman1 4y ago
  Isn't this mostly self-inflicted, though. The 2010 way works just as well today. * npm as a tool, sorry, it sucks. You got to replace all other languages with javascript, live with the consequences of that choice. * libraries/packages/... are easy to add but hard to maintain. Extremely fine-grained packages with no culture of long-term stability make this a lot worse. * I'd rather have git complain about a merge than spend time finding out which of file.html, file_old.html, file2.html file_new.html , ... are in use. Lucky you if only 1 file is the answer. * The whole 'programmers want to install tooling but the sysadmins wont let them' story goes back to at least the '80 ies. Devs on unix installed software in their home folder instead of letting responsible sysadmins install it system-wide (when the sysadmin has time and can be convinced it is usefull).
MobiusHorizons 4y ago
The linked article lists a lot of jobs that a frontend developer may be asked to do. Many sites certainly have all of those, but it is not realistic to say that every frontend developer is expected to know how to do all of these. (honestly these days I'm happy if a frontend developer actually knows what a DOM node is). But it is certainly true that Frontend development is complicated, and often under-appreciated. IME, the person doing a final integration is always the person who has to deal with all the miscommunication that has accumulated over the project. This is true in all fields I am aware of. Frontend development typically fills this role, because the flaws in the design of the data layer, or the miscommunications between the business stakeholder and the designer are typically invisible until someone actually tries to integrate it end to end. Actually delivering a good user experience in a reasonable amount of time while identifying and mitigating these hurdles is very challenging, and can be taken for granted especially if you end up doing a good job at it. IME the items listed in the article do happen to some people some times, but are much less fundamental than the general integration problem.
- bryanrasmussen 4y ago
  >(honestly these days I'm happy if a frontend developer actually knows what a DOM node is). ok but if they don't it's probably because they know the difference between Yeoman, Gulp, Webpack and probably one of the newer ones.
5350-uiop-1130 4y ago
i think ultimately what drives the churn in javascript are business needs. selling more things, and reducing costs. node is a product of reducing server cost by offloading the app onto the user. this is why your browser tab is using 5gb of ram. spa are also part of this race to have the most attractive and fluid experience for the customer, and to cut on costs by having a single web app that can function on many different platforms. and having all these build tools to reduce file sizes to save on hosting delivery costs. so i dont think its so much a technical issue as it is one driven by business needs. this is the main issue. all this innovation in js has raised the level of expectation to a level that the language/platform itself was never design to accomodate. and now we are stuck with this mess for the forseeable future.
Existenceblinks 4y ago
Within 10 years, I've never worked on frontend-only nor backend-only. My responsibility is the same because I don't introduce unnecessary complexity. All team members can do anything, one could do better than the other. Don't open pull request for too long, that's only problem, otherwise no problems at all.
bryanrasmussen 4y ago
I'm not sure, in most places I've worked there are multiple people doing these things and some of the parts, like understanding accessibility rules is left to one person to handle, so there is some minor separation of tasks.
- mxuribe 4y ago
  I think you might have worked in good places then. Kudos, and I'm jealous! :-) Wherever i have worked, there has been a constant corporate push to squeeze the least amount of people to work on "web stuff"...and of course such "web teams" need to have several (high-paying) Chiefs leading them, who merely direct orders at the "web team". /sigh

75 points by headalgorithm 4y ago

DerekBickerton 4y ago

Or in other words, this is piling complexity on top of complexity on top of complexity, on top of various abstractions.

jerf 4y ago
I think one of the reasons I like working on the backend more is that every once in a while, you get to do a clean sweep and throw away layers of abstraction. You can work on some app with Ruby on Rails and then load librarys on top of that and then load libraries on top of those that monkeypatch the original libraries... but nothing stops you from grabbing one particular critical API call and reimplementing it in a raw http.Handler in Go that spews simple SQL straight to your DB, sweeping away half-a-dozen layers of abstraction in one fell swoop, or whatever similar story you like to tell. The backend's responsibility ends with delivering the correct bytes in response to some HTTP message and it doesn't matter how you get there. The frontend... well... the equivalent is technically there, if you are willing and able to work with the grain of the browser. When I'm left to my own devices I can successfully front-end a lot of things with just some basic Javascript and some simple HTML. But it doesn't tend to scale, and it really doesn't scale if you've got some manager who loves that prototype of the calendar selector you did (that was just the browser widget), but really needs these three bullet points that are impossible to do with the native widget so now you're pulling in a library to provide a framework that provides the backbone of the actual widget that does the job and there's simply no other practical alternative because, what, are you going to spend six weeks implementing it yourself instead? No. Of course not. It's not that the front end never drops a layer of abstraction. jQuery was pretty successfully dropped, to cite one specific example. But you don't ever get that clean sweep, because that's just... too clean a sweep to satisfy any manager or designer.
- zerocrates 4y ago
  I think the basic issue is that we're neither implementing new widespread patterns in the browser (new widgets, elements, etc.) nor really making it so we provide lower-level building blocks for interaction. Where we did add elements (like the calendar for example) they're so broadly specified that the browsers disagree on them so much you'll find yourself hard-pressed to actually use them. I think type=email is the only "new" element that is uncontroversially useful. You mostly have the "free" decades-old elements, and when you step a toe beyond them you're incurring a huge amount of work to try to emulate what the browser was giving you, or probably a library or framework to do it. On the very simplest end, I'm still baffled that there's no combobox element. `datalist` is kind of a mess and isn't quite the same.

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 ago
This. 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.

brundolf 4y ago

> the unending list of topics to learn and the vast swings of urgent demands puts you in a state of constant stress and reinvention At least all these tasks use (mostly) the same tools, and stick to the same (couple of) languages. A full-stack workflow usually adds an entirely different set of tooling and languages, and then DevOps adds an entirely different set of tooling, languages, concerns, domain, and mindset.

pclmulqdq 4y ago

I am a systems programmer with very little experience writing html, but I have written some very basic frontends for a blog and a startup website. What real web developers can do with the tooling they have is amazing. There is a gigantic mountain of abstractions here, and they almost feel arbitrary, but when you read about them, you learn that each absurdly general tool was put into a standard or a framework to do a specific thing. To me, web development feels about the same as the time I made a processor in minecraft: you have so many weird and arbitrary constraints placed on you by the framework of HTML + CSS (let alone adding a JS framework), and then on top of that you have n + 1 different tools and methodologies to do the same thing, each of which has subtle tradeoffs. It amazes me that anyone can actually develop code in that environment!

cutler 4y ago

> What’s one change we could make to eliminate 80% of the work? Hotwire/Turbolinks or its equivalent.

iamcrazyyounus 4y ago

It's a good point. I'm not sure if I ever internalized it completely. For example, "You believe in design, and you're paying for it, but you are not getting your money's worth because of the gap between engineering and design," could be used in a compelling PowerPoint presentation for a C-level audience. I've definitely seen it. It's comparable to a restaurant that pays people to find and buy sushi-grade fish because they believe in doing so, but it turns out that the cook is simply deep frying it without anyone seeing it. Shame. The knowledge of and distribution of talent are out of sync.

hyperman1 4y ago
My first reaction is: This will never work. A C-level PowerPoint needs a problem statement AND a clear action AND estimates of timings, money, people, in simple words, everything in tiny baby steps. Without action, it's just underlings complaining. With action, they say make it so and come back a few months later and ask what the results are in simple terms of time and money. But this is a strange reaction. I claim to think that people will solve things if they understand the problem. What makes the suits different? Somehow, I excluded the execs from actual peoplehood. They are out there, making ignorable sounds like a radio, or doing random damage to infrastructure like a bad storm, but always without any real thinking going on. A bit like Eliza. Spending their time doing political feuds against other execs. Gathering more underlings or budget. Reorganizing people to other random corners of the buildings. Eating big dinners while talking to other execs. Creating a new C-suite job for someone they like. Oh well, I'm probably cliche level wrong. Or maybe the AI people should target exec-level consciousness as a stepping stone to real-people consciousness ;-)
- 20after4 4y ago
  It's because c-level management jobs are largely occupied by psychopaths and narcissists.

soulofmischief 4y ago

I understand the increased complexity is nauseating and churning out an awful lot of really narrow developers, but I will be honest... All of the bullet points listed are why I enjoy web development. I am able to amass a seemingly unbounded amount of knowledge, work on an unbounded number of interesting, varied problems, and have the blessing of being compensated appropriately for my investment in myself. Modern web development is, within all this complexity, an open door to anywhere in the world for those with patience. I didn't even want to be a web developer when I was young. I wanted to be a game developer. Complexities and salaries were somewhat equivalent back then. Then around 2015 it became clear that web development was becoming a cutting-edge marriage of a wealth of amazing technologies and applications. I really love being a part of this industry, whether or not I despise 80% of it.

qudat 4y ago
Same, and I wrote a blog article about it because front end development has a lot of unique challenges. https://erock.prose.sh/my-love-letter-to-front-end-web-development https://erock.prose.sh/my-love-letter-to-front-end-web-devel...
- soulofmischief 4y ago
  I enjoyed your article, thanks for sharing. > Modern javascript code is compiled and that's not going away anytime soon Absolutely, I think most opponents of this change in the workflow have failed to understand the requirements being placed on developers to push a cutting-edge, performant and platform-neutral service ecosystem.
- aragilar 4y ago
  I agree the need to keep things small is a key part of front-end tooling, but it is worth noting that the choice by the ecosystem to effectively statically link everything (vs having a versioned stdlib which could be cached in a privacy-preserving way) does mean that sometimes size is traded off in detrimental-to-user ways (e.g. dropping support for older/unpopular browsers ASAP, worse implementations are chosen over better ones due to file size). I do wonder what's going to happen with the use of WASM, I doubt it's going to produce libraries any smaller than ELF, so are people going to try and use caching tools like indexeddb to avoid repeated downloads (and is that the next key bit of tooling to arrive), or are we going to burn our mobile data just so people can avoid building native apps? As a side note, I find the numpy comment quite interesting: I'm guessing the ~30MB is based on the wheel? It looks to me (based on the size of numpy in Debian) that ~1/2 of that is shared libraries (e.g. BLAS) which isn't part of numpy. There's also things like: f2py (which helps wrap Fortran libs for use in python), which is just over 1MB; tests including test data, which looks to be about ~5MB; and SIMD support which is almost 2MB. I suspect there's other things you could strip out which would make the size smaller to make things more comparable to front-end work (I've noticed on shared systems that the size of people's conda installs is comparable to my container with a full dev environment, both doing similar things with python). I do think you'd struggle to get it under a few MBs though, as for comparison the FFTW shared lib on my system alone is 2.1MB (with the static one sitting at 4.3MB), and I'd be concerned if there was a different FFT codebase which was much smaller than that (as you'd start wondering what's been left out/incorrectly implemented).

5350-uiop-1130 4y ago

it's pretty stark for me: in 2010: > pull files from ftp or visual source safe > edit html/css files > upload ...then jquery came, helped normalise js cross browser. then sass, and simple build tools like gulp which i found useful and easy to manage. in 2022: > install git > setup git credentials > install node > install npm, yarn, npx....probably missing other package managers > run npm install > it fails for obscure reasons: deprecated packages, missing packages, incompatible node versions etc etc > try to fix all the myriad npm issues > npm install > npm run dev: failed docker not found... > install docker: cannot install > sudo install docker > not on sudoers list will be reported > create IT ticket for sudo access > 2 days later, install docker > run npm dev > make the edit > commit failed, you are 10 commits behind > try to merge, cannot automatically merge this is just a contrived example of all the added stuff we have to deal with which is NOT directly a part of what i need to do, edit some css or html or maybe tweak some js. javascript has completely changed the meaning of front-end. front end is really full stack javascript developer who can also build responsive for almost unlimited browsers/os's....whilst also being good at js/react/vue/redux state management performance and building fancy animations and transitions with css/svg, accessibility, typography....on and on it is a lot...the work itself might not be so hard based on your own exp, but the expecations on us are very high.

bryanrasmussen 4y ago
> install git > setup git credentials pretty much every developer job requires this nowadays, but of course the setup git credentials is often more complicated today than it was a few years ago with generate new ssh key and write in form field.
- fragmede 4y ago
  which, it really shouldn't be. Developers on GitHub have keys at https://github.com/<username>.keys https://github.com/<username>.keys, so I just add that to my server in the right places and new developers are off to the code mines (next to me).
hyperman1 4y ago
Isn't this mostly self-inflicted, though. The 2010 way works just as well today. * npm as a tool, sorry, it sucks. You got to replace all other languages with javascript, live with the consequences of that choice. * libraries/packages/... are easy to add but hard to maintain. Extremely fine-grained packages with no culture of long-term stability make this a lot worse. * I'd rather have git complain about a merge than spend time finding out which of file.html, file_old.html, file2.html file_new.html , ... are in use. Lucky you if only 1 file is the answer. * The whole 'programmers want to install tooling but the sysadmins wont let them' story goes back to at least the '80 ies. Devs on unix installed software in their home folder instead of letting responsible sysadmins install it system-wide (when the sysadmin has time and can be convinced it is usefull).

MobiusHorizons 4y ago

The linked article lists a lot of jobs that a frontend developer may be asked to do. Many sites certainly have all of those, but it is not realistic to say that every frontend developer is expected to know how to do all of these. (honestly these days I'm happy if a frontend developer actually knows what a DOM node is). But it is certainly true that Frontend development is complicated, and often under-appreciated. IME, the person doing a final integration is always the person who has to deal with all the miscommunication that has accumulated over the project. This is true in all fields I am aware of. Frontend development typically fills this role, because the flaws in the design of the data layer, or the miscommunications between the business stakeholder and the designer are typically invisible until someone actually tries to integrate it end to end. Actually delivering a good user experience in a reasonable amount of time while identifying and mitigating these hurdles is very challenging, and can be taken for granted especially if you end up doing a good job at it. IME the items listed in the article do happen to some people some times, but are much less fundamental than the general integration problem.

bryanrasmussen 4y ago
>(honestly these days I'm happy if a frontend developer actually knows what a DOM node is). ok but if they don't it's probably because they know the difference between Yeoman, Gulp, Webpack and probably one of the newer ones.

5350-uiop-1130 4y ago

i think ultimately what drives the churn in javascript are business needs. selling more things, and reducing costs. node is a product of reducing server cost by offloading the app onto the user. this is why your browser tab is using 5gb of ram. spa are also part of this race to have the most attractive and fluid experience for the customer, and to cut on costs by having a single web app that can function on many different platforms. and having all these build tools to reduce file sizes to save on hosting delivery costs. so i dont think its so much a technical issue as it is one driven by business needs. this is the main issue. all this innovation in js has raised the level of expectation to a level that the language/platform itself was never design to accomodate. and now we are stuck with this mess for the forseeable future.

Existenceblinks 4y ago

Within 10 years, I've never worked on frontend-only nor backend-only. My responsibility is the same because I don't introduce unnecessary complexity. All team members can do anything, one could do better than the other. Don't open pull request for too long, that's only problem, otherwise no problems at all.

bryanrasmussen 4y ago

I'm not sure, in most places I've worked there are multiple people doing these things and some of the parts, like understanding accessibility rules is left to one person to handle, so there is some minor separation of tasks.

mxuribe 4y ago
I think you might have worked in good places then. Kudos, and I'm jealous! :-) Wherever i have worked, there has been a constant corporate push to squeeze the least amount of people to work on "web stuff"...and of course such "web teams" need to have several (high-paying) Chiefs leading them, who merely direct orders at the "web team". /sigh