4 ms·

> Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. It’s bananas. The thing is, it's totally possible, but i

by diggan 2y ago

> Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. It’s bananas. The thing is, it's totally possible, but it requires restraint and properly caring about what you pull into your project. Back in the vanilla JS/jQuery days, when I got started, our "dependency management" was basically copy-paste .js files into a `vendor/` directory. Then nodejs/npm appeared (and bower, which FE used before using npm), and suddenly the advice became to just not program those things yourself, download the module. But already at that point, a lot of us questioned the idea of owning thousands of hidden lines, rather than explicitly owning those, and outsourcing everything to volunteers who basically do FOSS for fun. Even today, it's possible to care about your project enough to not bloat the invisible parts too much, if you want to be able to continue to work on the project. Again, requires restraint, and going back to the "I only need a function from this library so instead of depending on the entire library, lets just copy-paste this function into our codebase and add some tests" way of dealing with minor things. So I guess what I'm ranting about, is that this is a people and process problem, not a JavaScript problem, because there are a lot of us JS developers who don't suffer from this problem, while large parts of the ecosystem does.

mplanchard 2y ago
I agree you can avoid it with care, but I do think it's a JavaScript problem, at least moreso than in other languages. The culture is one of acceptance of churn. It seems like everything from minor libraries to major frameworks is much more likely to introduce a breaking change in JS than in Rust, C++, or even python. I've never written any emacs lisp that I had to change when upgrading emacs, and the third-party libraries I use there also tend to deprecate things rarely and carefully. But, if we stop working on a JS codebase for more than a few months, there's a very real chance that it will no longer build with current tools or that an upgrade to fix e.g. a security vulnerability will turn into a gordian nightmare.
- schindlabua 2y ago
  And I think the Javascript problem exists because frontend/UI is just a very complicated domain, in the sense that frontend is a big messy ball of side effects. If you've been around and saw the web grow up, and saw all the new ideas all those libraries brought to the table (jQuery deferreds becoming async/await, 960 grid slowly morphing into flexbox and css grid, etc etc) then all the breaking changes make sense, we're still in a discovery stage in the frontend. Though now that I'm not doing much FE these days I get a feel for how frustrating it is to keep up to date. The current metaframeworks also solve interesting problems (that I'm not sure I had tbh) and no doubt new web standards will follow from them. But yeah if you're a new developer who doesn't have all those years of context it must be insanely confusing to swim in a sea of libraries and frameworks without having a good grip on the core web platform.
  - ajmurmann 2y ago
    It seems that in addition to the issue were some things were actually tedious to do, there has also always been a drive to wow users (or really other devs?) by doing something that pushes the boundaries of what's possible. Once someone has done it, everyone is expected to do it and now work is tedious again. A simple example is how back in 2009/10 everyone was all excited about rounded corners. You had to cut all these assets and got a more complex DOM but it became table stakes. So CSS got an attribute for this. Then we needed fancy grids everywhere and fourteenth elements on mobile which was tedious till frameworks did some of it. I think the wow-treadmill doesn't exist like this on the backend because nobody sees it. The closest equivalent is scaling your architecture for a level that your app will never need.
  - mplanchard 2y ago
    I’ve been writing JS since the PHP and jquery days, so I’m not unfamiliar. I understand these libraries are doing complex things, but they also seem to love churning for churn’s sake (react hooks is an example, svelte v5 is another, eslint entirely deprecating their old config format is yet another). I don’t mind learning or using a framework to do complicated things. I mind when the ecosystem as a whole makes it so much harder to get real work done and instead forces everyone to do busywork like switching tsconfig to eslint, then switching eslint config to the new flat format.
    - schindlabua 2y ago
      Hooks were great. But yeah eslint flat config is probably also better than the old format but we could have easily done without that breaking change you're right. The churn is part of why I try to do mostly backend these days, especially with the current state of tooling. Like when react came out it was immediately clear it was going to be a mainstay, I can't imagine nextjs in it's current form to be around in a few years because it's very terrible and I want the metaframework dust to settle a bit before diving back in.
