Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

As somebody using Svelte for a real production application, I can only 100% agree with their recommendations regarding Svelte because of the overall dev experience is unmatched. It just feels right. Easy. Simple. And I'm not even considering performance here as another benefit.

I usually make the analogy of a video game, where you can pick the difficulty. Svelte/SvelteKit is working in the "easy" difficulty level. You can achieve the same end result and keep your sanity (and your hair).



I've been using Svelte's custom elements (web components) to make components that slot into pages on an existing .net / alpine.js site. It's been a great dev experience and results in really portable components. Each component is it's own bundle (achieved via separate vite configs - you can also organise to bundle groups of components work together). Each of the tools in the tools section is a svelte custom element https://www.appsoftware.com/tools/utilities/calculators


Can we build the elements as part of light dom? Do they call their destructor when we navigate away?


I will keep using Next.js, because that is what SaaS vendors support on their extension SDKs, and I have better things to do than build an ecosystem.

Alternatives are great for those without these kinds of constraints.

In which case, I rather use traditional Java and .NET frameworks with minimal JavaScript, if at all.


How do you deal with the horrendously slow on-the-fly compile times in dev mode?

I wonder how anyone gets any work done when they have to wait 10 seconds on every page load on a M3 Macbook Air


Turbopack helps, ever used C, C++, Rust, Scala, Swift in large scale projects?

Back in 1999 - 2001, every time I wanted to do a make clean; make all in a C based product (actuall TCL with lots of C extensions), it took at least one hour build time.


I guess I am spoiled by Java and Angular then.

Both compile for the same time as a page load in Next dev mode, but then everything is smooth sailing (and Angular also does hot-reloading well)


I would choose vue because you can still get paid for it but react is king by jobs. If you're playing in the hobby space then between liveview, datastar etc, there is plenty of cool stuff moving the needle. React is nice and simple IMHO which is why average devs like me enjoy it.


>React is nice and simple IMHO which is why average devs like me enjoy it.

Maybe years ago. Now it's a bloated beast.


Can you give some examples? I feel like React is still pretty much just React, having developed with it for a decade now. Hooks was the only meaningful API (surface) change, no?


> having developed with it for a decade now

I think this is the reason why React feels normal to you. But as someone coming into it fresh, React felt like there were always 4 different ways to do the same thing and 3 of them are wrong because they built a new API/there are more idiomatic ways to accomplish the same thing now. If you have a decade of experience, then you probably do most things the right/obvious way so don't even notice all the incorrect ways/footguns that React gives you.


If you're coming into it in 2025, it's even simpler. Just ignore the SSR stuff which Vercel are pushing and you're good. A lot of the path has been smoothed out over the years to make it an ideal place to start today.


> If you're coming into it in 2025, it's even simpler. Just ignore the

official documentation, otherwise you'll be creating a NextJS app and get recommended to deploy to Vercel.


You claim that React offers me multiple incorrect ways/footguns to do things, but you can't list a single meaningful API surface change besides Hooks when that was the point of my comment?

Saying React is a "bloated monster" and then not being able to provide a single example of ways it has bloated is a joke. The article we're looking at shows that the bundle size can be a bit bigger but the speed to render is equivalent to all these other frameworks.

If you really love minimal bundle sizes, go off, but bundle size is not how I would define bloat in a framework


I feel like the introduction of React Compiler was a pretty big change, too?

The article seems to make the bloat self-evident by comparing the load times of identical apps and finding React magnitudes slower.

To be fair, I haven't written in React for a few years now. I reached for Svelte with the last two apps I built after using React professionally for 4 years. I was expecting there to be a learning curve and there just... wasn't? It was staggering how little I had to think about. Even something as small as not having to write in JSX (however normalized I was to writing in it) really felt meaningful once I took a step back and saw the forest for the trees.

I dunno. I just remember being on the interview circuit and asking engineers to tell me about useCallback, useEffect, useMemo, and memo and how they're used, how something like console.log would fair in relation to them, when to include/exclude arguments from memoization arrays, etc.. and it was pretty easy to trip a lot of people up. I think the introduction of the compiler is an attempt to mitigate a lot of those pains, but newer frameworks designed with those headaches in mind from the start rather than mitigating much later and you can feel it.


> I feel like the introduction of React Compiler was a pretty big change, too?

React 19 required almost no code changes in my multiple production apps so unless I missed something, I would say the API surface was virtually unchanged by it

> The article seems to make the bloat self-evident by comparing the load times of identical apps and finding React magnitudes slower.

What are you talking about? Next.js != React, that's your own fault if you bought into their marketing. TanStack / React looks to be a slightly larger bundle size but I'm seeing FCP differences from 35ms to 43ms (React being 43ms), how is that orders of magnitude slower?

Bad faith or bad reading, I can't help you either way here

> asking engineers to tell me about useCallback, useEffect, useMemo, and memo and how they're used

What are you even trying to say? Are you implying that other web frameworks don't come with any state management, or that they are reactive, or that you don't need the concepts from React in them?

"People got confused sometimes" isn't really a defense when the alternative is a framework you only ever use on solo greenfield projects that you've never talked to another engineer about their core concepts.

Seriously, you are just peddling groupthink, there isn't a single legit criticism of React.

Next.js, on the flip side, we should all go off on those clowns, but I wouldn't touch that with a 10 foot pole so I don't see how it's even relevant.


https://react.dev/reference/react-compiler/directives/use-no...

"use no memo"

react now needs you to declare what you are not using, using a language "feature" that does not exist. It is crazy how people keep denying reality wrt React.


They gave an escape hatch to people who wrote malformed hooks so their build process wouldn't crash, I don't really think that's a meaningful use case.

Are directives horrible? Absolutely. Did I encounter any need for this across porting 4 different apps and a component library to React 19? No, it was frictionless.

Because React is the same as it has been for a long time.


I rolled my eyes when hooks came out and never used it again besides for work, so not really. All the frameworks on the planet and facebook is still a heaping pile of dog shit. I was spoiled by Vue's lifecycle methods and then Svelte and it was impossible to go back.

Maybe hooks are cool but the same code written in react vs vue vs svelte or something else is always easier on the eyes and more readable. Dependency arrays and stale closures are super annoying.

Sorry but I really hate React. I've dealt with way too many shit codebases. Meanwhile working in vue/svelte is a garden of roses even if written by raw juniors.


> I've dealt with way too many shit codebases.

Congrats, it's the most popular framework, no doubt there are abuses out there.

I highly doubt raw juniors are actually writing beautiful vue/svelte code, if obviously emotionally charged anecdotes are your only arguments here, I think you can just admit you see "Facebook" and crash out...


Apologies for not submitting a paper to an academic journal about why I hate React.


"I hate React, and here's some false-on-the-face anecdotes" is not a comment worth making.


This is going to sound selfish, but I liked being a solo React Typescript developer. My colleagues worked on UI/UX, back-end, DB, specs, etc, but I was responsible for the React code and I could just iterate and iterate without having to submit every change as a pull request.

Now with Laravel, Blade and JQuery the IDE support is low but everything is easy enough and we work as a team and do merge requests and it's a chill job even if it's full stack.


Hilarious its come full circle again. React was a breath of fresh air for fe's back in the day, and now we're back at jQuery! Why the switch from React to Laravel/Blade/JQuery?

>I liked being a solo React Typescript developer.

Being a solo FE rocks. Everyone thinks you're a magician. The worst is FE-by-committee where you get 'full-stack' devs but really they're 99% postgres and 1% html.


Hmm but Svelte docs is one of the most unfriendly I ever read through.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: