Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from Vue 2 to Svelte

escape.tech

Post reply on HN
Print view View original

141–150 of 289 posts

Re: Migrating from Vue 2 to Svelte

#141

Post by miohtama »

beau_g wrote: post #18

Has anyone worked on a very large Svelte project yet? I work on a large React app in real life, but have been learning Svelte in my off time - there are some nice aspects like the out of the box state management, the syntax and structure is a bit easier to learn than React, but my intuition is a Svelte project would become unwieldy for a very complex app (React class components that are hundreds of lines long with do…

Our application frontend is in SvelteKit and open source.

We are hosting ~2.5 million pages.

You can find the code here: https://github.com/tradingstrategy-ai/frontend/

One one the latest additions for making managing large applications easier is folder based pages, with +page.ts and +page.svelte and all of their children compnents in the same folder.

Generally, folder based routing makes code much more manageable than React routing solutions, as React has too many solutions and is not enough opinionated for large projetcs.

Re: Migrating from Vue 2 to Svelte

#142

Post by pbowyer »

for1nner wrote: post #50

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…

> 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)

Re: Migrating from Vue 2 to Svelte

#143

Post by theN00t »

As someone who has helped a few companies change frameworks I can say with confidence that it all boils down to developer adhesion within the product teams more than anything the frameworks have to offer. If a few people don't get over their own personal biases they are likely to drag development time down even unintentionally, and the performance of the application will suffer from more shortcuts being made. A well written Vue2 app can be much more performant than a poorly written Svelte app. That said, here are a few observations I have made.

Vue2/3/Svelte is the easier frameworks for the widest range of developers to use and maintain apps for. This is because of their approach to templating VS that of React for instance, not to mention how they handle styling though Vue2/3 is even a rung above that of Svelte when it comes to CSS.

React is great if you want to convince the money people because they are more likely to have heard about it and how everyone is using it.

Svelte has a lot of odd bugs and associated hacks you have to figure out, such as looping over a list may sometimes not work at all and you need to place it within {# key} hack, this re-renders everything within the block though so it kills performance.

SvelteKit is unusable at this point, the routing system has undergone several major changes for example but there are constantly several breaking changes, DO NOT USE.

Vue3 typescript support is near perfect, I have had more problems getting full typescript support in Svelte and React.

Re: Migrating from Vue 2 to Svelte

#144

Post by dottedmag »

b112 wrote: post #87
nlnn wrote: post #77

As a primarily backend person, it's always interesting to read about this sort of thing as an outsider with little appreciation for the nuances/challenges people face using these frameworks. I keep hoping things will settle a bit more so that I can someday pick one to learn in depth without worrying about it being replaced by the next hotness. Am I right in thinking the state of major players is roughly: React - incu…

I keep hoping things will settle a bit more so that I can someday pick one You are in the wrong industry, to think this will happen any time soon. Change has been fast in computing, for decades. Stand still, and you are overrun and eventually your knowledge moves towards irrelevance. Doctors need to keep up to date with new medical information, new drugs, new warnings about drugs, new techniques. Lawyers need to read…

Frontend changes seem to be the changes for the sake of the changes.

Last time there was a meaningful major improvement is when React devs came up with practical implementation of view=f(model) idea.

Re: Migrating from Vue 2 to Svelte

#146

Post by laszlokorte »

yewenjie wrote: post #21

One huge thing that I feel nobody talks about about Svelte is that there is no easy way to pass components as props. Sure, there is slots and svelte:component but the ergonomics just don't match.

I see that as an advantage. Everytime I see components passed as props or a callback passed as child in react I regard it as a big red flag that something is wrong with the architecture of either the app or react itself.

Re: Migrating from Vue 2 to Svelte

#147

Post by rep_movsd »

I question the project heads for deciding to migrate rather than build a new product UI side by side with the existing from scratch.

Since 2014, we have done this several times

UI+backend went from [Cruddy coffeescript + Node.js] to [Jquery + django] to [React 15 + django] to [React 17 + django] and after we were acquired [AngularJS + django] is ongoing.

Backend has been python since the beggining.

Public API server went from python to golang.

Compute and Infra went from private baremetal to k8s.

At no point was there ever any already running code being refactored or framework updated.

We build an improved clone of what exists and plug it in after its been used by enough people in beta. We dont throw the old stuff away until new deployments are working on client premises under high loads and extreme usage.

We dont force clients to upgrade unless serious bug fixes exist.

We never change UI in a way that older customers have to do anything different - unless its a major feature upgrade.

Re: Migrating from Vue 2 to Svelte

#148

Post by dmitriid »

dmitriid wrote: post #134
azangru wrote: post #107

Earlier quoted context omitted.

> why you put SSR and web components in the same sentence Web components are a browser standard; so anyone thinking about the long haul for their web product would be well advised to think about web components as well. > web components are literally incompatible with SSR Declarative shadow DOM is an emerging browser standard that is literally compatible with SSR, and is already supported by Blink-based browsers.

> Web components are a browser standard; so anyone thinking about the long haul for their web product would be well advised to think about web components as well. It doesn't make it 1. a good standard, 2. a requirement, and 3. a viable standard to support There are countless issues with web components none of which are on any path to solution, they keep valiantly solving issues that only arise from introducing web co…

> The fact that it's available in Chrome (don't insult us by using the vague Blink-based browsers) means literally nothing. Because Chrome are well known for shipping half-baked Chrome-only non-standards just because they feel like it