- mablopoule 2y ago
  I don't think it's a Javascript problem in the sense that it's due to intrinsics properties of Front-end developpement, or of NPM, but I do agree that's in a cultural problem in the Javascript ecosystem, especially around React. My theory is that there was a perfect storm around 2015 where everyone and their dog was encouraged to learn to code, especially by going through a coding bootcamp where they were mainly taught Javascript and React. At the same time there was a general enthusiasm for Open-Source, and of using Github as a sort of alternative, better Linkedin in order to get your first job as a software engineer. As a result lots of silly packages were created (and used !) by well-meaning junior developers, who were told that coding is very simple but also fraught with peril, so if they are serious then they better should use packages such as 'is-odd' which is clearly more professional than doing it yourself, cause it follows the DRY principle and also get updated test by lots of people, etc...
  - wwweston 2y ago
    Probably not coincidentally, 2016 was the year that I decided I was done with front-end after about decade of focus.
  - pookha 2y ago
    LOL 2015 was a banner year for the trendy web-dev influencers...I can remember junior developers tripping over themselves trying to implement "flux" to handle some form input. Needlessly complex bullshit libraries got forced down everyone's throat because AngularJS was passe and React was "very mindful, very demure". Eventually flux became "redux", which I gather was a "state management" framework that ripped off a post graduate students custom niche language. And I want to say the redux kid's background was literally microsoft powerpoint scripting. Very surreal time in development.
    - bloomingkales 2y ago
      We need a Behind the Javascript VH1 show.
    - acemarke 2y ago
      FWIW, I'm the current Redux maintainer, and that is an absolutely horrible and unfair description of how Redux was created. Elm was _an_ influence on Redux, but there were many other influences as well. Dan Abramov's prior experience did include some VB (possibly VB.NET, I think), but also a lot of actual JS. See the actual "History of Redux" and "Prior Art" docs pages, and a couple of my blog posts, for an accurate description of the influences that led to Redux's creation: - https://redux.js.org/understanding/history-and-design/history-of-redux https://redux.js.org/understanding/history-and-design/histor... - https://redux.js.org/understanding/history-and-design/prior-art https://redux.js.org/understanding/history-and-design/prior-... - https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
- hombre_fatal 2y ago
  Well, you should compare the JS UI ecosystem to other UI ecosystems like Android and iOS, not ecosystems that run on one machine with no UI. Then you'd make a more sensible comparison like React versus something like SwiftUI which is constantly changing, constantly breaking, and still basically in beta mode for 10 years, yet it only runs on specific versions of Apple hardware and software. And usually it's so insufficient that you also build part of your app in UIKit/Cocoa in a completely different language. React is far more stable to build with and far less experimental. People who have never touched any UI tech until HTML/JS have no clue how good they have it, so they confuse universally hard things about UI tech with something that must be specific to JS, so they additionally assume it's so much better elsewhere. You should try updating a nontrivial SwiftUI app you made for the iPhone 11 to work on the iPhone 16. Not only have your libraries changed (not just topical ones, but the Promise library you used is defunct and everything now uses Combine and 2021 Swift async features, so you have to migrate all of your async code), but the platform itself doesn't have APIs that you were using anymore. That's not even a class of problem you deal with on browser tech.
  - porterehunley 2y ago
    This is strange to hear because I switched over to SwiftUI/Native from web-based(react native) because I was so frustrated with the JS UI ecosystem. I would be stuck for a long time from conflicting package dependencies after updating/adding a new library. JS seems like the only ecosystem where adding a few simple libraries results in hundreds of added packages.
  - wolvesechoes 2y ago
    "Well, you should compare the JS UI ecosystem to other UI ecosystems like Android and iOS, not ecosystems that run on one machine with no UI." "People who have never touched any UI tech until HTML/JS have no clue how good they have it" Tech like: - Delphi/Free Pascal, where usually code from 20 years ago compiles today with minor adjustments? - Qt, developed and maintained for over 30 years, currently at 6th major release? - Win32, and frameworks built on top of it like MFC, WinForms, WPF? Yeah, we are SO lucky we've got JS ecosystem. It is impossible to think how people lived without it.
- bloomingkales 2y ago
  People have a lot of opinions of javascript because it really is the Statue of Liberty. You really can know a subset of Algol and have portable apps in the browser asap. Well gosh darnit, then everyone and their mother is going to come to America It's an age old envy.
