Hacker News Reader

Excellent observation. This right here is what a senior frontend engineer, that has gone through a couple rewrites and hype cycles, looks like.

The fact that they used a popularity contest as justification is laughable: if you have more than 3 years in the field you have experienced the pattern that the new kid on the block, often untested and with smaller mind share, jumps to the top of any "which framework would you like to try next?" surveys, while the tried and tested one move towards the bottom.

https://emtemp.gcom.cloud/ngw/globalassets/en/research/image...

No stable and productive framework will ever be able to compete in hype and good PR than alpha-quality software.

> No stable and productive framework will ever be able to compete in hype and good PR than alpha-quality software.

Huh? Stable and productive tools will let developers ship features while hyped frameworks come and go. Whatever survives and is in good shape after multiple hype cycles is surely a winner.

I get it. Yes, stable and productive frameworks would win out in a fair fight, but it isn't a fair fight. The warts in the stable, productive framework are known, and there's already mid-level devs with battle scars that are clamoring for something better than the stable, productive framework.

The alpha-quality software is all new shininess, sometimes with explicit promises of solving the warts of [STABLE FRAMEWORK]. Plus everybody seems to think that new shininess looks better on a resume.

I do not disagree. I meant that alpha software has fewer detractors, for the simple reason that few have actually used it for something serious and hit their head against all the bugs and shortcomings. On the hype metric alone, stable software just can't compete.

"There are only two kinds of languages^Hframeworks: the ones people complain about and the ones nobody uses."

Seems like a rewrite for the sake of a rewrite. New frameworks are exciting but if you're building a product you have to realize that's not important to your customers.

Sure if you were on PHP, a rewrite to a JS framework would be worth it, because you could deliver features to your customers faster, less bugs, etc. But once you're in the JS ecosystem, it gets much harder to justify a lateral migration like that. Like what features have they actually picked up as a result of the migration? Or are they just doing it so they can work on flashy new framework? I'm going to guess the latter.

> Sure if you were on PHP, a rewrite to a JS framework would be worth it, because you could deliver features to your customers faster, less bugs, etc.

That sounds just as much like a cargo cult thing and not actually making sense.

In what way is being on Vue 2 painful? Using it in production, zero problems, everyone understands it, does everything we need.

Plan to migrate to Vue 3 for the nice to haves and to keep up to date, but Vue 2 is not painful at all.

Considered React but I think Vue will be more productive for the team as a whole in the long term. Vue is more intuitive, better designed, and structured. But totally understand React has a larger ecosystem - we’ll just be building more stuff in house so understanding our own code will be more important than having a larger choice of dependencies.

Did take a look at Svelte, agree with you.

I understood it as “migrating to Vue 3 is no more painful than staying on Vue 2”.

Isn't the reasoning to migrate literally the first sentence in the blog post?

> After using Vue 2 as our front-end framework for almost two years, it was announced that this support would no longer be maintained,

Eg. some teams don't want their development to happen on a framework with no support from the devs that wrote it.

As someone working in a large Vue 2 app:

- Very poor typescript support.

- Poor performance (compared to Vue 3).

- Ecosystem has already started lagging behind (e.g. Vue Testing Library for v2 has out of date dependencies, and no one is actively maintaining it)

- Nuxt 2 hasn't made any releases in ages.

- Nuxt only matter if you want to use it, is not Vues problem, because you talking about another software which addresses a different problem. - Typescript support is only a problem if you want to use Typescript, imagine, there is also a world beyond TS. - Performance, often a matter of design and understanding your framework

> - Very poor typescript support.

If you use class components and prop decorators, the TS support is actually pretty nice. Kinda boilerplate heavy, but nice.

I really enjoyed using these tools, it felt idiomatic to have a class per component with props and data as fields on the class - but it seems like there's now no upgrade path for us folks in Vue 3 land.

I used those too, but it makes the upgrade to Vue 3 quite a bit harder.

I've worked professionally in both Vue 2 and React. Even with class components and prop decorators you still have the annoying Vue template DSL where you don't get any TS support.

In comparison JSX will be checked by typescript, so in that regard JSX (and therefore React) is superior.

Composition API has the best Typescript support available in Vue 2. It's supported out of the box in 2.7, and a plugin in previous versions. The decorator syntax is unsupported in Vue 3 and shouldn't be used.

> - Nuxt 2 hasn't made any releases in ages.

FWIW, Nuxt 3 was released in November. https://nuxt.com/v3

Note: used Vue 2 and 3 with JavaScript instead of TypeScript, so cannot comment on the latter.

Personally, I rather enjoy the <script setup> syntax in Vue 3 which makes using the Composition API more pleasant and makes it feel more like React, instead of something more boilerplate heavy: https://vuejs.org/api/sfc-script-setup.html

Of course, Composition API itself is also available in Vue 2 (at least the newer versions) as a plugin, but personally I didn't see anyone using it in the older version. Either way, it can make code easier to write!

Furthermore, starting out new projects, regardless of which version you use, Pinia is a great option, which you won't see in many of the older Vue 2 projects (but could use if you started a new one with Vue 2, although that's not a good option because of EOL): https://pinia.vuejs.org/

Aside from that, Vue 3 still lacks some component library support in some cases, last I checked so perhaps that's an argument in Vue 2's favor (until everything is updated): https://news.ycombinator.com/item?id=32916677

React feels good in some cases, for example thanks to new solutions like https://react-query-v3.tanstack.com/ but at the same time seems to be getting more overcomplicated as time goes on (Vue feels like it does hooks in a more clean way, you don't need to deal with the complexity of Redux either).

The last React + TypeScript codebase that I looked at felt like it's just going to slow down anyone who works with it, which seemed to be true, judging on how fast people iterated with it vs a Vue project. Note: that's an anecdote.

Then again, the only good front end technology with TypeScript that I've used was Angular, even though it crumbled under its weight otherwise sometimes (once again, in regards to iteration speed in particular).

> React + TypeScript [...] anecdote

I agree that that combination it is very ceremonial.

We now doing new projects in Elm as the JS/TS ecosystem simply does not cut it for me.

Wise choice, but it brings along with it the curse of Plato’s Cave.

To some a curse, to some enlightenment. :)

In my experience React + TypeScript is a match made in heaven. You are basically writing pure TypeScript in TSX.

It certainly isn't bad and is my first choice. But, do you have a deep understanding of how React's rendering model works in all edge cases? Because that part really isn't heaven for me. Feels more like trying to navigate a minefield.

I don't and can see how in edge case scenario's one can run into discrepancies between Reacts typings and advanced edge case workarounds. Especially since React itself isn't written in TypeScript.

> In what way is being on Vue 2 painful? Using it in production, zero problems, everyone understands it, does everything we need.

I think others have offered sufficient/agreeable takes on this, but as the OP, I'll firstly point the pain finger at our own development and blame far too much state/ui/biz logic existing in the web in very tangled and inappropriate ways (part of the nightmare I inherited). Beyond that, the actual vue2-related pain points are typically ecosystem-related support (packages, etc.), and specifically being able to adapt to typescript (this project was initially done in early vue 2.x with just javascript, and attempting to reimplement in typescript to address some of our pain was not fun)

SvelteKit (a meta framework) is still not at 1.0, but Svelte itself is at 3.53 and mature and stable. We've used it production for several apps (moving from React). It's been a joy to work with.

SvelteKit isn't Svelte's UI framework. SvelteKit is a full web framework for serving Svelte apps. It's essentially Sapper + Svelte in a more harmonious combination.

I have no opinions about any of these libraries and frameworks for business applications.

SvelteKit is going ot be Django/Ruby on Rails of frontend frameworks. Due to integration and polish, it is so much easier to use than anything I have developed with on Angular, React and even older stacks like jQuery.

How is typescript support? I found that a bit lacking when I was using Svelte (and I otherwise love svelte)

Typescript support in Svelte is one of the biggest problems with the framework I’ve encountered. We have a couple of production Svelte apps at my job and overall the frontend DX is excellent. However, not being able to use generically typed components is a big missing feature. We have a number of custom core components which work really well, but not being able to create a new component with something like MyTable = Table<User> feels like an oversight. Inside of the Table code we work around this shortcoming to appease tslint…

Overall though regular .ts code works well. We use it for all our API definitions and networking layer, and it’s been 1000x better than our former version built with jinja/jQuery.

I may be missing something (I haven't used Svelte, SvelteKit, or TypeScript much), this doesn't seem accurate. I was going to link to a direct example, but I'm not sure I understand exactly what you're looking for. More information here: https://github.com/ivanhofer/sveltekit-typescript-showcase

I added some more information in another reply, but Svelte has officially supported TypeScript for a couple years now. It provides some tooling to get started and there are also existing projects that may make certain things easier or more useful.

Announcement (some things have changed, surely): https://svelte.dev/blog/svelte-and-typescript

More info in the GitHub repo I linked to elsewhere.

> SvelteKit is going ot be Django/Ruby on Rails of frontend frameworks.

I use it for my production app, so I'm a big supporter, but I don't think this is true. It's an extremely light framework that doesn't offer anywhere close to the feature support of Django or Rails, and as far as I'm aware it doesn't have any intention of doing so. Perhaps I'm mistaken?

I'm not saying it's the same (like you said, Svelte isn't at 1.0) but don't you feel like there's at least a little irony in saying the post stinks of justifying someone just wanting to try out something different when you're currently chucking a Vue 2 app for React?

Reading your post it doesn't sound like you're fully onboard with that jump anyway? (Maybe I'm reading too far with this though).

Correction, Svelte is already passed 1.0. It's Svelte kit that's not at 1.0 yet (hopefully in a few weeks tho)

React is not really a new hotness anymore though.

Imo, makes it the best bet for building anything.

There's still a new JS framework everyday but if you ignore all that noise and for production-quality software just have a look at React and the most popular meta framework on it, Next.js, you'll be more than alright.

Next.js is not a good general purpose React framework. It is good for static sites with sparse dynamic pages but nothing more complex. And the documentation is still woefully inadequate.

Don't be like me, choosing to build an entire app on Next.js and hating every moment of it after the honeymoon period ended 2 weeks in. Live and learn.

What do you recommend instead (or are looking at)?

Sorry, I wouldn't know. I got out the frontend world after that experience, and I don't think I've seen any solid answer yet.

Can I ask how long you ended up using Next for? Did you quit frontend dev after 2 weeks, or only after working through the challenges etc.?

My Next honeymoon has been going on for a couple years now, and I think it's an AMAZING developer experience compared to anything I've worked with before (Perl/PHP/Laravel/Symfony/Angular/jQuery/React)... it's the framework that made me choose to specialize in frontend because it was so nice. What didn't work for you?

I designed and led that project for 3 years. The technology choice was mine, so it was a learning experience. Frontend was something I did alongside the rest of the stack, but I've seen so many terrible libraries by inexperienced developers come and go post jQuery, I actively avoid frontend-focused roles now.

> I've seen so many terrible libraries by inexperienced developers come and go post jQuery, I actively avoid frontend-focused roles now.

I don't blame you, heh. Every year I feel like the fragmentation is getting worse, not better. It's fun for a while, but makes it really hard to plan for long-term stability and maintainability. It's likely anything I write today will be unusable in 2 years.

I am still annoyed I took the time to learn Webpack and its overly complex configuration a few years back, and the world has already forgotten all about it. There definitely is the feeling that learning a new frontend library is a terrible use of your time.

Hey there, I'm on the Next.js team. Sorry about this experience. I would argue Next.js is a general purpose React framework – we enable you to take advantage of all the latest React features. Apologies if there was a gap in the documentation. Could you share more so we can improve? You can also email lee at vercel dot com.

You might be much more experienced than me so feel free to discard my suggestions if you objectively know you're right.

However, I would strongly disagree with you on the part about it not being suitable for complex applications.

If you feel that way, you can choose to have a decoupled backend (which is what I do with Django) or go all in with full-stack integrations (tRPC in conjunction with edge functions) on top of Next.js.

I have seen great apps built with both of those ideologies.

> [svelte] is utterly untenable for an actual product-serving business

This is an overstatement. Use what you want and what works for you, but we've been using Svelte in production for years and overall are extremely happy with it.

In general agreement with one caveat; Svelte is hardly new. Rich Harris was using it at NYT 4 years (at least) ago, and it's been open source since. It's caught on because of; a pushback against React, the surging popularity of Vue, the sudden popularity of Rollup (which has been around just as long, but adoption in Snowpack/Astro and Vite was a game changer), Rich being hired by Vercel and more weight behind Svelte. All of those things have gelled to create a popularity surge in the framework. I'd shy away from calling it the "new hotness," and simply bear in mind that it's just trending lately.

> Vue 3 is great, I highly recommend reacty-folks or frontend devs try it. We wanted the larger ecosystem (and boo to us for not being brave enough to support the growing vuecosystem).

I enjoy Vue 3 and I don't enjoy React, but like you this is the reason I keep heading back to React.

From tldraw [1] to react-flow [2] to the superb AtlasKit [3] to form builders & validators, the React ecosystem contains great stuff that isn't available off-the-shelf for other frameworks.

1. https://www.tldraw.dev/

2. https://reactflow.dev/

3. https://atlaskit.atlassian.com/ (seriously, table handling in the RTE is excellent)

Have you seen https://vueflow.dev/

No I hadn't, thank you for sharing!

Wowowow stop.. last time I seriously looked aeons ago (4 or 5 years? :D) there was Vue as the nice smaller thing as an alternative React.. besides some other few bigger names. Noe Vue2, and Vue3? That didn't age well? And Svelte?

Omg, doing (because I need to) C or C++ stuff, where you have (or lets say you are bound to for several reasons, compatibility, regulations,..) C++11.. or even C99 .. man I feel so old and slow as I potentially am, lol.

You don't know how good you have it to work on the backend (and I don't mean Node).

Trust me, the grass ain't greener on the other side.

Spotty support for C++17/C++20 is very annoying. Maybe if you stick to one platform and one language edition on one compiler you'll have a nice and stable C++ experience, but that's no different from Javascript. We adopt new things because we want better things, having some of those things fail or quickly deprecate is a risk that comes with that territory.

BTW just a snarky aside, but I've never seen any of the Javascript frameworks make as bad design decisions as the C++11/C++14 standards committees have. At least when you use a one-day-fly JS framework you'll use something that was actually designed with a grain of intelligence.

React and vue are still going along.

Vue 3 was a big shift, like react hooks. It will take some time for community to stop whining about it, and accept old version is legacy like react classes

> The framework is so new

Just a note: Svelte is 6 years old, only 2 years younger than Vue. Both are definitely "old" on JS-framework timescales.

I think you probably can start using svelte/sveltekit for production development, depending on your timeline... the "svelte" part is mature, and sveltekit (the web app framework around svelte) is close to release according to their status report (feature complete, no more planned breaking changes)

It's a little risky, but not particularly so.

But I agree that vue3 is usually a much better migration path from vue2. Also, it seems outright bonkers to me to give major weight to the "State of JS" survey, and doubly so since the delta is small.

I migrated from vue 2 about 4 months ago seeking better typescript support and looking to move away from webpack. While I absolutely loved the simplicity and feel of svelte, I came to the same conclusion that it is not ready for a major production application yet. In a few years, I'm hoping vue setup scripts are as low friction as svelte or it may be time to switch over (they're close now, if you're using the latest macros, which may or may not be in beta still).

I've been writing operational apps with Svelte for over two years. I develop geospatial applications that make heavy use of WebGL. Haven't yet ran into any serious limitations. I keep things fairly simple and have been using tailwind the entire time. We had to fork a geospatial map framework (Cesium) to allow it to be loaded with Rollup.js as a simple javascript es6 module. But I wouldn't blame that on Svelte.

1) Vue 2: two years of support. Man.

2) we REALLY need a sort of "reference implementation" website that does the typical things a website needs to provide comparisons of approaches (hm, and performance benchmarks) to things like templating / html generation / data binding / etc.

I think Sate of JS is really useful, as long as you weight with User count, not just the percent of people that have liked the framework. Svelte is much too low in the actual usage for me personally to adopt.

> The former [svelte] is utterly untenable for an actual product-serving business - it is a pre-release, actively-developing product

I agree with this point. I also think that in terms of svelte-kit, the use-cases are pretty specific. I originally built https://neovimcraft.com using svelte-kit in an effort to learn the framework and see how useful it is.

I eventually ripped it out because all I needed was a static site generator and the framework felt like overkill and in some cases too magical:

https://github.com/neurosnap/neovimcraft/pull/201

Migrating from Vue2 to Vue3 is not that hard with the compat layer of Vue 3.1, it allows you to convert your code progressively.

I'll guess Vuex -> Pinia is more work.

I was annoyed when I found out vuex4 was pinia. But I followed the guide and converted over and was suprised it works without any bugs. (Except for my typos during the migration) turned out great and I love the simplified api.

Yes it's not that hard and different, but it can't really be done progressively.

Yeah, "We didn't consider React because it would have taken too much time to learn" doesn't sound very convincing to me.

Looks like we finally have a winner of the Frontend Wars.