Great example is Custom Elements V0: they shipped it, forced a Youtube re-write in it (well, in Polymer), literally no one else implemented it, they had to wait ~7 years to remove it from the browser because they had to wait for Youtube to re-write everything again in V1.

Great standards, and a bet on the future, I'm sure.

Re: Migrating from Vue 2 to Svelte

#149

Post by richeyryan »

swyx wrote: post #22

echos many of the same things i loved about svelte when i got involved in 2019: https://www.swyx.io/svelte-why people always call out the small community to be a downside, so a few of us started Svelte Society to fix that (very humble numbers compared to react, Rethinking Reactivity is probably the best starting point for most https://youtu.be/AdNJ3fydeao ). i actually think theres a “be careful what you wish for” as…

I find a lot of Svelte users are pretty religious and hysterically anti-React. When the first version of Svelte Query was announced, people were trashing the API because it looked like hooks and "you don't need those in Svelte", concluding the library must be useless. There's a lot of the "Svelte is the one true way" talk, similar to when Vue was the main alternative to React. The core team seem very reasonable but I think the community has some maturing to do.

Re: Migrating from Vue 2 to Svelte

#150

Post by andrewflnr »

Hawxy wrote: post #99
andrewflnr wrote: post #47

Earlier quoted context omitted.

Trivial is not the word I would use. My 2 -> 3 migration is a currently ongoing nightmare, even with the compat lib. I was using vue-class-component with typescript, which apparently... just doesn't work at all with Vue 3? And this isn't really documented, so I basically spent today digging around in Vue's guts with the debugger to prove there was no good way to salvage it for my code, I really just needed to rip it…

> vue-class-component with typescript I was using this but immediately saw the writing on the wall as soon as the Composition API came out with its far superior typescript support. Converted our greenfield Vue 2 app over to the new API within a few weeks which turned out to be the correct decision. Unfortunately, unless you were following Vue development very closely this would've slid by. Are you sure vue-class-comp…

I'm not going to rewrite everything to the composition API in the course of migrating. I want to get the app running, then start moving things over gradually. (I do like the look of it, FWIW. I'm hoping to use it to factor out some tricky UI stuff.)

On a distinct but similar note, I don't want to pull an "RC" into my migration, let alone one with no prospects of being maintained. I was already seeing scuttlebutt about deprecating it entirely. Removing it entirely had a much clearer and lower-risk path before it, if not a fun one.

Post reply on HN