15 ms·

I have recently been doing some upgrades to the build system for our FE code to swap out yarn for pnpm. I’m normally a backend engineer, but I’ve spent plenty o

I have recently been doing some upgrades to the build system for our FE code to swap out yarn for pnpm. I’m normally a backend engineer, but I’ve spent plenty of time in the JS mines. The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated. Oh, you used the apollo CLI in 2022? Bam, deprecated, go learn how to use graphql-client or whatever, which has a totally different configuration and doesn’t support all the same options. Okay, so we just keep the old one and disable the node engine check in pnpm that makes it complain. Want to do a patch upgrade to some dependency? Hope you weren’t relying on any of its type signatures! Pin that as well, with a todo in the codebase hoping someone will update the signatures. Finally get things running, watch the stream of hundreds of deprecation warnings fly by during the install. Eventually it builds, and I get the hell out of there. It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc. I’ve been working on a large rust project for nearly four years and in that time there have been a few minor breaking changes in or of third party libraries, but only one major breaking change that required significant changes to our application. Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. It’s bananas. Okay, rant over.

__loam 2y ago
GraphQL is such an exciting addition to the front end stack. Imagine, an entire new system you need to learn that cargo cult proponents love and also sucks ass to use.
SamuelAdams 2y ago
I agree, it seems like popular packages really need an LTS release channel or something. Enterprises do not have budget or time to continuously invest in their front end tools. Meanwhile, compared to something written in dotnet or go. I bet there’s a very strong chance those projects will continue to work in 3-5 years.
fragmede 2y ago
Wait, we're supposed to use pnpm now? What happened to yarn? What's wrong with npm? I stop paying attention for six months and even the installer has changed. What's an npx?
- mplanchard 2y ago
  Right??? I started out the process trying to stick with yarn and upgrade it to use plug and play for better CI caching, but svelte apparently just does not work with it and will not do so, so I started looking into pnpm.
  - fragmede 2y ago
    Meanwhile, I had to do some backend thing yesterday, and ended up using the LD_LIBRARY_PATH trick, which was introduced in 1988. I'm grateful that LLMs are great at writing frontend code for me, though the broader implications are a bit scary.
    - soco 2y ago
      But can a LLM help writing code for a library released or updated a few months ago, covering the implied breaking changes? With the way they work today, probably not.
- genuine_smiles 2y ago
  Yarn is still great. npm is ok. pnpm is a little faster than Yarn but has less features.
  - evrybdygonsrfin 2y ago
    Hardly a deal-breaker; presumably I can just pipe the output to less.
- chrisldgk 2y ago
  Main difference between all of them is speed. There’s some differences in how npm, yarn, pnpm or bun handle workspaces and hoisting (and stuff like dependency overrides) but if one of them works for you, you rarely have to switch between them. Edit: also npx is just an alias for npm exec, allowing you to run scripts in npm packages
- diggan 2y ago
gtsop 2y ago
This is exactly why I am a huge fan of ember.js Unfortunatelly it fell behind in popularity mostly due to some unimportant reasons (eg not being able to render 1M rows faster than react) and some important ones (load times), but boy did they build a stable ecosystem! I haven't seen such a commitment to stability and guardrail upgrades to this day on any other piece of front end library.
- jmnicolas 2y ago
  I'm thinking of building a long term living app (say an app that I will use the next 30 years). It has to be a web app so I was thinking of going pure JS. With that requirements in mind would you recommend ember.js?
  - vijaybritto 2y ago
    Go for web components. It's guaranteed to last 30 years
  - whism 2y ago
    If you are designing for that kind of long term I suggest looking into SmallTalk. A lot changes in 30 years.
  - solid_fuel 2y ago
    I know this is kind of the contrarian opinion and I'm not trying to be "that guy", but if you want a web app that works in 30 years you would probably be best off building a server-side rendered application. You need a server, HTTP, HTML, and CSS for any web application, but you don't always need a lot of client side javascript. The fewer things you have in your stack, the fewer things can change under your feet.
  - gtsop 2y ago
    If you MUST use a framework, then yes i would go with ember because they have a prooved commitment to following the web standards rather than creating their own custom standards that they throw away the next year. Having said that, 30 years are very VERY long time in web development. Maybe pure js isn't a bad call, but it depends on how large it is going to be. Someone else mentioned considering sever rendering, not a bad cinsideration either.
fridder 2y ago
This is why I have been so pumped for LiveView. It just removes so much javascript from the equation
- paradox460 2y ago
  And when you need to use JS, you can do so in a clean and controllable way. Using Liveview to mount and unmount custom vue components can give you an extremely nice workflow, where you can just treat a complex select (akin to select2) as another type of input Be sure to check out surface-ui. Marlus is a great guy, and surface really feels like the missing piece of liveview https://surface-ui.org/ https://surface-ui.org/
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.
hajile 2y ago
There's a disconnect between how a computer wants to do things and how a human wants to do things. This disconnect isn't so noticeable on the backend where the problems are generally related to scaling (as there isn't a generalized solution). On the frontend though, this disconnect is everything. This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules. This leads to a loop of unrealistic optimism. 1. Library X promises to abstract everything away in an easy-to-use way 2. Devs adopt X and it makes work fast and fun. 3. The human element forces in tons of edge cases. 4. Devs hit the abstraction limit and start needing elaborate workarounds to do simple things. 5. Devs start looking for an abstraction that works and goes back to the first stage. I'd note that a decent portion of this loop is powered by the explosion of FE devs. There were probably just a couple hundred thousand frontend people when Chrome launched in 2008 (and most of them were design guys rather than programmers). Today, there are millions and most of them have been programming for just a couple of years. Devs (especially senior devs who make architecture/library decisions) and their managers need to realize that there is no panacea. Fast time to market followed by slowing development speed is expected. It seems like every blog brags how "we rewrote 80% of our app in 3 months" but seldom mentions that they are still at just 95% done 3 years later. If you started with React in 2013, you'll still be using it 12 years later (11 years if you were using Vue). If you stuck with Redux, you'll still be using it 10 years later. If you used basically any of the abstractions layered on top of these basic libraries, you have probably been through several rewrites none much better than the previous. The key is not abstracting too much. Repeat yourself just a little more and you'll find the edge cases easier to deal with and changing something basic in 5 files is easier and faster than trying to wade into a single very complex component and change something. You'll find that lots of those abstraction libraries you were using aren't actually buying you much at all. I should also mention Typescript. Basic types are a great resource. When you are spending hours wrangling your complex type soup to fix something you know can be solved with just one simple change, this is an indicator your types are hurting your project. These types are almost always a reflection of your abstraction and indicate that you are abstracting too much. These types also indicate your code is highly polymorphic and will have terrible performance on modern JITs. DRY is a means to an end rather than an end in itself.
- skydhash 2y ago
blueflow 2y ago
laughs in C99
gedy 2y ago
> it seems like literally everything is deprecated I know you mentioned a company-backed example, but bear in mind most open source libs are given away and maintained for free. After a certain point people move on, so basically what do you expect to happen. I created and maintained a couple libraries for 5+ years and it didn't really help my career or life in any way - no job offers, didn't matter to interviewers, so why would I bother?
- mplanchard 2y ago
  Ya for sure, I’m not ragging on the small library devs. Mostly that’s not where the problem is anyway, because they tend to do a small subset of things reasonably well and so there’s not a lot of reason to change.
- niccl 2y ago
  but it doesn't seem to happen the same way in other parts of the programming world. Even in Django, yes, there are squillions of libraries for different things, and many of them haven't been updated in years, but the long-lived ones don't tend to have breaking changes in (at least in my experience). It just seems to be front-end stuff where people will make breaking changes in some long-lived package, and for no obvious reason. Make a new package, or a distinctly different version of the original package that won't get imported by a simple upgrade. Or am I missing some reason that it's not as simple to do this in front-end stuff as it is in other areas?
  - gedy 2y ago
    I mean the browser and security does change somewhat often so there's that. > Make a new package, or a distinctly different version of the original package that won't get imported by a simple upgrade. Maybe some of this is cultural or habits, but I've seen projects that do like import "react-router": "latest", and with no package-lock... and I'm like WTF are you doing? That is a recipe for disaster pulling in latest major versions which by semver can and do have breaking changes. That so many libs take advantage of semver is both good and bad.
0x000xca0xfe 2y ago
And the craziest part is that it is built on top of JS/HTML which is an extremely stable technology at heart. 15 years ago I wrote a small (5KLOC) vanilla JS webapp that is still in daily use by around 10 people without a single line changed. It held up better then my Win32 applications! Almost all of the front end churn is simply a political/organizational failure.
- anthropodie 2y ago
  I build simple applications for personal use like issue tracker, day planner, etc,. By default if you ask Claude it will generate React for frontend but I ask it to use HTML/CSS/JS instead. Because as a backend developer that makes sense to me. I find it hard to read the react code and want to avoid having dependency on npm. It's surprising how well the core technology works without fancy front end frameworks. Claude does most of the grunt work related to CSS/JS allowing me to focus on more interesting things. I only have to do few minor changes here and there which I am happy to do.
  - 0x000xca0xfe 2y ago
    Yeah it's surprising how easy many things really are. I asked Claude to spice up another vanilla JS/HTML app with a Material UI like touch ripple effect and... it simply did. Was just around 100 lines of CSS/JS. No need to rewrite everything.
  - tajd 2y ago
    Yes, 100% this. I’ve seen this idea before somewhere, but I wouldn’t be surprised if people started to basically develop more of their own software from first principles like this. I was doing it today to create a gantt chart from mermaid. I’ve built other applications inside react components as react seems relatively stable - I don’t really care about react though, only that it has a lot of training data for it.
  - ericmcer 2y ago
    Of course it works without frontend frameworks, but if you develop a frontend application using plain JS your core problem is still the one frameworks solve: syncing your application state with the DOM. At first you can do this manually using selectors, but a complex app will need to be capable of doing this to hundreds of elements whenever state changes. At that point you will build some kind of abstraction because manually updating every element would be insanity. That abstraction might be a simple virtual DOM, and now you are halfway to building your own React.
locallost 2y ago
decides to swap out a working package manager for another for no apparent reason "Why do JS people keep doing something new for no apparent reason?"
- koakuma-chan 2y ago
  I'd gladly swap out any piece of tooling if it's written in JavaScript.
- mplanchard 2y ago
  The reason was that I was trying to use a newish feature of yarn (plug and play) to improve CI caching. However, it refuses to play nicely with svelte. pnpm provides similar benefits but works with svelte.
uoaei 2y ago
My conspiracy theory is that FE engineers do this on purpose for job security. Otherwise there simply wouldn't be enough work to justify headcount and salary. Of course there's very few actually devious people who do this on purpose, but who among us hasn't thought "tickets are light this week, how about if I upgrade xxx or yyy?"
taeric 2y ago
Fully agreed that the amount of "that was last year's answer" is obscenely frustrating. Would be one thing if there were minimal boilerplate for the options, but so many patterns are quite involved.
Aurornis 2y ago
> It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc. I’m amazed at how much of this is driven by the FE influencers. The FE world has embraced social media, YouTube, and even Twitch to a degree that I haven’t seen in other domains. Influencers in these areas need to have a constant stream of fresh material to stay relevant, so they’re always driving toward something new that they can produce content about. This is in addition to the very active conference circuit. FE and JS conferences feel like one big competition to present on some hot new topic. There’s also a huge market for selling FE courses. These course creators need you to convince your boss to approve a $700 (limited time price!!!) video course to learn the new hot thing, but they can only do that if they get the industry to move away from the old thing that everyone knows already. So they push hard to drive the new thing and deprecate the old thing.
- ewzimm 2y ago
  That's fascinating, and I had no idea web dev influencers were so big. I checked, and there really are people with millions of followers doing development. Personally, the idea of learning anything related to coding through a video is extremely frustrating. It's a text medium. I want to look at things, take time, think it over, compare code, follow references, look up functions. That people like video formats isn't really surprising to me since it's everywhere, but I still don't fully understand the appeal. Even if you were raised on video content and started coding that way, at some point you have to reference text documentation, right? At that point, I would think you would just stick to the text and not go back to the video, but maybe it's just more entertaining the other way.
  - wiseowise 2y ago
    > That people like video formats isn't really surprising to me since it's everywhere That’s because those “people” are either larping students or kids that want to become programmers. I have never in my 10 year career met a person who said “yeah, I learn my craft from Fireship videos”.
    - 2y ago
pmarreck 2y ago
It's more or less always been like this. It's why I moved to mainly backend (where feasible). Because someone has to maintain that crap at some point.
sergiotapia 2y ago
one wonder how this liability of a tech stack became so popular. i have a theory it was VC dollars pumping up a ton of saas tools and they all came out with one-click integrations. this is one house of cards that may never really be fixed.
divan 2y ago
The worst thing is that it's a cultural aspect. This deprecation and breaking stuff hell is a result of millions of micro-choices. "Why not rename MultiselectDropdown into MultiSelectButtonDropdown! And maybe replace the API of that component to a completely new one! Sounds like a cool idea!". Thousands of person-hours are spent daily for fixing results of such 'extremely important'™ breaking changes. There is simply no culture of understanding the staggering costs of breaking APIs. This is especially frustrating after working for a decade with Go, that has backwards compatibility promise. Which somehow affects Go library developers stance on compaitbility and breaking things. The code written 10 years ago perfectly compiles and work on latest Go version, and it's such a wonderful experience. One of the ways of escaping this JS/web hell for me was switching to Flutter. It worked great, most of the web-stack accidental complexity was happily forgotten. But this culture of "breaking package is fine" creeps in into Dart ecosystem as well, and it's annoying as hell.
- wiseowise 2y ago
  > But this culture of "breaking package is fine" creeps in into Dart ecosystem as well, and it's annoying as hell. It’s almost like this has nothing to do with technology and is more result of a barrier of entry that is one step about nocode solution.
- evantbyrne 2y ago
  I suspect the cultural issues with JS primarily boil down to the fact that every org needs JS, which in turn results in 1) a glut of junior/mid devs and 2) it naturally being ground zero for hype cycles. At this point I honestly wonder if most orgs should even hire for JS skills, or if they would be better served by hiring backend engineers and training them to write progressively enhanced UIs.
  - bloomingkales 2y ago
    The thing is brilliant UI engineers will stun you with incredible UI. It's almost like not investing in AI, you will get blind sided by products that just look and feel better. Your backend engineers are never going to cut it. This is true for backend engineers too, if you try half ass it with "full stack" devs, brilliant backend devs will stun you with things and your products will be inferior. For example, we all got stunned by the machine learning people. We have to pay attention to everyone.
emseetech 2y ago
Ironic that FE dev is built on HTML and CSS, two specs that are so painfully backwards compatible that the original Space Jam website from 1996 still works. A web app written with HTML and CSS and a sprinkling of no-build Javascript will likely work as intended in 30 years.
powersnail 2y ago
That matches my experience as well. Google something, find the documentation, go to the documentation, and "We have moved our documentation to a brand new experience", and the link is to the home page of their new website, so you need to redo the search. X has been deprecated; Y is the replacement; and they provide the same functionality with a completely different API. It just does not make sense to me why Y is created, rather than having X's implementation replaced. A lot of documentations/discussions are also written with the assumption that you are migrating from the previous approach. So if you just dive in and don't have the context of what used to be the way, it's sometimes difficult to understand what they are talking about.
rcleveng 2y ago
I'm still using npm and wasn't sure if I should use yarn or pnmp, is there a clear winner here on this one? Is there an authoritative place to know which ways the winds of change are blowing on this? I ask since both of them (yarn and pnpm) have recent releases within the last days and weeks.
- homebrewer 2y ago
  pnpm saves a lot of disk space by reusing packages and hardlinking (or reflinking if your filesystem supports that) from a single global directory. It's fully transparent for you. Optionally, it can also use a strict mode (or whatever it's called) where you can only access packages that are explicitly mentioned in your dependency list. Really helps with preventing you from accidentally creating unexpended ties to your transitive dependencies. Yarn doesn't really have major upsides compared to modern npm if you can't/won't use their package format (which allows for reading files directly from compressed archives, but it comes with a bunch of downsides and doesn't work with all text editors and frameworks). tldr: I'd recommend pnpm.
  - rcleveng 2y ago
    Cool, thanks! I've not anything this succinct between them before.
    - mplanchard 2y ago
      I agree with their assessment. It uses some nifty storage tricks and I really appreciate the ability to know when packages are accidentally depending on dependencies they haven’t declared.
barrell 2y ago
This has been the most amazing thing about ClojureScript - finding libraries that are 10+ years old without an update still work perfectly. Using reagent and over time learning more and more of the internals (instead of the runaway treadmill in js land). I do miss some of the dynamism of the JS ecosystem from time to time but it’s really nice to step off the proverbial treadmill.
fourneau 2y ago
I've been working on a small side project on-and-off for the last year and some. The state-of-the-art decisions I made last year are already dead. There's a new version of everything, and everything was a breaking change, nothing is backwards compatible. How do people live like this?
- DidYaWipe 2y ago
  They don't. They say fuck it and learn a trade.
skeeterbug 2y ago
I recently had the opposite experience. App was built in older version of React/MUI/CRA/tsc (project started in 2020). I upgraded everything to latest, removed CRA for vite, and it just worked for the most part (vite has some docs for upgrading from CRA). MUI had a few things deprecated, but it didn't break. Removed the yarn lock and switched everything over to vanilla npm now that it has package locks. Took < 1 hour.
frank00001 2y ago
This is why I stopped doing front end.
golergka 2y ago
Can we make something like a “non-deprecation” pledge for libraries? Just make a public commitment on the top of your readme file saying that you will maintain backwards compatibility in your API for at least a couple years. This will make me choose your library over others.
cxr 2y ago
> Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. And by "in JS", you really mean, "in NPM land". So long as folks keep remaining seemingly (almost willfully) ignorant of the source of their pain and/or running right back into the fire the next time the opportunity presents itself, that pain is going to continue. NPM sucks. It's not the way to do JS. Everyone who has ever experienced it and then written a complaint about it should be more than willing to accept this. For whatever reason, though, they aren't. (My hypothesis? They like being able to write about their pain because it gives them something and someone to kvetch about/to. See Aurornis above/below on the role of social media and influence in "FE" (i.e. browser-focused software development), and Alex Danco's "Making is Show Business Now" <https://alexdanco.com/2020/10/08/making-is-show-business-now/ https://alexdanco.com/2020/10/08/making-is-show-business-now...>.)
- bobthepanda 2y ago
  the problem is that as with everything else in FE it is kind of hard to tell what successor framework will "win" and not do this to you. Svelte and Vue were nice and stable until they were not, Deno as an alternative to NPM kind of never got any traction, and unfortunately no one has come up with a better sandbox that works the same everywhere other than the web.
  - deleted 2y ago
    [deleted]
  - rollcat 2y ago
    I understand why they had to EOL Vue 2 and make Vue 3 - I'm still facing migrating a couple of projects at some point, and I will keep putting it away x) But is upgrading Vue 3 across minor versions that much of a pain? Actually curious about people's real world experience.
- wruza 2y ago
  Also by “npm land” you mean “react-webpack-based bloated build- and eco-systems”. NPM sucks. It's not the way to do JS ${X}PM is absolutely the way to do $X. You can’t survive without the PM part. You just have to know cancer when you see it and call it out rather than praising.
jdauriemma 2y ago
Hi there - I work at Apollo and I'd be happy to help you migrate off our old CLI. That utility was sort of a hodgepodge of tools that we ended up either replatforming to our `rover` CLI or, in the case of code generation, recommending that folks use GraphQL Code Generator. It's a testament to that utility's sprawl that I can't guess your use case just by your name-drop of it. I realize the irony in my saying that since it sort of plays into this narrative, but FWIW all the functionality (and then some) of `apollo` is still actively maintained, just not in that particular codebase or form factor. Let me know if there's anything I can do to assist. FWIW Apollo Client is actively maintained, has a lot of new features, and is preparing a v4 release (currently in Alpha). We'll be celebrating 10 years next year :)
- mplanchard 2y ago
  I appreciate this! It is the codegen part, but because it’s in a repo that mostly is just getting bugfixes until we eventually subsume it all with something newer, it’s hard to justify the time spent to migrate to a different tool. The issue I was having with pnpm was that it wouldn’t install the apollo CLI tool due to its having set a required node version that is now quite old in its package.json. I was hoping the graphql codegen options would be more similar, but after about an hour of trying to figure out how to get it to generate approximately the same output I gave up. I’ve worked around it for now by using `pnpm dlx` to use the old apollo CLI without having it as part of the actual package dependencies.
  - jdauriemma 2y ago
    That's a start! Forgive me, I'm heading into a meeting but I want to share some resources with you. It's close to the end of my day so I'll check back in the morning. If you prefer to continue the conversation on another platform, I'm happy to exchange emails or Discord handles. Also consider posting at community[.]apollographql[.]com, the Apollo Client team tries its best to respond to everyone who asks for help there. Any code snippets would be helpful to illustrate observed vs. ideal state when migrating.
  - jdauriemma 2y ago
KronisLV 2y ago
The other day, I needed to quickly whip up an internal dashboard with some dynamic logic. Being somewhat lazy, I just imported jQuery and some additional scripts for it, one of the small CSS-only libraries for basic styling, put all of the custom code in a single JS file and that's it. No toolchains. No build process. No learning about any particular way of doing state managing or rendering or what have you. Just some files and some code. It was delightfully simple. For bigger projects I do think that the likes of Vue strike a nice balance between features and usability, but I've also seen a lot of messing around with toolchains and package versions (or even stuff like needing to migrate away from AngularJS), sometimes it's nice to avoid all of that when you don't need that complexity.
- cosmic_cheese 2y ago
  > No toolchains. No build process. No learning about any particular way of doing state managing or rendering or what have you. Just some files and some code. To me this experience was once upon a time the single biggest selling point for the web as a development platform, and yet everyone is so eager to wade neck-deep into ever-changing library and build chain cruft instead. It’s mystifying.
230nanometers 2y ago
One of many reasons I left FE jobs. I'm tired of spending my evenings discovering what refactor I'm gonna have to do next.
jongjong 2y ago
Part of the problem is that React monopolized the entire space and most other frameworks became legacy; not able to maintain even a tiny community. The sad thing is that React's success, much like its parent company (Meta) is due primarily to network effects and not to merit. This is why frontend development is so bad these days.
squidsoup 2y ago
You could make exactly the same complaint about python packaging. We've gone from setuptools, to pip, to poetry and now uv.
zeroq 2y ago
This. I have a pet project (let's call it home brew Plex) that I've started some 10 years ago and every 2 years I come back to it with the same experiment - let's see what do I have to change to be in line with the current javascript trends. And every time it leads to a complete rewrite. And I'm not talking about changing Angular to React -- I'm talking about fundamental shifts in paradigm, tooling that falls apart, and a brand new feature that everyone has to use this season. The paradox is that I've started my career 25 years ago doing frontend - in flash, as JS was almost noexistent in it's current form back then - and still when I have to do small eyecandy or experiment I like to use plain old ES3/ES5 JS that I can author in a notepad and run directly in a browser without needing a tooling pipeline that would put a blush on most game developers. I think it partially comes from the fact that JS as a modern, full fledged programming language came out of the blue, with sudden demise of flash, catching everyone by surprise. I remember when companies started shifting to js and asking for senior frontend programmers back in the days. I was thinking to myself - hey, if you want someone with 5 yoe with JS in 2013 then most people in the market will be experts on jquery plugins, not serious programming. And I think that's the reason why the community as a whole keeps reinventing the wheel and trying to prove themselves so hard.
throwaway92432 2y ago
Many bring the same mindset to backend as well. In my small team of less than 10 developers we use C#, Java, Kotlin, Rust, Elixir, Go, Javascript, Typescript, and Python to worry about and maintain because developers have been allowed to pick what they want. I have stopped caring about how incredibly short sighted this is, and just think of it as experience that improves my resume
- switch007 2y ago
  > because developers have been allowed to pick what they want. That's a technical leadership failure first and foremost
graynk 2y ago
I fully agree, _but_ it's not just frontend, it's the entire NPM ecosystem. Meaning it's not much better in NodeJS (or Deno/Bun/whathaveyou)
cosmic_cheese 2y ago
Meanwhile, I can go dig up some open source Objective-C/AppKit Mac app project that hasn’t seen any activity in 20 years and probably get it compiling and running in an evening. Cleaning out warnings might take a weekend. I wonder what it’d take to achieve that kind of stability over time in the web front end world…
deleted 2y ago
[deleted]
kamaal 2y ago
>>The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated. I build a lot of FE stuff for internal company tooling. Production, monitoring, dashboards etc. Its crazy how the React ecosystem works. Like you can come back after two years to add a feature and realise you now face weeks/months of migrations tasks before you even begin to add the features. I always compare this to something like say Java. Imagine if Java deprecated and broke everything every 2 years or so. Imagine the omni present migrations projects in the backend. Sometimes I think this is why banks, and other places that need long term stability are still on php+jquery+LAMP stack.
- Auracle 2y ago
  I’m getting back into development after being a photographer for the last 10 years and after reading your comment I thought “maybe I should apply at a bank…”
brightball 2y ago
This experience is one of the reasons people love Phoenix LiveView so much.
deleted 2y ago
[deleted]
johnfn 2y ago
As a primarily frontend engineer who has "spent plenty of time in the Python mines", I feel exactly the same way. Oh my god, Python is a horrific mishmash of deprecated and impossible-to-upgrade libraries and dependencies. Honestly, I think it's significantly worse than the frontend - at least with the frontend, the scope of the damage is limited by TypeScript and the language limiting you to doing relatively sane things. In Python, you can do LITERALLY EVERYTHING, which leads to library authors doing LITERALLY EVERYTHING. Want to change how modules are imported? Go for it! Want to make a metaclass and break all assumptions about how a class operates? Have fun! Think your static typing will help you? Good luck - you can't even do trivial things like `Partial<T>` or statically assert that two objects have the same type. All this kvetching about libraries changing makes me laugh. The Python 2 -> 3 transition was so horrific that the last place that I worked at had a 100M Python monolith with no plans of EVER upgrading to 3. SqlAlchemy 1 -> 2 is an 8 step migration that requires a TOTAL rewrite, and if you break anything, YOUR SITE GOES DOWN. And then people complain because React optionally added hooks or something! The weird thing is that the internet is full of posts about "The Frontend Treadmill", but no one ever seems to gripe about the converse.
- sethammons 2y ago
  I am back at a python shop and (again) pushing, successfully, Go. Python is molasses for teams for all the reasons you state and more.
  - wruza 2y ago
    What does “molasses” mean here? Search says it’s “slow”, but that makes little sense.
    - sethammons 2y ago
      that's exactly what I mean. At the three python shops I've been at, teams reach across boundaries and add abstractions. This gets something out fast at first, but as the organization grows, if you are not diligent, the code organically grows and the ability to ship new things becomes increasingly tied to how other things are implemented. What should take 1 team 1 sprint takes a dozen teams a dozen sprints. Code that shouldn't seemingly otherwise do so can get called in unexpected ways and take down your application. All this "you can do anything" ability leads to abstractions to solve niche issues that makes everything harder to reason about. A great example: In django, a property on a model object might not be a property. This isn't limited to django, but that is where it bit me. So "customer_record.billing_type". Having loaded the customer_record, one might assume that you could access a property on it with little to no issue. Nope. Python lets you treat that property as a method, and now a hot loop in our code is making a network request to load load more data from a different databases. To prevent this requires mental load, knowing what properties are properties and which are not. Because in Python, it could be anything, even a boat, and you know how much we've wanted one of those --Peter G.
guappa 2y ago
> It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc My theory is that they do it because they don't have enough to do.
brabel 2y ago
I work mostly on the JVM world, with Java/Kotlin. Two comments: In Java: I can build stuff from the early 2000's without changing a line, most likely, if it's using Maven or Ant to build. If it's Gradle, we may have trouble with the JVM version even if Gradle wrapper is used, and if it's not, well good luck as Gradle has evolved hugely since the early days (I think early 2010's if my memory is any good). In Kotlin: has been a wild ride for me... not like JS, maybe... more like what you describe from Rust. I mean, in 4 years you've had a breaking change, that's horrifying for someone used to Java :D. Kotlin does require a lot of upkeep compared to Java, specially when combined with said Gradle. More if you use KTest... much more if you use KTor... and a hell of a lot more if you use Kotlin MP, which we do on one of our projects (though I acknowledge we were early adopters).

__loam 2y ago

GraphQL is such an exciting addition to the front end stack. Imagine, an entire new system you need to learn that cargo cult proponents love and also sucks ass to use.

SamuelAdams 2y ago

I agree, it seems like popular packages really need an LTS release channel or something. Enterprises do not have budget or time to continuously invest in their front end tools. Meanwhile, compared to something written in dotnet or go. I bet there’s a very strong chance those projects will continue to work in 3-5 years.

fragmede 2y ago

Wait, we're supposed to use pnpm now? What happened to yarn? What's wrong with npm? I stop paying attention for six months and even the installer has changed. What's an npx?

mplanchard 2y ago
Right??? I started out the process trying to stick with yarn and upgrade it to use plug and play for better CI caching, but svelte apparently just does not work with it and will not do so, so I started looking into pnpm.
- fragmede 2y ago
  Meanwhile, I had to do some backend thing yesterday, and ended up using the LD_LIBRARY_PATH trick, which was introduced in 1988. I'm grateful that LLMs are great at writing frontend code for me, though the broader implications are a bit scary.
  - soco 2y ago
    But can a LLM help writing code for a library released or updated a few months ago, covering the implied breaking changes? With the way they work today, probably not.
genuine_smiles 2y ago
Yarn is still great. npm is ok. pnpm is a little faster than Yarn but has less features.
- evrybdygonsrfin 2y ago
  Hardly a deal-breaker; presumably I can just pipe the output to less.
chrisldgk 2y ago
Main difference between all of them is speed. There’s some differences in how npm, yarn, pnpm or bun handle workspaces and hoisting (and stuff like dependency overrides) but if one of them works for you, you rarely have to switch between them. Edit: also npx is just an alias for npm exec, allowing you to run scripts in npm packages
diggan 2y ago

gtsop 2y ago

This is exactly why I am a huge fan of ember.js Unfortunatelly it fell behind in popularity mostly due to some unimportant reasons (eg not being able to render 1M rows faster than react) and some important ones (load times), but boy did they build a stable ecosystem! I haven't seen such a commitment to stability and guardrail upgrades to this day on any other piece of front end library.

jmnicolas 2y ago
I'm thinking of building a long term living app (say an app that I will use the next 30 years). It has to be a web app so I was thinking of going pure JS. With that requirements in mind would you recommend ember.js?
- vijaybritto 2y ago
  Go for web components. It's guaranteed to last 30 years
- whism 2y ago
  If you are designing for that kind of long term I suggest looking into SmallTalk. A lot changes in 30 years.
- solid_fuel 2y ago
  I know this is kind of the contrarian opinion and I'm not trying to be "that guy", but if you want a web app that works in 30 years you would probably be best off building a server-side rendered application. You need a server, HTTP, HTML, and CSS for any web application, but you don't always need a lot of client side javascript. The fewer things you have in your stack, the fewer things can change under your feet.
- gtsop 2y ago
  If you MUST use a framework, then yes i would go with ember because they have a prooved commitment to following the web standards rather than creating their own custom standards that they throw away the next year. Having said that, 30 years are very VERY long time in web development. Maybe pure js isn't a bad call, but it depends on how large it is going to be. Someone else mentioned considering sever rendering, not a bad cinsideration either.

fridder 2y ago

This is why I have been so pumped for LiveView. It just removes so much javascript from the equation

paradox460 2y ago
And when you need to use JS, you can do so in a clean and controllable way. Using Liveview to mount and unmount custom vue components can give you an extremely nice workflow, where you can just treat a complex select (akin to select2) as another type of input Be sure to check out surface-ui. Marlus is a great guy, and surface really feels like the missing piece of liveview https://surface-ui.org/ https://surface-ui.org/

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.

hajile 2y ago

There's a disconnect between how a computer wants to do things and how a human wants to do things. This disconnect isn't so noticeable on the backend where the problems are generally related to scaling (as there isn't a generalized solution). On the frontend though, this disconnect is everything. This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules. This leads to a loop of unrealistic optimism. 1. Library X promises to abstract everything away in an easy-to-use way 2. Devs adopt X and it makes work fast and fun. 3. The human element forces in tons of edge cases. 4. Devs hit the abstraction limit and start needing elaborate workarounds to do simple things. 5. Devs start looking for an abstraction that works and goes back to the first stage. I'd note that a decent portion of this loop is powered by the explosion of FE devs. There were probably just a couple hundred thousand frontend people when Chrome launched in 2008 (and most of them were design guys rather than programmers). Today, there are millions and most of them have been programming for just a couple of years. Devs (especially senior devs who make architecture/library decisions) and their managers need to realize that there is no panacea. Fast time to market followed by slowing development speed is expected. It seems like every blog brags how "we rewrote 80% of our app in 3 months" but seldom mentions that they are still at just 95% done 3 years later. If you started with React in 2013, you'll still be using it 12 years later (11 years if you were using Vue). If you stuck with Redux, you'll still be using it 10 years later. If you used basically any of the abstractions layered on top of these basic libraries, you have probably been through several rewrites none much better than the previous. The key is not abstracting too much. Repeat yourself just a little more and you'll find the edge cases easier to deal with and changing something basic in 5 files is easier and faster than trying to wade into a single very complex component and change something. You'll find that lots of those abstraction libraries you were using aren't actually buying you much at all. I should also mention Typescript. Basic types are a great resource. When you are spending hours wrangling your complex type soup to fix something you know can be solved with just one simple change, this is an indicator your types are hurting your project. These types are almost always a reflection of your abstraction and indicate that you are abstracting too much. These types also indicate your code is highly polymorphic and will have terrible performance on modern JITs. DRY is a means to an end rather than an end in itself.

skydhash 2y ago

blueflow 2y ago

laughs in C99

gedy 2y ago

> it seems like literally everything is deprecated I know you mentioned a company-backed example, but bear in mind most open source libs are given away and maintained for free. After a certain point people move on, so basically what do you expect to happen. I created and maintained a couple libraries for 5+ years and it didn't really help my career or life in any way - no job offers, didn't matter to interviewers, so why would I bother?

mplanchard 2y ago
Ya for sure, I’m not ragging on the small library devs. Mostly that’s not where the problem is anyway, because they tend to do a small subset of things reasonably well and so there’s not a lot of reason to change.
niccl 2y ago
but it doesn't seem to happen the same way in other parts of the programming world. Even in Django, yes, there are squillions of libraries for different things, and many of them haven't been updated in years, but the long-lived ones don't tend to have breaking changes in (at least in my experience). It just seems to be front-end stuff where people will make breaking changes in some long-lived package, and for no obvious reason. Make a new package, or a distinctly different version of the original package that won't get imported by a simple upgrade. Or am I missing some reason that it's not as simple to do this in front-end stuff as it is in other areas?
- gedy 2y ago
  I mean the browser and security does change somewhat often so there's that. > Make a new package, or a distinctly different version of the original package that won't get imported by a simple upgrade. Maybe some of this is cultural or habits, but I've seen projects that do like import "react-router": "latest", and with no package-lock... and I'm like WTF are you doing? That is a recipe for disaster pulling in latest major versions which by semver can and do have breaking changes. That so many libs take advantage of semver is both good and bad.

0x000xca0xfe 2y ago

And the craziest part is that it is built on top of JS/HTML which is an extremely stable technology at heart. 15 years ago I wrote a small (5KLOC) vanilla JS webapp that is still in daily use by around 10 people without a single line changed. It held up better then my Win32 applications! Almost all of the front end churn is simply a political/organizational failure.

anthropodie 2y ago
I build simple applications for personal use like issue tracker, day planner, etc,. By default if you ask Claude it will generate React for frontend but I ask it to use HTML/CSS/JS instead. Because as a backend developer that makes sense to me. I find it hard to read the react code and want to avoid having dependency on npm. It's surprising how well the core technology works without fancy front end frameworks. Claude does most of the grunt work related to CSS/JS allowing me to focus on more interesting things. I only have to do few minor changes here and there which I am happy to do.
- 0x000xca0xfe 2y ago
  Yeah it's surprising how easy many things really are. I asked Claude to spice up another vanilla JS/HTML app with a Material UI like touch ripple effect and... it simply did. Was just around 100 lines of CSS/JS. No need to rewrite everything.
- tajd 2y ago
  Yes, 100% this. I’ve seen this idea before somewhere, but I wouldn’t be surprised if people started to basically develop more of their own software from first principles like this. I was doing it today to create a gantt chart from mermaid. I’ve built other applications inside react components as react seems relatively stable - I don’t really care about react though, only that it has a lot of training data for it.
- ericmcer 2y ago
  Of course it works without frontend frameworks, but if you develop a frontend application using plain JS your core problem is still the one frameworks solve: syncing your application state with the DOM. At first you can do this manually using selectors, but a complex app will need to be capable of doing this to hundreds of elements whenever state changes. At that point you will build some kind of abstraction because manually updating every element would be insanity. That abstraction might be a simple virtual DOM, and now you are halfway to building your own React.

locallost 2y ago

decides to swap out a working package manager for another for no apparent reason "Why do JS people keep doing something new for no apparent reason?"

koakuma-chan 2y ago
I'd gladly swap out any piece of tooling if it's written in JavaScript.
mplanchard 2y ago
The reason was that I was trying to use a newish feature of yarn (plug and play) to improve CI caching. However, it refuses to play nicely with svelte. pnpm provides similar benefits but works with svelte.

uoaei 2y ago

My conspiracy theory is that FE engineers do this on purpose for job security. Otherwise there simply wouldn't be enough work to justify headcount and salary. Of course there's very few actually devious people who do this on purpose, but who among us hasn't thought "tickets are light this week, how about if I upgrade xxx or yyy?"

taeric 2y ago

Fully agreed that the amount of "that was last year's answer" is obscenely frustrating. Would be one thing if there were minimal boilerplate for the options, but so many patterns are quite involved.

Aurornis 2y ago

> It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc. I’m amazed at how much of this is driven by the FE influencers. The FE world has embraced social media, YouTube, and even Twitch to a degree that I haven’t seen in other domains. Influencers in these areas need to have a constant stream of fresh material to stay relevant, so they’re always driving toward something new that they can produce content about. This is in addition to the very active conference circuit. FE and JS conferences feel like one big competition to present on some hot new topic. There’s also a huge market for selling FE courses. These course creators need you to convince your boss to approve a $700 (limited time price!!!) video course to learn the new hot thing, but they can only do that if they get the industry to move away from the old thing that everyone knows already. So they push hard to drive the new thing and deprecate the old thing.

ewzimm 2y ago
That's fascinating, and I had no idea web dev influencers were so big. I checked, and there really are people with millions of followers doing development. Personally, the idea of learning anything related to coding through a video is extremely frustrating. It's a text medium. I want to look at things, take time, think it over, compare code, follow references, look up functions. That people like video formats isn't really surprising to me since it's everywhere, but I still don't fully understand the appeal. Even if you were raised on video content and started coding that way, at some point you have to reference text documentation, right? At that point, I would think you would just stick to the text and not go back to the video, but maybe it's just more entertaining the other way.
- wiseowise 2y ago
  > That people like video formats isn't really surprising to me since it's everywhere That’s because those “people” are either larping students or kids that want to become programmers. I have never in my 10 year career met a person who said “yeah, I learn my craft from Fireship videos”.
  - 2y ago

pmarreck 2y ago

It's more or less always been like this. It's why I moved to mainly backend (where feasible). Because someone has to maintain that crap at some point.

sergiotapia 2y ago

one wonder how this liability of a tech stack became so popular. i have a theory it was VC dollars pumping up a ton of saas tools and they all came out with one-click integrations. this is one house of cards that may never really be fixed.

divan 2y ago

The worst thing is that it's a cultural aspect. This deprecation and breaking stuff hell is a result of millions of micro-choices. "Why not rename MultiselectDropdown into MultiSelectButtonDropdown! And maybe replace the API of that component to a completely new one! Sounds like a cool idea!". Thousands of person-hours are spent daily for fixing results of such 'extremely important'™ breaking changes. There is simply no culture of understanding the staggering costs of breaking APIs. This is especially frustrating after working for a decade with Go, that has backwards compatibility promise. Which somehow affects Go library developers stance on compaitbility and breaking things. The code written 10 years ago perfectly compiles and work on latest Go version, and it's such a wonderful experience. One of the ways of escaping this JS/web hell for me was switching to Flutter. It worked great, most of the web-stack accidental complexity was happily forgotten. But this culture of "breaking package is fine" creeps in into Dart ecosystem as well, and it's annoying as hell.

wiseowise 2y ago
> But this culture of "breaking package is fine" creeps in into Dart ecosystem as well, and it's annoying as hell. It’s almost like this has nothing to do with technology and is more result of a barrier of entry that is one step about nocode solution.
evantbyrne 2y ago
I suspect the cultural issues with JS primarily boil down to the fact that every org needs JS, which in turn results in 1) a glut of junior/mid devs and 2) it naturally being ground zero for hype cycles. At this point I honestly wonder if most orgs should even hire for JS skills, or if they would be better served by hiring backend engineers and training them to write progressively enhanced UIs.
- bloomingkales 2y ago
  The thing is brilliant UI engineers will stun you with incredible UI. It's almost like not investing in AI, you will get blind sided by products that just look and feel better. Your backend engineers are never going to cut it. This is true for backend engineers too, if you try half ass it with "full stack" devs, brilliant backend devs will stun you with things and your products will be inferior. For example, we all got stunned by the machine learning people. We have to pay attention to everyone.

emseetech 2y ago

Ironic that FE dev is built on HTML and CSS, two specs that are so painfully backwards compatible that the original Space Jam website from 1996 still works. A web app written with HTML and CSS and a sprinkling of no-build Javascript will likely work as intended in 30 years.

powersnail 2y ago

That matches my experience as well. Google something, find the documentation, go to the documentation, and "We have moved our documentation to a brand new experience", and the link is to the home page of their new website, so you need to redo the search. X has been deprecated; Y is the replacement; and they provide the same functionality with a completely different API. It just does not make sense to me why Y is created, rather than having X's implementation replaced. A lot of documentations/discussions are also written with the assumption that you are migrating from the previous approach. So if you just dive in and don't have the context of what used to be the way, it's sometimes difficult to understand what they are talking about.

rcleveng 2y ago

I'm still using npm and wasn't sure if I should use yarn or pnmp, is there a clear winner here on this one? Is there an authoritative place to know which ways the winds of change are blowing on this? I ask since both of them (yarn and pnpm) have recent releases within the last days and weeks.

homebrewer 2y ago
pnpm saves a lot of disk space by reusing packages and hardlinking (or reflinking if your filesystem supports that) from a single global directory. It's fully transparent for you. Optionally, it can also use a strict mode (or whatever it's called) where you can only access packages that are explicitly mentioned in your dependency list. Really helps with preventing you from accidentally creating unexpended ties to your transitive dependencies. Yarn doesn't really have major upsides compared to modern npm if you can't/won't use their package format (which allows for reading files directly from compressed archives, but it comes with a bunch of downsides and doesn't work with all text editors and frameworks). tldr: I'd recommend pnpm.
- rcleveng 2y ago
  Cool, thanks! I've not anything this succinct between them before.
  - mplanchard 2y ago
    I agree with their assessment. It uses some nifty storage tricks and I really appreciate the ability to know when packages are accidentally depending on dependencies they haven’t declared.

barrell 2y ago

This has been the most amazing thing about ClojureScript - finding libraries that are 10+ years old without an update still work perfectly. Using reagent and over time learning more and more of the internals (instead of the runaway treadmill in js land). I do miss some of the dynamism of the JS ecosystem from time to time but it’s really nice to step off the proverbial treadmill.

fourneau 2y ago

I've been working on a small side project on-and-off for the last year and some. The state-of-the-art decisions I made last year are already dead. There's a new version of everything, and everything was a breaking change, nothing is backwards compatible. How do people live like this?

DidYaWipe 2y ago
They don't. They say fuck it and learn a trade.

skeeterbug 2y ago

I recently had the opposite experience. App was built in older version of React/MUI/CRA/tsc (project started in 2020). I upgraded everything to latest, removed CRA for vite, and it just worked for the most part (vite has some docs for upgrading from CRA). MUI had a few things deprecated, but it didn't break. Removed the yarn lock and switched everything over to vanilla npm now that it has package locks. Took < 1 hour.

frank00001 2y ago

This is why I stopped doing front end.

golergka 2y ago

Can we make something like a “non-deprecation” pledge for libraries? Just make a public commitment on the top of your readme file saying that you will maintain backwards compatibility in your API for at least a couple years. This will make me choose your library over others.

cxr 2y ago

> Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. And by "in JS", you really mean, "in NPM land". So long as folks keep remaining seemingly (almost willfully) ignorant of the source of their pain and/or running right back into the fire the next time the opportunity presents itself, that pain is going to continue. NPM sucks. It's not the way to do JS. Everyone who has ever experienced it and then written a complaint about it should be more than willing to accept this. For whatever reason, though, they aren't. (My hypothesis? They like being able to write about their pain because it gives them something and someone to kvetch about/to. See Aurornis above/below on the role of social media and influence in "FE" (i.e. browser-focused software development), and Alex Danco's "Making is Show Business Now" <https://alexdanco.com/2020/10/08/making-is-show-business-now/ https://alexdanco.com/2020/10/08/making-is-show-business-now...>.)

bobthepanda 2y ago
the problem is that as with everything else in FE it is kind of hard to tell what successor framework will "win" and not do this to you. Svelte and Vue were nice and stable until they were not, Deno as an alternative to NPM kind of never got any traction, and unfortunately no one has come up with a better sandbox that works the same everywhere other than the web.
- deleted 2y ago
  [deleted]
- rollcat 2y ago
  I understand why they had to EOL Vue 2 and make Vue 3 - I'm still facing migrating a couple of projects at some point, and I will keep putting it away x) But is upgrading Vue 3 across minor versions that much of a pain? Actually curious about people's real world experience.
wruza 2y ago
Also by “npm land” you mean “react-webpack-based bloated build- and eco-systems”. NPM sucks. It's not the way to do JS ${X}PM is absolutely the way to do $X. You can’t survive without the PM part. You just have to know cancer when you see it and call it out rather than praising.

jdauriemma 2y ago

Hi there - I work at Apollo and I'd be happy to help you migrate off our old CLI. That utility was sort of a hodgepodge of tools that we ended up either replatforming to our `rover` CLI or, in the case of code generation, recommending that folks use GraphQL Code Generator. It's a testament to that utility's sprawl that I can't guess your use case just by your name-drop of it. I realize the irony in my saying that since it sort of plays into this narrative, but FWIW all the functionality (and then some) of `apollo` is still actively maintained, just not in that particular codebase or form factor. Let me know if there's anything I can do to assist. FWIW Apollo Client is actively maintained, has a lot of new features, and is preparing a v4 release (currently in Alpha). We'll be celebrating 10 years next year :)

