4 ms·

Frontend work sounds like hell. You're telling me you updated YOUR code to work with the latest framework release? What was even new in that release? They seem

Frontend work sounds like hell. You're telling me you updated YOUR code to work with the latest framework release? What was even new in that release? They seem to have no respect for peoples time or any consideration for longtermism or even just the common decency of backwards compatibility. What are we at now, React 19? Is it just a reason to keep people employed?

wetpaws 2y ago
[dead]
golergka 2y ago
> You're telling me you updated YOUR code to work with the latest framework release? I work on frontend right now, but I've worked on backend earlier, as well as gamedev and desktop applications. And it was always like that in every area: when your major dependency has a major version upgrade, you will have to spend effort on migrating your code to support it.
- bastardoperator 2y ago
  It a software problem, not a frontend/backend problem. We've all been subjected this insanity in some way.
  - int_19h 2y ago
    Its severity varies between ecosystems, though, and JavaScript is especially crazy in this regard. Frontend JS, doubly so.
- fiddlerwoaroof 2y ago
  The issue I had when I still worked in the frontend world is the frequency of major version updates. If you used standard project bootstrapping tools in approximately 2017, you got a whole bunch of libraries and tools that would have significant breaking changes multiple times over the next three years or so (I know because I had to maintain them).
- 2mlWQbCK 2y ago
  That seems to be a problem that is getting worse with time though, with increasingly frequent "major" releases and fewer that consider backwards compatibility much at all. Also it used to be much more common to have published specs and standards that you could code to for a good chance to not have to rewrite your code next month.
- leosarev 2y ago
  Except usual time to upgrade to next version of .net is less than man day.
striking 2y ago
> What are we at now, Rails 8? Is it just a reason to keep people employed?
- bdcravens 2y ago
  8 major releases over 20 years vs 19 over 10.
  - mardifoufs 2y ago
    Yet react 19 is almost (except for some edge cases that only affect very specific stuff) fully compatible with version 1. Try running a rails 3 app on rails 8 or vice versa.
  - morcus 2y ago
    The React versioning is a bit silly, but React 15 was the first major version (in 2016) which makes it more like 4 major releases in 9 years. Not that different from 8 major releases over 20 years.
sieabahlpark 2y ago
Tailwind v4 just gave everyone who uses sass the middle finger. It's rampant in the front end to rewrite because it's actually a solved problem. They need to explain their salary by reinventing constantly..
voat 2y ago
No one is forcing you to upgrade, Svelte 4 still works just fine? Svelte has had basically no major API changes since 2019, that's a better part of a decade. And with this new architecture change, they released a sophisticated codemod to do most of the work of updating for you.
- KTibow 2y ago
  In fact, you can still use Svelte 4-style components with Svelte 5, even in the same project.
- cube00 2y ago
  Great until your dependency scanner picks up a vulnerability in the framework or a dependency that can't be upgraded without breaking v4, no exemptions can be given and the only updated version is 5. [1] [1] https://endoflife.date/svelte https://endoflife.date/svelte
  - Capricorn2481 2y ago
    If it's already end of life you can fork it and upgrade the dependency. You'll miss nothing. This is only difficult if you need to maintain changes upstream, but that's not the case here. Security support lifetimes make sense for a widely used language or runtime, but not really a frontend web framework on the most backwards compatible language you can have.
austin-cheney 2y ago
Front end development is a 90% self-induced hell. There are real challenges like accessibility, processing data from service calls, architecture, and more. Those aren't the things most developers complain about. Most front end developers spend their energy on concerns of code style, tools, build steps, framework madness, state management, and more. Those are fashion concerns. A decent programmer can solve for most of those themselves without external tooling in a fraction of the time and code size, but not everybody that does this work is confident writing original code.
- Etheryte 2y ago
  I can't even begin to count the number of codebases I've seen where developers rolled with this idea and ended up with royal spaghetti. Everyone thinks they can build these frameworks from scratch, but they overlook the unknown unknowns. Nearly every custom implementation of state management, complex forms, async flow management, etc I've seen in the wild is riddled with countless bugs that could've been avoided if they just picked a boring and widely used library. And I've seen plenty, because I'm usually the guy that gets called up when no one else can untangle it anymore.
  - austin-cheney 2y ago
    Yes, I have seen that countless times too. Developers that have no idea how to write original software think they can go without a framework and then write a framework. That is stupid, and its because those developers know something about frameworks but never learned to program. Stop toying with irrelevant nonsense and actually release a product for users that solves from some real business requirement, which is certainly not a framework.
- johnfn 2y ago
  State management is absolutely a real front end concern. That's what you're going to be spending a lot of your time on; you better make sure you do it well. Code style is roughly a solved problem thanks to Prettier, as is build steps with Vite. And I don't know what you mean that "framework madness" is a fashion concern. You have to pick a framework, you can't just avoid that part.
johnfn 2y ago
What does this have to do with frontend work? Major version updates are common across any part of the stack. Just off the top of my head, SQLAlchemy has a seven step migration process[1] from 1.4 to 2.0, and it's absolutely not the kind of thing you could pull off in a few days if your code base has grown past a certain size. [1]: https://docs.sqlalchemy.org/en/20/changelog/migration_20.html https://docs.sqlalchemy.org/en/20/changelog/migration_20.htm...
- deleted 2y ago
  [deleted]
afavour 2y ago
Honestly it’s exhausting seeing endless posts from people who don’t do frontend development saying “wow, looks awful!” having made zero effort to actually understand the scenario. > They seem to have no respect for peoples time or any consideration for longtermism or even just the common decency of backwards compatibility You mean Svelte 5, the backwards compatible framework that makes all of its new features an optional opt-in? That one? > What are we at now, React 19? Allow me to introduce you to the concept of semantic versioning, otherwise known as “a versioning system that has defined meaning”. Any breaking change means a new major version, which is why the numbers increment at a rate that is apparently terrifying. These breaking changes are often absolutely tiny and trivial to adapt to. I don’t even like React but the upgrade path between major versions is rarely a big deal. You’re taking a non-semantic versioning mindset (new version number? Guess I have to rewrite everything!!) and applying it in a scenario where it doesn’t fit.
- jauntywundrkind 2y ago
  > Honestly it’s exhausting seeing endless posts from people who don’t do frontend development saying “wow, looks awful!” having made zero effort to actually understand the scenario. There's much bigger topics afoot in the world that also make me think humanity desperately needs better tools to defend & equip ourselves with broadscale collaborative efforts to shut down & reject-by-default negative-valence posts. The hater-squad has the easiest job on the planet attracting some fellow people who also want to resist learning, change, or who want to feel more secure in their current position. The Dark Side is strong.
- zx0r 2y ago
  > Honestly it’s exhausting seeing endless posts from people who don’t do frontend development saying “wow, looks awful!” having made zero effort to actually understand the scenario. Inevitably we will see it in every front-end related thread until the end of time.