DanielHB 2y ago
> But already at that point, a lot of us questioned the idea of owning thousands of hidden lines, rather than explicitly owning those, and outsourcing everything to volunteers who basically do FOSS for fun. This is not quite accurate, the libraries you see the most complaints about are the most popular libraries around. OP specifically complained about Apollo which widely used and backed by a SasS service and VC money. React also deprecates APIs quite often (although they are usually the more obscure parts of the API, the widely used stuff doesn't get deprecated nearly as often). It gets worse when you add smaller libraries who do come from "volunteers who basically do FOSS for fun" because they often have peerDependencies with the big libraries but don't get updated as the big lib deprecates stuff.
- diggan 2y ago
  Yeah, fair enough, you're right, a lot of the churn is created by companies who do FOSS too. But I think the original point stands regardless of how popular the library is, or who is backing it. Just because Facebook today cares about React, doesn't mean I'd implicitly trust them to care about it for as long as I want to care about my own project, and I certainly don't trust their use cases to always match mine, and that's OK. I think what I was trying to get across is that "npm install lib" carries a far bigger cost than most people realize, just because it gets hidden behind "our code" while in reality, as soon as you include a library/framework into your own codebase, you need to see it as "our code" immediately.
  - DanielHB 2y ago
    I agree with you, but I think the liability of a dependency is FAR higher if it has a peerDependency to another dependency. For example, react-router has a peerDependency with react, therefor the liability of adding it to your project is much higher because you can have both of these scenarios: 1) Can't update react without updating react-router because react deprecated some API 2) Can't update react-router without updating react because the new version of react-router is using some new API from react And it drives me insane that people will just add react-random-small-thing from github handle @NotGoingToMaintainThis. These kinds of small dependencies with peerDependencies to core libs are the devil. I am not opposed to using dependencies, but your project needs to pick a few core dependencies and stick with them...
jaza 2y ago
I'm a back-end dev, I've avoided being paid to do any front-end work (and/or my bosses have avoided paying me to do any front-end work? hahaha) for getting on a decade now. So no doubt front-end devs will cringe at what I'm about to say (not that I care!). But for the occasional personal front-end stuff that I still do, my "dependency management" is just "copy-paste versioned CDN script tags / CSS link-rel tags into my index.html file". Which is equivalent to (but better than) old-skool copy-pasting into a "vendor" directory" (which of course I also did, back in the day). And my "front-end build system" is just "write vanilla javascript in .js files and include it un-minified un-typescripted un-anything via script tags". I've got better things to do in my spare time, than deal with npm / gulp / yarn / whatever they've invented this week.
julik 2y ago
At this point in time this is absolutely a "people and process" problem. But also the process that is there has been excercised and is known to folks you may hire. Trying to come up with less of it (or with a different version of it) dramatically shrinks the number of people who can be productive on your product from day 1, and is not a choice to be made lightly. There is also a number of people who will then be spending time convincing you that the "none" or "less" process you have imposed is wrong and you should "just get on with the program".

by diggan 2y ago

mplanchard 2y ago

I agree you can avoid it with care, but I do think it's a JavaScript problem, at least moreso than in other languages. The culture is one of acceptance of churn. It seems like everything from minor libraries to major frameworks is much more likely to introduce a breaking change in JS than in Rust, C++, or even python. I've never written any emacs lisp that I had to change when upgrading emacs, and the third-party libraries I use there also tend to deprecate things rarely and carefully. But, if we stop working on a JS codebase for more than a few months, there's a very real chance that it will no longer build with current tools or that an upgrade to fix e.g. a security vulnerability will turn into a gordian nightmare.

schindlabua 2y ago
And I think the Javascript problem exists because frontend/UI is just a very complicated domain, in the sense that frontend is a big messy ball of side effects. If you've been around and saw the web grow up, and saw all the new ideas all those libraries brought to the table (jQuery deferreds becoming async/await, 960 grid slowly morphing into flexbox and css grid, etc etc) then all the breaking changes make sense, we're still in a discovery stage in the frontend. Though now that I'm not doing much FE these days I get a feel for how frustrating it is to keep up to date. The current metaframeworks also solve interesting problems (that I'm not sure I had tbh) and no doubt new web standards will follow from them. But yeah if you're a new developer who doesn't have all those years of context it must be insanely confusing to swim in a sea of libraries and frameworks without having a good grip on the core web platform.
- ajmurmann 2y ago
  It seems that in addition to the issue were some things were actually tedious to do, there has also always been a drive to wow users (or really other devs?) by doing something that pushes the boundaries of what's possible. Once someone has done it, everyone is expected to do it and now work is tedious again. A simple example is how back in 2009/10 everyone was all excited about rounded corners. You had to cut all these assets and got a more complex DOM but it became table stakes. So CSS got an attribute for this. Then we needed fancy grids everywhere and fourteenth elements on mobile which was tedious till frameworks did some of it. I think the wow-treadmill doesn't exist like this on the backend because nobody sees it. The closest equivalent is scaling your architecture for a level that your app will never need.