mplanchard 2y ago
I appreciate this! It is the codegen part, but because it’s in a repo that mostly is just getting bugfixes until we eventually subsume it all with something newer, it’s hard to justify the time spent to migrate to a different tool. The issue I was having with pnpm was that it wouldn’t install the apollo CLI tool due to its having set a required node version that is now quite old in its package.json. I was hoping the graphql codegen options would be more similar, but after about an hour of trying to figure out how to get it to generate approximately the same output I gave up. I’ve worked around it for now by using `pnpm dlx` to use the old apollo CLI without having it as part of the actual package dependencies.
- jdauriemma 2y ago
  That's a start! Forgive me, I'm heading into a meeting but I want to share some resources with you. It's close to the end of my day so I'll check back in the morning. If you prefer to continue the conversation on another platform, I'm happy to exchange emails or Discord handles. Also consider posting at community[.]apollographql[.]com, the Apollo Client team tries its best to respond to everyone who asks for help there. Any code snippets would be helpful to illustrate observed vs. ideal state when migrating.
- jdauriemma 2y ago

KronisLV 2y ago

The other day, I needed to quickly whip up an internal dashboard with some dynamic logic. Being somewhat lazy, I just imported jQuery and some additional scripts for it, one of the small CSS-only libraries for basic styling, put all of the custom code in a single JS file and that's it. No toolchains. No build process. No learning about any particular way of doing state managing or rendering or what have you. Just some files and some code. It was delightfully simple. For bigger projects I do think that the likes of Vue strike a nice balance between features and usability, but I've also seen a lot of messing around with toolchains and package versions (or even stuff like needing to migrate away from AngularJS), sometimes it's nice to avoid all of that when you don't need that complexity.

cosmic_cheese 2y ago
> No toolchains. No build process. No learning about any particular way of doing state managing or rendering or what have you. Just some files and some code. To me this experience was once upon a time the single biggest selling point for the web as a development platform, and yet everyone is so eager to wade neck-deep into ever-changing library and build chain cruft instead. It’s mystifying.

230nanometers 2y ago

One of many reasons I left FE jobs. I'm tired of spending my evenings discovering what refactor I'm gonna have to do next.

jongjong 2y ago

Part of the problem is that React monopolized the entire space and most other frameworks became legacy; not able to maintain even a tiny community. The sad thing is that React's success, much like its parent company (Meta) is due primarily to network effects and not to merit. This is why frontend development is so bad these days.

squidsoup 2y ago

You could make exactly the same complaint about python packaging. We've gone from setuptools, to pip, to poetry and now uv.

zeroq 2y ago

This. I have a pet project (let's call it home brew Plex) that I've started some 10 years ago and every 2 years I come back to it with the same experiment - let's see what do I have to change to be in line with the current javascript trends. And every time it leads to a complete rewrite. And I'm not talking about changing Angular to React -- I'm talking about fundamental shifts in paradigm, tooling that falls apart, and a brand new feature that everyone has to use this season. The paradox is that I've started my career 25 years ago doing frontend - in flash, as JS was almost noexistent in it's current form back then - and still when I have to do small eyecandy or experiment I like to use plain old ES3/ES5 JS that I can author in a notepad and run directly in a browser without needing a tooling pipeline that would put a blush on most game developers. I think it partially comes from the fact that JS as a modern, full fledged programming language came out of the blue, with sudden demise of flash, catching everyone by surprise. I remember when companies started shifting to js and asking for senior frontend programmers back in the days. I was thinking to myself - hey, if you want someone with 5 yoe with JS in 2013 then most people in the market will be experts on jquery plugins, not serious programming. And I think that's the reason why the community as a whole keeps reinventing the wheel and trying to prove themselves so hard.

throwaway92432 2y ago

Many bring the same mindset to backend as well. In my small team of less than 10 developers we use C#, Java, Kotlin, Rust, Elixir, Go, Javascript, Typescript, and Python to worry about and maintain because developers have been allowed to pick what they want. I have stopped caring about how incredibly short sighted this is, and just think of it as experience that improves my resume

switch007 2y ago
> because developers have been allowed to pick what they want. That's a technical leadership failure first and foremost

graynk 2y ago

I fully agree, _but_ it's not just frontend, it's the entire NPM ecosystem. Meaning it's not much better in NodeJS (or Deno/Bun/whathaveyou)

cosmic_cheese 2y ago

Meanwhile, I can go dig up some open source Objective-C/AppKit Mac app project that hasn’t seen any activity in 20 years and probably get it compiling and running in an evening. Cleaning out warnings might take a weekend. I wonder what it’d take to achieve that kind of stability over time in the web front end world…

deleted 2y ago

[deleted]

kamaal 2y ago

>>The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated. I build a lot of FE stuff for internal company tooling. Production, monitoring, dashboards etc. Its crazy how the React ecosystem works. Like you can come back after two years to add a feature and realise you now face weeks/months of migrations tasks before you even begin to add the features. I always compare this to something like say Java. Imagine if Java deprecated and broke everything every 2 years or so. Imagine the omni present migrations projects in the backend. Sometimes I think this is why banks, and other places that need long term stability are still on php+jquery+LAMP stack.

Auracle 2y ago
I’m getting back into development after being a photographer for the last 10 years and after reading your comment I thought “maybe I should apply at a bank…”

brightball 2y ago

This experience is one of the reasons people love Phoenix LiveView so much.

deleted 2y ago

[deleted]

johnfn 2y ago

As a primarily frontend engineer who has "spent plenty of time in the Python mines", I feel exactly the same way. Oh my god, Python is a horrific mishmash of deprecated and impossible-to-upgrade libraries and dependencies. Honestly, I think it's significantly worse than the frontend - at least with the frontend, the scope of the damage is limited by TypeScript and the language limiting you to doing relatively sane things. In Python, you can do LITERALLY EVERYTHING, which leads to library authors doing LITERALLY EVERYTHING. Want to change how modules are imported? Go for it! Want to make a metaclass and break all assumptions about how a class operates? Have fun! Think your static typing will help you? Good luck - you can't even do trivial things like `Partial<T>` or statically assert that two objects have the same type. All this kvetching about libraries changing makes me laugh. The Python 2 -> 3 transition was so horrific that the last place that I worked at had a 100M Python monolith with no plans of EVER upgrading to 3. SqlAlchemy 1 -> 2 is an 8 step migration that requires a TOTAL rewrite, and if you break anything, YOUR SITE GOES DOWN. And then people complain because React optionally added hooks or something! The weird thing is that the internet is full of posts about "The Frontend Treadmill", but no one ever seems to gripe about the converse.

sethammons 2y ago
I am back at a python shop and (again) pushing, successfully, Go. Python is molasses for teams for all the reasons you state and more.
- wruza 2y ago
  What does “molasses” mean here? Search says it’s “slow”, but that makes little sense.
  - sethammons 2y ago
    that's exactly what I mean. At the three python shops I've been at, teams reach across boundaries and add abstractions. This gets something out fast at first, but as the organization grows, if you are not diligent, the code organically grows and the ability to ship new things becomes increasingly tied to how other things are implemented. What should take 1 team 1 sprint takes a dozen teams a dozen sprints. Code that shouldn't seemingly otherwise do so can get called in unexpected ways and take down your application. All this "you can do anything" ability leads to abstractions to solve niche issues that makes everything harder to reason about. A great example: In django, a property on a model object might not be a property. This isn't limited to django, but that is where it bit me. So "customer_record.billing_type". Having loaded the customer_record, one might assume that you could access a property on it with little to no issue. Nope. Python lets you treat that property as a method, and now a hot loop in our code is making a network request to load load more data from a different databases. To prevent this requires mental load, knowing what properties are properties and which are not. Because in Python, it could be anything, even a boat, and you know how much we've wanted one of those --Peter G.

guappa 2y ago

> It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc My theory is that they do it because they don't have enough to do.

brabel 2y ago

I work mostly on the JVM world, with Java/Kotlin. Two comments: In Java: I can build stuff from the early 2000's without changing a line, most likely, if it's using Maven or Ant to build. If it's Gradle, we may have trouble with the JVM version even if Gradle wrapper is used, and if it's not, well good luck as Gradle has evolved hugely since the early days (I think early 2010's if my memory is any good). In Kotlin: has been a wild ride for me... not like JS, maybe... more like what you describe from Rust. I mean, in 4 years you've had a breaking change, that's horrifying for someone used to Java :D. Kotlin does require a lot of upkeep compared to Java, specially when combined with said Gradle. More if you use KTest... much more if you use KTor... and a hell of a lot more if you use Kotlin MP, which we do on one of our projects (though I acknowledge we were early adopters).