morsecodist 2y ago
There is really no place where updating dependencies is dramatically better. Back end frameworks and even whole languages have this problem. On the front end, I mostly use React and it has been fairly backwards compatible. It's a tradeoff. If you never ever make breaking changes you can end up constrained by previous design decisions. If you make them all the time users won't be able to keep up.
- smt88 2y ago
  > There is really no place where updating dependencies is dramatically better This is absolutely untrue. There's a huge gap in how easy it is to upgrade some stacks vs. others. Updating dependencies in a language with strong, static types and/or an expressive type system is incredibly easy, for example: Step 1: update dependencies Step 2: fix compiler errors Upgrading major versions of .NET, for example, sometimes requires no work at all. This is not true in JavaScript, Python, and some other languages where you're only going to discover issues during runtime. TypeScript makes things a lot better, but you're relying on the authors of your dependencies either using TypeScript or keeping types up to date.
  - morsecodist 2y ago
    I was a bit broad here. I am sure certain projects get things better than others. When I said no place I was more referring to whole categories of development like, front-end, back-end, embedded, data pipelines, ect... I love types and advocate their use whenever possible. They help a lot but they are a spectrum. Thanks to static analysis tools like TypeScript or even eslint you can get a bit towards automated checks on front end code. Also even compiled languages can miss some things, different languages have type systems that give you different kinds of guarantees. For example, Java has NPEs that can't be caught at compile time.
  - KronisLV 2y ago
    > There's a huge gap in how easy it is to upgrade some stacks vs. others. This I can agree with. > Updating dependencies in a language with strong, static types and/or an expressive type system is incredibly easy Java would typically be regarded a pretty close to .NET in regards to its type system, yet I've seen plenty of issues with updating dependencies, whenever you have any sort of dynamic class loading or reflection going on: be it Lombok or MapStruct not liking a specific version of Java, or Spring Boot or one of its many integrations throwing errors during startup after a successful compile, sometimes even disliking specific annotations that worked previously. A decent type system will help you make sure that the code compiles, sure (and I'm thankful for that), but with some styles of writing code and handling, for example, dependency injection, all bets are off. The same goes for any dependencies that make liberal use of those features. I'd have to dig around for specific examples, but I know for a fact that there are plenty of projects that are stuck on old versions of Spring for that very reason. Or the fact that there are plenty of pre-.NET Core projects out there that won't be upgraded to anything new anytime soon for similar reasons. In my experience, updates suck across the board, the only variable is how much. And that applies to everything not just dependencies in code (and runtimes): I've also had seemingly innocuous Debian updates break GRUB and prevent the OS from booting, or even upgrades making exim4 start up for some reason and taking up the port that my mail server needed, preventing it from starting.
dustingetz 2y ago
developers get what they pay for. When one values their time at zero, vendors also value it at zero.
raincole 2y ago
> You're telling me you updated YOUR code to work with the latest framework release? Next time I'll tell you how people used to update their code to use Python 3! Shocky-shocky.
- procaryote 2y ago
  That was also an obviously terrible idea, iirc to the point even python leadership aims to never do it again
  - Capricorn2481 2y ago
    And yet Scala did it next. And both were dramatically worse than what is happening here. Just frontend FUD
sergiotapia 2y ago
That's javascript ecosystem in general. A revolving door of breaking changes and yet another web framework. Not to mention many many many tiny libraries. To give you a simple example. "What's the best web framework these days for fullstack JS work?" Ok, Hono, found that. Installed it, great, it even runs well with Bun. Holy shit, it seems like JS is catching up! But now how do I talk to my database? Hono has no such thing, you're on your own. Ok, let's use Prisma but setting that up there is no one-true-way, it's all blog posts and praying you followed the right one. Also Prisma seems to now work with joins? Migrations? You set that up manually. Deploying is another story. Very painful. --- Compare to Laravel, Rails or Phoenix. All these things baked in, one blessed paved road to tackle the common things 99.9% of web apps need. We are blessed to have all this great work for free, right at our fingertips. People donated a lot of time and love into building them. I hope javascript one day reaches that level. It's still cowboyitis out there.
- zx0r 2y ago
  > Ok, Hono, found that. Weird that you went with some framework I've never heard of, and that definitely does not come up when I google for best fullstack JS framework. > Ok, let's use Prisma but setting that up there is no one-true-way Maybe the docs? https://www.prisma.io/docs/getting-started https://www.prisma.io/docs/getting-started > Deploying is another story. I mean deployment always brings some complexity, but for the majority of JS frameworks you can get started by building it, throwing it in a docker container, and hosting that somewhere. I don't see what's difficult about that
- madeofpalk 2y ago
  I've never heard of any of these tools. Maybe you should be more critical of the answers you get? I've been sitting here as a react developer, quite stagnent in my toolset, using the same React I've been writing since 2015. The 'newest' technology I picked up was Typescript back in 2019.
deleted 2y ago
[deleted]
mardifoufs 2y ago
React has been almost fully backwards compatible going back to version 1. If you have react code that worked 10 years ago it will almost certainly still work just fine right now. That's more than a lot of other platforms. Higher number doesn't mean less backwards compatible.
madeofpalk 2y ago
"What are we at now, Ubuntu 24?" For what it's worth, between 2011 and 2016, React shipped versions 0.0.1 to 0.14.0. Then in 2016 they said "fuck it, we're stable now" and jumped immediately to 15.0.0 (they considered 0.14.0 to be mostly equal to 14.0.0). Then they did 16 in 2017, 17 in 2020, 18 in 2022, and 19 finally in Dec 2024. I don't think 4 major versions in ~9 years is a world breaking amount of churn. I have my problems with the team's development of React, but I think they have a pretty sensible view of breaking changes and limiting churn.
conradfr 2y ago
Personally I've picked Vue over React like height years ago and it's been mostly great, never regretted it. Also StimulusJS and htmx are good for simple cases as long as you don't need a global state IMHO.

wetpaws 2y ago

[dead]

golergka 2y ago

> You're telling me you updated YOUR code to work with the latest framework release? I work on frontend right now, but I've worked on backend earlier, as well as gamedev and desktop applications. And it was always like that in every area: when your major dependency has a major version upgrade, you will have to spend effort on migrating your code to support it.

bastardoperator 2y ago
It a software problem, not a frontend/backend problem. We've all been subjected this insanity in some way.
- int_19h 2y ago
  Its severity varies between ecosystems, though, and JavaScript is especially crazy in this regard. Frontend JS, doubly so.
fiddlerwoaroof 2y ago
The issue I had when I still worked in the frontend world is the frequency of major version updates. If you used standard project bootstrapping tools in approximately 2017, you got a whole bunch of libraries and tools that would have significant breaking changes multiple times over the next three years or so (I know because I had to maintain them).
2mlWQbCK 2y ago
That seems to be a problem that is getting worse with time though, with increasingly frequent "major" releases and fewer that consider backwards compatibility much at all. Also it used to be much more common to have published specs and standards that you could code to for a good chance to not have to rewrite your code next month.
leosarev 2y ago
Except usual time to upgrade to next version of .net is less than man day.

striking 2y ago

> What are we at now, Rails 8? Is it just a reason to keep people employed?

bdcravens 2y ago
8 major releases over 20 years vs 19 over 10.
- mardifoufs 2y ago
  Yet react 19 is almost (except for some edge cases that only affect very specific stuff) fully compatible with version 1. Try running a rails 3 app on rails 8 or vice versa.
- morcus 2y ago
  The React versioning is a bit silly, but React 15 was the first major version (in 2016) which makes it more like 4 major releases in 9 years. Not that different from 8 major releases over 20 years.

sieabahlpark 2y ago

Tailwind v4 just gave everyone who uses sass the middle finger. It's rampant in the front end to rewrite because it's actually a solved problem. They need to explain their salary by reinventing constantly..

voat 2y ago

No one is forcing you to upgrade, Svelte 4 still works just fine? Svelte has had basically no major API changes since 2019, that's a better part of a decade. And with this new architecture change, they released a sophisticated codemod to do most of the work of updating for you.

KTibow 2y ago
In fact, you can still use Svelte 4-style components with Svelte 5, even in the same project.
cube00 2y ago
Great until your dependency scanner picks up a vulnerability in the framework or a dependency that can't be upgraded without breaking v4, no exemptions can be given and the only updated version is 5. [1] [1] https://endoflife.date/svelte https://endoflife.date/svelte
- Capricorn2481 2y ago
  If it's already end of life you can fork it and upgrade the dependency. You'll miss nothing. This is only difficult if you need to maintain changes upstream, but that's not the case here. Security support lifetimes make sense for a widely used language or runtime, but not really a frontend web framework on the most backwards compatible language you can have.

austin-cheney 2y ago

Front end development is a 90% self-induced hell. There are real challenges like accessibility, processing data from service calls, architecture, and more. Those aren't the things most developers complain about. Most front end developers spend their energy on concerns of code style, tools, build steps, framework madness, state management, and more. Those are fashion concerns. A decent programmer can solve for most of those themselves without external tooling in a fraction of the time and code size, but not everybody that does this work is confident writing original code.

Etheryte 2y ago
I can't even begin to count the number of codebases I've seen where developers rolled with this idea and ended up with royal spaghetti. Everyone thinks they can build these frameworks from scratch, but they overlook the unknown unknowns. Nearly every custom implementation of state management, complex forms, async flow management, etc I've seen in the wild is riddled with countless bugs that could've been avoided if they just picked a boring and widely used library. And I've seen plenty, because I'm usually the guy that gets called up when no one else can untangle it anymore.
- austin-cheney 2y ago
  Yes, I have seen that countless times too. Developers that have no idea how to write original software think they can go without a framework and then write a framework. That is stupid, and its because those developers know something about frameworks but never learned to program. Stop toying with irrelevant nonsense and actually release a product for users that solves from some real business requirement, which is certainly not a framework.
johnfn 2y ago
State management is absolutely a real front end concern. That's what you're going to be spending a lot of your time on; you better make sure you do it well. Code style is roughly a solved problem thanks to Prettier, as is build steps with Vite. And I don't know what you mean that "framework madness" is a fashion concern. You have to pick a framework, you can't just avoid that part.

johnfn 2y ago

What does this have to do with frontend work? Major version updates are common across any part of the stack. Just off the top of my head, SQLAlchemy has a seven step migration process[1] from 1.4 to 2.0, and it's absolutely not the kind of thing you could pull off in a few days if your code base has grown past a certain size. [1]: https://docs.sqlalchemy.org/en/20/changelog/migration_20.html https://docs.sqlalchemy.org/en/20/changelog/migration_20.htm...

deleted 2y ago
[deleted]

afavour 2y ago

Honestly it’s exhausting seeing endless posts from people who don’t do frontend development saying “wow, looks awful!” having made zero effort to actually understand the scenario. > They seem to have no respect for peoples time or any consideration for longtermism or even just the common decency of backwards compatibility You mean Svelte 5, the backwards compatible framework that makes all of its new features an optional opt-in? That one? > What are we at now, React 19? Allow me to introduce you to the concept of semantic versioning, otherwise known as “a versioning system that has defined meaning”. Any breaking change means a new major version, which is why the numbers increment at a rate that is apparently terrifying. These breaking changes are often absolutely tiny and trivial to adapt to. I don’t even like React but the upgrade path between major versions is rarely a big deal. You’re taking a non-semantic versioning mindset (new version number? Guess I have to rewrite everything!!) and applying it in a scenario where it doesn’t fit.

jauntywundrkind 2y ago
> Honestly it’s exhausting seeing endless posts from people who don’t do frontend development saying “wow, looks awful!” having made zero effort to actually understand the scenario. There's much bigger topics afoot in the world that also make me think humanity desperately needs better tools to defend & equip ourselves with broadscale collaborative efforts to shut down & reject-by-default negative-valence posts. The hater-squad has the easiest job on the planet attracting some fellow people who also want to resist learning, change, or who want to feel more secure in their current position. The Dark Side is strong.
zx0r 2y ago
> Honestly it’s exhausting seeing endless posts from people who don’t do frontend development saying “wow, looks awful!” having made zero effort to actually understand the scenario. Inevitably we will see it in every front-end related thread until the end of time.

morsecodist 2y ago

There is really no place where updating dependencies is dramatically better. Back end frameworks and even whole languages have this problem. On the front end, I mostly use React and it has been fairly backwards compatible. It's a tradeoff. If you never ever make breaking changes you can end up constrained by previous design decisions. If you make them all the time users won't be able to keep up.

smt88 2y ago
> There is really no place where updating dependencies is dramatically better This is absolutely untrue. There's a huge gap in how easy it is to upgrade some stacks vs. others. Updating dependencies in a language with strong, static types and/or an expressive type system is incredibly easy, for example: Step 1: update dependencies Step 2: fix compiler errors Upgrading major versions of .NET, for example, sometimes requires no work at all. This is not true in JavaScript, Python, and some other languages where you're only going to discover issues during runtime. TypeScript makes things a lot better, but you're relying on the authors of your dependencies either using TypeScript or keeping types up to date.
- morsecodist 2y ago
  I was a bit broad here. I am sure certain projects get things better than others. When I said no place I was more referring to whole categories of development like, front-end, back-end, embedded, data pipelines, ect... I love types and advocate their use whenever possible. They help a lot but they are a spectrum. Thanks to static analysis tools like TypeScript or even eslint you can get a bit towards automated checks on front end code. Also even compiled languages can miss some things, different languages have type systems that give you different kinds of guarantees. For example, Java has NPEs that can't be caught at compile time.
- KronisLV 2y ago
  > There's a huge gap in how easy it is to upgrade some stacks vs. others. This I can agree with. > Updating dependencies in a language with strong, static types and/or an expressive type system is incredibly easy Java would typically be regarded a pretty close to .NET in regards to its type system, yet I've seen plenty of issues with updating dependencies, whenever you have any sort of dynamic class loading or reflection going on: be it Lombok or MapStruct not liking a specific version of Java, or Spring Boot or one of its many integrations throwing errors during startup after a successful compile, sometimes even disliking specific annotations that worked previously. A decent type system will help you make sure that the code compiles, sure (and I'm thankful for that), but with some styles of writing code and handling, for example, dependency injection, all bets are off. The same goes for any dependencies that make liberal use of those features. I'd have to dig around for specific examples, but I know for a fact that there are plenty of projects that are stuck on old versions of Spring for that very reason. Or the fact that there are plenty of pre-.NET Core projects out there that won't be upgraded to anything new anytime soon for similar reasons. In my experience, updates suck across the board, the only variable is how much. And that applies to everything not just dependencies in code (and runtimes): I've also had seemingly innocuous Debian updates break GRUB and prevent the OS from booting, or even upgrades making exim4 start up for some reason and taking up the port that my mail server needed, preventing it from starting.

dustingetz 2y ago

developers get what they pay for. When one values their time at zero, vendors also value it at zero.

raincole 2y ago

> You're telling me you updated YOUR code to work with the latest framework release? Next time I'll tell you how people used to update their code to use Python 3! Shocky-shocky.

procaryote 2y ago
That was also an obviously terrible idea, iirc to the point even python leadership aims to never do it again
- Capricorn2481 2y ago
  And yet Scala did it next. And both were dramatically worse than what is happening here. Just frontend FUD

sergiotapia 2y ago

That's javascript ecosystem in general. A revolving door of breaking changes and yet another web framework. Not to mention many many many tiny libraries. To give you a simple example. "What's the best web framework these days for fullstack JS work?" Ok, Hono, found that. Installed it, great, it even runs well with Bun. Holy shit, it seems like JS is catching up! But now how do I talk to my database? Hono has no such thing, you're on your own. Ok, let's use Prisma but setting that up there is no one-true-way, it's all blog posts and praying you followed the right one. Also Prisma seems to now work with joins? Migrations? You set that up manually. Deploying is another story. Very painful. --- Compare to Laravel, Rails or Phoenix. All these things baked in, one blessed paved road to tackle the common things 99.9% of web apps need. We are blessed to have all this great work for free, right at our fingertips. People donated a lot of time and love into building them. I hope javascript one day reaches that level. It's still cowboyitis out there.

zx0r 2y ago
> Ok, Hono, found that. Weird that you went with some framework I've never heard of, and that definitely does not come up when I google for best fullstack JS framework. > Ok, let's use Prisma but setting that up there is no one-true-way Maybe the docs? https://www.prisma.io/docs/getting-started https://www.prisma.io/docs/getting-started > Deploying is another story. I mean deployment always brings some complexity, but for the majority of JS frameworks you can get started by building it, throwing it in a docker container, and hosting that somewhere. I don't see what's difficult about that
madeofpalk 2y ago
I've never heard of any of these tools. Maybe you should be more critical of the answers you get? I've been sitting here as a react developer, quite stagnent in my toolset, using the same React I've been writing since 2015. The 'newest' technology I picked up was Typescript back in 2019.

deleted 2y ago

[deleted]

mardifoufs 2y ago

React has been almost fully backwards compatible going back to version 1. If you have react code that worked 10 years ago it will almost certainly still work just fine right now. That's more than a lot of other platforms. Higher number doesn't mean less backwards compatible.

madeofpalk 2y ago

"What are we at now, Ubuntu 24?" For what it's worth, between 2011 and 2016, React shipped versions 0.0.1 to 0.14.0. Then in 2016 they said "fuck it, we're stable now" and jumped immediately to 15.0.0 (they considered 0.14.0 to be mostly equal to 14.0.0). Then they did 16 in 2017, 17 in 2020, 18 in 2022, and 19 finally in Dec 2024. I don't think 4 major versions in ~9 years is a world breaking amount of churn. I have my problems with the team's development of React, but I think they have a pretty sensible view of breaking changes and limiting churn.

conradfr 2y ago

Personally I've picked Vue over React like height years ago and it's been mostly great, never regretted it. Also StimulusJS and htmx are good for simple cases as long as you don't need a global state IMHO.