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

251–260 of 289 posts

Re: Migrating from Vue 2 to Svelte

#251

Post by sph »

solardev wrote: post #248
sph wrote: post #196

Earlier quoted context omitted.

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…

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.

Re: Migrating from Vue 2 to Svelte

#252

Post by solardev »

veidelis wrote: post #162
randomsearch wrote: post #81

Earlier quoted context omitted.

If you want a serious answer: because frameworks do a lot of work for you. For example, they will keep state synchronised between your data model and components (and with some handy plugins, your server). They allow encapsulation and reuse through a well thought out set of abstractions. They provide functionality like routing and app-wide data stores with transactions. If you’re just building a webpage no problem, us…

I think what snowl wanted to know was more technical than that - why such new syntax is necessary to achieve those things? Why exactly the same things cannot be achieved with existing syntax? For example, it's very understandable why JSX is preferable over vue's string syntax ( ) in terms of "just use JS" argument. What exactly warrants this necessity for these weird looking and non-standard syntaxes and why it can't…

With plain HTML+JS, it's very easy to get components to accidentally race each other when you have multiple inputs and outputs, like user interactions plus async API calls plus rerenders and UI state changes.

The syntactical sugar is often masking a lot of complexity behind the scenes, and the very idea of (say) React's props propagation within a component tree is an abstraction over having to write a bunch of separate event handlers and figuring out a way to manually share state between them.

If that is a problem you run into in your app, you can of course write your own system. But that's all these frameworks are... someone else had that same problem, decided to formally tackle it and make it a well-supported & documented system so that others facing the same problem can use that as a solution too. Over time the industry converges on a few (React, Vue, Svelte these days, Angular in the past). If you don't like any of them, well, that's how a new framework is made...

Vanilla HTML doesn't even have loops and conditionals, the basic features of any templating language from 10-20 years ago. It's glorified Gopher with JS shimmed in because Netscape was afraid of losing dominance. It was never intended to become the de facto language of software app distribution... the whole reliance on a "document" model is a poor fit for an entire class of web apps (like Google Maps or Gmail or Spotify or Netflix or Figma or Photopea).

IMO the better question in my mind is not "why do new JS frameworks and templates keep popping up?" (because HTML+JS sucks), but rather "why haven't native HTML+JS continued to evolve, creating a native solution for common pain points that the frameworks address -- like state, component trees, etc.?"

For what it's worth, at least the Web won, instead of (say) ActiveX or .NET or Flash or the Metaverse or whatever alternate ecosystem companies have tried. The JS frameworks offer some of the devex benefits of those other richer languages while still being able to compile down to HTML+JS for delivery to the enduser -- a huge benefit over a "cleaner" ecosystem that would require the enduser to install additional software. The ugliness of modern JS is because it's no longer trying to just handle basic documents, but trying to replace desktop apps altogether. And for many people, it already has.

Re: Migrating from Vue 2 to Svelte

#253

Post by solardev »

sph wrote: post #251
solardev wrote: post #248

Earlier quoted context omitted.

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…

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.

Re: Migrating from Vue 2 to Svelte

#254

Post by sph »

solardev wrote: post #253
sph wrote: post #251

Earlier quoted context omitted.

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.

Re: Migrating from Vue 2 to Svelte

#255

Post by sph »

azangru wrote: post #218
sph wrote: post #124

Earlier quoted context omitted.

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 yo…

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

Re: Migrating from Vue 2 to Svelte

#256

Post by hmillison »

exclusiv wrote: post #102
karmasimida wrote: post #24

Earlier quoted context omitted.

Meanwhile React will continue succeeding the test of time

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…

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.

Re: Migrating from Vue 2 to Svelte

#257

Post by EMM_386 »

> Besides, the latters share the same concepts of single file components: logic (JavaScript), structure (HTML), and style (CSS) in the same file.

Personally, I hate this.

I currently work on a large Angular 14 (now 15) application that separates the view (HTML) from the logic (TS) and the styling (CSS). So you have essentially 3 files for a component.

I don't understand why some developers love cramming this stuff into the same file. Angular's default style encapsulation prevents component styles from affecting other components.

To each their own, I guess.

Re: Migrating from Vue 2 to Svelte

#258

Post by nov21b »

latchkey wrote: post #235
nov21b wrote: post #178

Earlier quoted context omitted.

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.

Re: Migrating from Vue 2 to Svelte

#259

Post by pookha »

caseymarquis wrote: post #183
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…

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…

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.

Re: Migrating from Vue 2 to Svelte

#260

Post by b112 »

KyeRussell wrote: post #188
b112 wrote: post #87

Earlier quoted context omitted.

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…

This is a common rebuttal against any dissent against the insane flux of the front end space and I genuinely don’t believe that anyone with significant experience in software actually believes it. The front end space is really quite unique in its fragmentation and pace of change. Things are…maybe starting to cool down a touch, but not really. We can talk til the cows come home about how this or that have caused thing…

Front end doesn't change that much from an implementation and coding perspective.

To that I mean, if you could code 5 years ago, and deploy a front end of any sort 5 years ago, you won't have many issues today.

People still use redis/memcached, mysql, php, apache2, with laravel for example.

And solutions such as docker, with unvetted builds snagged from random people, are no different, functionally, than a VM or even a bare metal cluster.

I will agree that the absurd node ecosystem, with its unsecure, unauditable packages, composer and its insane web of just stupid dependancies are ridiculous.

But that's not rapid change of method or coding language, just because behind the scenes it's all just language such as php.

So sure, the cruft is just that, but the meat is what drives change, and a lot of it.

Post reply on HN