- mplanchard 2y ago
  I’ve been writing JS since the PHP and jquery days, so I’m not unfamiliar. I understand these libraries are doing complex things, but they also seem to love churning for churn’s sake (react hooks is an example, svelte v5 is another, eslint entirely deprecating their old config format is yet another). I don’t mind learning or using a framework to do complicated things. I mind when the ecosystem as a whole makes it so much harder to get real work done and instead forces everyone to do busywork like switching tsconfig to eslint, then switching eslint config to the new flat format.
  - schindlabua 2y ago
    Hooks were great. But yeah eslint flat config is probably also better than the old format but we could have easily done without that breaking change you're right. The churn is part of why I try to do mostly backend these days, especially with the current state of tooling. Like when react came out it was immediately clear it was going to be a mainstay, I can't imagine nextjs in it's current form to be around in a few years because it's very terrible and I want the metaframework dust to settle a bit before diving back in.
mablopoule 2y ago
I don't think it's a Javascript problem in the sense that it's due to intrinsics properties of Front-end developpement, or of NPM, but I do agree that's in a cultural problem in the Javascript ecosystem, especially around React. My theory is that there was a perfect storm around 2015 where everyone and their dog was encouraged to learn to code, especially by going through a coding bootcamp where they were mainly taught Javascript and React. At the same time there was a general enthusiasm for Open-Source, and of using Github as a sort of alternative, better Linkedin in order to get your first job as a software engineer. As a result lots of silly packages were created (and used !) by well-meaning junior developers, who were told that coding is very simple but also fraught with peril, so if they are serious then they better should use packages such as 'is-odd' which is clearly more professional than doing it yourself, cause it follows the DRY principle and also get updated test by lots of people, etc...
- wwweston 2y ago
  Probably not coincidentally, 2016 was the year that I decided I was done with front-end after about decade of focus.
- pookha 2y ago
  LOL 2015 was a banner year for the trendy web-dev influencers...I can remember junior developers tripping over themselves trying to implement "flux" to handle some form input. Needlessly complex bullshit libraries got forced down everyone's throat because AngularJS was passe and React was "very mindful, very demure". Eventually flux became "redux", which I gather was a "state management" framework that ripped off a post graduate students custom niche language. And I want to say the redux kid's background was literally microsoft powerpoint scripting. Very surreal time in development.
  - bloomingkales 2y ago
    We need a Behind the Javascript VH1 show.
  - acemarke 2y ago
    FWIW, I'm the current Redux maintainer, and that is an absolutely horrible and unfair description of how Redux was created. Elm was _an_ influence on Redux, but there were many other influences as well. Dan Abramov's prior experience did include some VB (possibly VB.NET, I think), but also a lot of actual JS. See the actual "History of Redux" and "Prior Art" docs pages, and a couple of my blog posts, for an accurate description of the influences that led to Redux's creation: - https://redux.js.org/understanding/history-and-design/history-of-redux https://redux.js.org/understanding/history-and-design/histor... - https://redux.js.org/understanding/history-and-design/prior-art https://redux.js.org/understanding/history-and-design/prior-... - https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
hombre_fatal 2y ago
Well, you should compare the JS UI ecosystem to other UI ecosystems like Android and iOS, not ecosystems that run on one machine with no UI. Then you'd make a more sensible comparison like React versus something like SwiftUI which is constantly changing, constantly breaking, and still basically in beta mode for 10 years, yet it only runs on specific versions of Apple hardware and software. And usually it's so insufficient that you also build part of your app in UIKit/Cocoa in a completely different language. React is far more stable to build with and far less experimental. People who have never touched any UI tech until HTML/JS have no clue how good they have it, so they confuse universally hard things about UI tech with something that must be specific to JS, so they additionally assume it's so much better elsewhere. You should try updating a nontrivial SwiftUI app you made for the iPhone 11 to work on the iPhone 16. Not only have your libraries changed (not just topical ones, but the Promise library you used is defunct and everything now uses Combine and 2021 Swift async features, so you have to migrate all of your async code), but the platform itself doesn't have APIs that you were using anymore. That's not even a class of problem you deal with on browser tech.
- porterehunley 2y ago
  This is strange to hear because I switched over to SwiftUI/Native from web-based(react native) because I was so frustrated with the JS UI ecosystem. I would be stuck for a long time from conflicting package dependencies after updating/adding a new library. JS seems like the only ecosystem where adding a few simple libraries results in hundreds of added packages.
