Live data from Hacker News

Migrating from Vue 2 to Svelte

escape.tech

241–250 of 289 posts

Re: Migrating from Vue 2 to Svelte

#241

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…

> [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.

Re: Migrating from Vue 2 to Svelte

#242
In most react codebases I've used, there's zero separation between business logic and code that touches react or redux. Meaning if you wanted to migrate, 95% of files would have to be re-written.

Do Vue codebases in the wild tend to be different? Or would this have been a massive undertaking as well?

Re: Migrating from Vue 2 to Svelte

#243

Svelte & SvelteKit has been wonderfully productive for me. It's a bit insane that I have adopted it across so many projects of mine despite the fact it is pre 1.0 (well that has more to do with me I guess), but I am just faster with it. I have used a lot of frontend frameworks over the years, and before SvelteKit Vue & Nuxt were what I was warming up to. The article really focused on measurable things like type check…

Ditto. It's my go-to for all new web projects - we just move so much quicker in it, and don't usually spend a whole lot of time thinking about it - most of the time, it just doesn't get in the way at all.

Re: Migrating from Vue 2 to Svelte

#244
post #31
post #7

Still don't understand why people prefer magic templated front-end frameworks. Reading non-standard HTML just sucks. What even is "$:" or why does Vue require non-standard javascript ref("") objects...

Because in many cases, manipulating the DOM with vanilla JS sucks way more than writing declarative code with a framework.

It's really not that bad. At least not in 2022. With the caveat that you can keep your UI (DOM manipulation) code from your business logic code. Which I'm sceptical of given the front-end code bases I've seen in the wild.

But no one writes blog posts about how Vanilla JS 2 is no longer supported so they had to migrate to Svelte :)

Re: Migrating from Vue 2 to Svelte

#245

It's ridiculous to me to read that for some people it is desired to have CSS, JS, and HTML in the same file. I would never consider it an improvement.

It's one of the things I love about svelte. Obviously global styles live in a separate place, but having scoped JS/CSS alongside the HTML its related to is a godsend, especially as a project grows.

Re: Migrating from Vue 2 to Svelte

#246
post #86

Earlier quoted context omitted.

As a backend person that used to be a front end person, there has never been a better time for using VanillaJS (or TypeScript), HTML, and CSS? > someday pick one to learn in depth without worrying about it being replaced by the next hotness So maybe the trick is to not use a framework. Like, I don't need a "framework" for backend dev, just a toolbox of good libraries. The tooling around TypeScript is similar to a bac…

If you’re working on a reasonably sized project “without a framework”, and haven’t effectively built your own, I’m very skeptical of the engineering practices at play.

Maybe Vue and Svelte are different. But something like react is "just a library", right? So they must be greenspunning their own framework as well, by their own admission.

So then ask yourself the question - which underlying tech of your in house framework is going to be more stable, supported, have better tooling, and be easier to reason about. I'd pick the DOM every time.

Re: Migrating from Vue 2 to Svelte

#247

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…

> 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

Re: Migrating from Vue 2 to Svelte

#248
post #196

Earlier quoted context omitted.

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?

Re: Migrating from Vue 2 to Svelte

#249

In most react codebases I've used, there's zero separation between business logic and code that touches react or redux. Meaning if you wanted to migrate, 95% of files would have to be re-written. Do Vue codebases in the wild tend to be different? Or would this have been a massive undertaking as well?

This is a great question.

Re: Migrating from Vue 2 to Svelte

#250
post #7

Still don't understand why people prefer magic templated front-end frameworks. Reading non-standard HTML just sucks. What even is "$:" or why does Vue require non-standard javascript ref("") objects...

HTML and JS evolve very, very, very slowly compared to the needs of complex web apps.

If you're just building a simple page, sure, don't use a framework. But once you get into the realm of multi-screen async state sharing across components, a framework makes that a LOT easier to read and maintain.

At the end of the day the minor syntactic changes aren't much more complex than say, Markdown... they just facilitate component composition. The actual business logic is usually still written in plain JS. The templating language doesn't really matter all that much in the end, whether it's JSX or a Vue thing or a Shopify Liquid template or whatever.

HTML + JS isn't some golden standard that markup should aspire to... it is literally the lowest common denominator. It's historical baggage that everyone's forced to compile down to, and there's nothing magical or special about either writing in a framework or in pure HTML. Users don't care. Just make it work, and make it work within resource constraints. The latter is usually what drives framework usage... most teams don't have infinite time to reinvent everything in their own proprietary framework.

Post reply on HN