Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Migrating from svelte to <next flavor of the month> when


Meanwhile React will continue succeeding the test of time


I learned React almost a decade ago and never looked back. Multiple SaaS apps and dozens of personal projects later, I feel no need to reach for anything else.


i just think vercel made a very smart move hedging their bets among the big 4 major frameworks, so no matter what wins they still win


React is on the downfall because of NON-functional hooks. API becoming too large and the direction is unclear - at least to me.



I like React and I'll admit that I resisted React at first, mainly due to JSX and workflow purposes. We had teams that could do CSS/HTML very well and those that were more capable in JS. There was a gap in skills. And taking the design files into HTML/CSS, testing the bulk of it and THEN adding dynamic functionality and JS was a good flow.

This was also many years ago, where we had - let's build apps mainly with HTML/CSS and sprinkle in some JS framework sugar and dynamic capability on the client side. Ok, Angular/Ember and then Vue worked VERY well. We made a hop from jQuery to more sophistication but still easy to read and develop compelling and maintainable, interactive frontends. Then we did SPAs which worked well for a few things but were vastly oversold.

React came along which was nice, but early on, it was not needed for many projects even though many devs started implementing it.

We had a demand for more rich web apps and they got MORE complex and dynamic. We decided, maybe we shouldn't sprinkle in all these sugary JS framework tags and corresponding logic in our HTML.

Then we had a ton more university-educated programmers entering the frontend scene that used to just be comprised of a megaton of jQuery heroes (no offense, they got shit done and went out to lunch most days while the more sophisticated frontend devs went hardcore on semantic HTML/CSS, VanillaJS, spending countless hours on browser bugs and QA cycles and using divs to render tabular data for fun/ego?).

We also got more interest in React from non full-time frontend devs (ex: fullstack and even backend devs) that were like, hey building frontend doesn't suck like it used to in VanillaJS! Count me in!

Coupled with the Stackoverflow copy-paste dev era and the nightmarish third party library upgrade scenarios... now we have a TON of shitty React codebases and people have, and will, migrate away from them. This cycle I'm describing gives rise to challengers like Svelte.

I like React (and React Native), but the many codebases I've inherited have not been good. In fact, I've probably inherited as many decent React codebases as decent jQuery codebases but what does that say? Not much because I haven't inherited many good examples of either.

I'll still choose inheriting a shitty React project over a shitty jQuery project any day. Great progress has been made (although you could argue much of the progress was in cross-browser standards and advancements in browser technology).

But I still feel like the truth that everything that is old becomes new again cannot be avoided.

And in that - it's web components and/or more HTML sprinkled JS frameworks for the win to me. I haven't used Svelte, although some on my team like it, but it looks like a return to a get-shit-done dynamic websites/apps framework.

And I'll likely still continue using React for larger, more rich and dynamic apps that require a larger dev team.


Totally agree with you that now that React has matured, I have dealt with a ton of shitty React codebases because it really is more of a library that doesn't inform you how to architect your app and thus lots of folks went in completely different directions. Additionally because some of the pitfalls of React can be unintuitive, it is tough to unravel these in a larger codebase.

However, I will say it has been much easier to make updates to bad React codebases than a bad jQuery codebase. The way React works tend to make it less difficult to reason about even if the app is poorly built.


As will Angular lol


This. For me product velocity and producing value fast for customers is always top priority. Migrating from state of the art framework #1 to state of the art framework #2 seems wild.


When the CTO tries to ride waves.


Is six years old framework "flavor of the month"?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: