The very first paragraph leads me to believe this is just a rewrite into svelte for the sake of it - I get it, Svelte is the new hotness on the FE-js-block, but this entire post stinks of "someone on the dev team advocated and fluffed enough figures to convince us. So now we're going to tell you why it was the right choice!" I say all this pretty confidently as someone currently maintaining a massive legacy vue2 app which we are currently rewriting into... *checks notes* React. Because we thoroughly vetted and PoC'd how we'd do it in Svelte and in Vue 3. The former is utterly untenable for an actual product-serving business - it is a pre-release, actively-developing product. 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).
The framework is so new, trying to justify your decision based on State of JS surveys over the last three years is asinine at best - svelte's own UI framework[1] is not even at 1.0 (has only recently been renamed to sveltekit).
Furthermore, there's a literal migration guide[2] to bring your app from vue 2 to 3. It's not easy. It's not painless. But being on vue 2 is equally painful. I'm also not sure what documentation or development this person is referring to because "restricted global access" is just patently false for both vue 2 and 3 - I don't even know what to cite here because it boggles my mind so thoroughly that I can't even conceive where you would come up with that "fact." Is this someone who's never opened their root app file? The place where one can pipe anything from decorators (and yes, enums???) to entire packages globally?
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.
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.
> 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."
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.
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.
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.
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 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
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).
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.
> 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?
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.
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).
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.
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.
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.
> [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.
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.
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.
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
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.
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:
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.
The framework is so new, trying to justify your decision based on State of JS surveys over the last three years is asinine at best - svelte's own UI framework[1] is not even at 1.0 (has only recently been renamed to sveltekit).
Furthermore, there's a literal migration guide[2] to bring your app from vue 2 to 3. It's not easy. It's not painless. But being on vue 2 is equally painful. I'm also not sure what documentation or development this person is referring to because "restricted global access" is just patently false for both vue 2 and 3 - I don't even know what to cite here because it boggles my mind so thoroughly that I can't even conceive where you would come up with that "fact." Is this someone who's never opened their root app file? The place where one can pipe anything from decorators (and yes, enums???) to entire packages globally?
[1] https://kit.svelte.dev [2] https://v3-migration.vuejs.org/