- wolvesechoes 2y ago
  "Well, you should compare the JS UI ecosystem to other UI ecosystems like Android and iOS, not ecosystems that run on one machine with no UI." "People who have never touched any UI tech until HTML/JS have no clue how good they have it" Tech like: - Delphi/Free Pascal, where usually code from 20 years ago compiles today with minor adjustments? - Qt, developed and maintained for over 30 years, currently at 6th major release? - Win32, and frameworks built on top of it like MFC, WinForms, WPF? Yeah, we are SO lucky we've got JS ecosystem. It is impossible to think how people lived without it.
bloomingkales 2y ago
People have a lot of opinions of javascript because it really is the Statue of Liberty. You really can know a subset of Algol and have portable apps in the browser asap. Well gosh darnit, then everyone and their mother is going to come to America It's an age old envy.

DanielHB 2y ago

> But already at that point, a lot of us questioned the idea of owning thousands of hidden lines, rather than explicitly owning those, and outsourcing everything to volunteers who basically do FOSS for fun. This is not quite accurate, the libraries you see the most complaints about are the most popular libraries around. OP specifically complained about Apollo which widely used and backed by a SasS service and VC money. React also deprecates APIs quite often (although they are usually the more obscure parts of the API, the widely used stuff doesn't get deprecated nearly as often). It gets worse when you add smaller libraries who do come from "volunteers who basically do FOSS for fun" because they often have peerDependencies with the big libraries but don't get updated as the big lib deprecates stuff.

diggan 2y ago
Yeah, fair enough, you're right, a lot of the churn is created by companies who do FOSS too. But I think the original point stands regardless of how popular the library is, or who is backing it. Just because Facebook today cares about React, doesn't mean I'd implicitly trust them to care about it for as long as I want to care about my own project, and I certainly don't trust their use cases to always match mine, and that's OK. I think what I was trying to get across is that "npm install lib" carries a far bigger cost than most people realize, just because it gets hidden behind "our code" while in reality, as soon as you include a library/framework into your own codebase, you need to see it as "our code" immediately.
- DanielHB 2y ago
  I agree with you, but I think the liability of a dependency is FAR higher if it has a peerDependency to another dependency. For example, react-router has a peerDependency with react, therefor the liability of adding it to your project is much higher because you can have both of these scenarios: 1) Can't update react without updating react-router because react deprecated some API 2) Can't update react-router without updating react because the new version of react-router is using some new API from react And it drives me insane that people will just add react-random-small-thing from github handle @NotGoingToMaintainThis. These kinds of small dependencies with peerDependencies to core libs are the devil. I am not opposed to using dependencies, but your project needs to pick a few core dependencies and stick with them...

jaza 2y ago

I'm a back-end dev, I've avoided being paid to do any front-end work (and/or my bosses have avoided paying me to do any front-end work? hahaha) for getting on a decade now. So no doubt front-end devs will cringe at what I'm about to say (not that I care!). But for the occasional personal front-end stuff that I still do, my "dependency management" is just "copy-paste versioned CDN script tags / CSS link-rel tags into my index.html file". Which is equivalent to (but better than) old-skool copy-pasting into a "vendor" directory" (which of course I also did, back in the day). And my "front-end build system" is just "write vanilla javascript in .js files and include it un-minified un-typescripted un-anything via script tags". I've got better things to do in my spare time, than deal with npm / gulp / yarn / whatever they've invented this week.

julik 2y ago

At this point in time this is absolutely a "people and process" problem. But also the process that is there has been excercised and is known to folks you may hire. Trying to come up with less of it (or with a different version of it) dramatically shrinks the number of people who can be productive on your product from day 1, and is not a choice to be made lightly. There is also a number of people who will then be spending time convincing you that the "none" or "less" process you have imposed is wrong and you should "just get on with the program".