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

Comparing Svelte and React

jackfranklin.co.uk

Post reply on HN
Print view View original

121–130 of 338 posts

Re: Comparing Svelte and React

#121

Post by darksaints »

deckard1 wrote: post #69

I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed the…

> I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed their mind at least 3 times on the API and none of it fits together today. Hooks and classes don't mix, lifecycle methods are still out there and just as confusing today as they were years ago. Mixing state and functions. It's just a horrible bag of half-baked bad ideas. And it's not even batteries included.

This, so much. It has been so frustrating to have to go from es5 classes to es6 classes + stateless functions to stateful hook oriented functions that do nothing but create just a new type of class, but also with es6 classes but with different methods. Seriously, WTF?!

I really like the ideas behind Svelte, but some things just really do not mix well with it. Like leaflet or d3. For some reason, mixing declarative rendering approaches with non-declarative approaches results in completely mind boggling buggy interactions that aren't easily understood. And typescript integration feels tacked on and doesn't play nice with some of the semantic differences between svelte and javascript, which makes me doubt how much you can really say that it is just Javascript. I mean the entire concept of a variable has completely changed to become reactive, and at that point it's not really javascript anymore, it's something that compiles to javascript while looking almost exactly like javascript. I'd love to give it a deeper look, and I probably will soon, but I'm quite skeptical of what might be hiding underneath the covers.

Re: Comparing Svelte and React

#122

Post by nsonha »

k__ wrote: post #118
nsonha wrote: post #115

Earlier quoted context omitted.

biggest issue of Svelte (and vue and others) is that mutable state is marketed as a feature. If you don't like mutable state anyway then it just seems like an inferior way of writing code.

Yes. To be fair, after looking how the whole Redux story went, I think the mainstream simply wasn't ready for immutable state.

I didn't mean the solution had to be redux or immutable state. It could be state encapsulation like in oop, or centralizing state update (setState)

Re: Comparing Svelte and React

#123

Post by nsonha »

ForHackernews wrote: post #95
robertoandred wrote: post #81

Earlier quoted context omitted.

How is Svelte "just JavaScript" when it uses custom templates and file types?

Svelte itself is a compiler: It compiles the `.svelte` files into (readable-ish) vanilla JavaScript that runs directly in the browser.

X is a Y that Z things in to vanilla js

Re: Comparing Svelte and React

#124

Post by lhorie »

nsonha wrote: post #115
mattgreenrocks wrote: post #110

Earlier quoted context omitted.

IMO, Svelte’s biggest issue is it didn’t come out of FAANG.

biggest issue of Svelte (and vue and others) is that mutable state is marketed as a feature. If you don't like mutable state anyway then it just seems like an inferior way of writing code.

You can't get away from mutable state. Redux, for example, just hides the big `state = newState` mutation but it's still very much there. When a library/framework uses mutable state, it's not that they're saying immutability is an anti-feature. They're just being pragmatic in the sense that mutation has to happen anyways and they consider explicit to be better than implicit. (With that said, some people do argue that immutable JS is in fact an anti-pattern because JS doesn't really lend itself to idiomatic performant immutability in the first place and emulating it as an abstraction adds a lot of unwanted complexity)

IMHO, it's a disservice to yourself to just blindly drink the immutable koolaid without understanding the very real drawbacks it comes with in JS-land. There's a great deal of gray area where explicit mutation is perfectly adequate in ways that overzealous immutability might be counterproductive.

Re: Comparing Svelte and React

#125

Post by mattgreenrocks »

k__ wrote: post #118
nsonha wrote: post #115

Earlier quoted context omitted.

biggest issue of Svelte (and vue and others) is that mutable state is marketed as a feature. If you don't like mutable state anyway then it just seems like an inferior way of writing code.

Yes. To be fair, after looking how the whole Redux story went, I think the mainstream simply wasn't ready for immutable state.

It’s a shame. Controlled side effects are a big win IMO, especially mutability.

Re: Comparing Svelte and React

#126

Post by lhorie »

nsonha wrote: post #117
lhorie wrote: post #86

Earlier quoted context omitted.

I feel like this "just javascript" trope really needs to die. JSX is not "Just Javascript", and magically reactive `foo = bar` assigments are not "Just Javascript". But frankly, that doesn't really matter one bit anyways; it's fairly nitpicky to object to different control flow syntaxes, when at the end of the day you're just rendering data from a request to screen. I'm sure not many people would be willing to argue…

where do I read about this throwing promises thing?

The crank.js intro blog post is a good place to start[0]

[0] https://crank.js.org/blog/introducing-crank

Re: Comparing Svelte and React

#127

Post by nawgz »

dan-robertson wrote: post #111
alfonsodev wrote: post #75

Earlier quoted context omitted.

I think many people adopted React because Facebook was behind it, and using it in production, the ecosystem is huge, there is a react- package for everything you can image, there is also react-native, I don't like it, but there it is, you can reuse the knowledge to build native mobile apps. Now Svelte, I haven't been following, but I think the creators are working in what's going to be next and even better framework[…

I don’t think any of your arguments in favour of react are sufficient. JQuery had a huge number of libraries and could be used to make websites that worked. Angular was backed by Google who generally have more clout than Facebook. I think most comparisons would find that jQuery does not solve the same problems and that angular resembles the kind of steaming brown thing one might find behind a cow—and that’s before yo…

Your counter points don’t check out too much though?

> jQuery

Just not possible to compose, which makes full applications difficult. No answers for state management or such either, completely a different scope than frameworks

> Google more clout than FB

In some domains sure, but I’ve never understood how people don’t think FB are masters of UI. There is probably no org with more UI clout than FB, they built their own insanely adopted library after all while Google can barely force their own engineers to use Angular

React is also unquestionably the most JavaScript of the libraries, a component’s markup is such a thin abstraction around an object and maps perfectly to DOM trees and concepts, classes or functions or hooks are all using native JS concepts, explicitly typed typescript and react genuinely eliminates the need for all simple testing plus makes for a streamlined developer experience, and its concepts of lifecycles and composability introduce complexity but in my opinion in a clearly delineated and extremely powerful way

Also, as always I have to note this, the churn argument is completely overblown wrt React, each way of writing code still works or compiles, conceptually the lifecycle and state management never changed just its syntax, and npm has old versions for a reason. I run 2016 code in production today as an internal application for engineers, and I’ve seamlessly updated webpack and module versions while keeping the same code syntax.

Re: Comparing Svelte and React

#128

Post by nsonha »

lhorie wrote: post #124
nsonha wrote: post #115

Earlier quoted context omitted.

biggest issue of Svelte (and vue and others) is that mutable state is marketed as a feature. If you don't like mutable state anyway then it just seems like an inferior way of writing code.

You can't get away from mutable state. Redux, for example, just hides the big `state = newState` mutation but it's still very much there. When a library/framework uses mutable state, it's not that they're saying immutability is an anti-feature. They're just being pragmatic in the sense that mutation has to happen anyways and they consider explicit to be better than implicit. (With that said, some people do argue that…

you're arguing based on a very mechanical understanding of why immutable state is important. Immutability is just a solution to the actual goal which is controlled side effect as someone put in the other comment.

Given a side effect (a piece of data is mutated), I need to know what code caused it and when. When you casually throw assign statements everywhere that question becomes really hard to answer.

Re: Comparing Svelte and React

#129

Post by orangecat »

brundolf wrote: post #68
gkaemmer wrote: post #66

Earlier quoted context omitted.

I actually came to this thread expecting more people to call out MobX. When I use MobX with react, I find it to be as simple and _fun_ as the author finds svelte. Most of the problems people tend to raise with React are problems that are solved by observable state objects. I also evangelize it whenever I can -- I don't want MobX to be forever doomed to its status as a cult hit!

It's baffling to me how distant of a second it is in terms of popularity. Instead of forcing you to contort your program into a special paradigm in order to deal with reactivity in a sane way, it simply makes reactivity a non-concern (while remaining pretty simple and predictable when you do actually care to dig beneath the magic). You can write code in a way that's natural and simply not think about reactivity most…

And then there's Vue.js which essentially has MobX functionality built in. When you want to update the state, you just...update the state, which can be a plain JS object that knows nothing about the front-end framework. I've used it for several medium-size projects and haven't gotten close to needing anything like Redux or Vuex.

Re: Comparing Svelte and React

#130

Post by darksaints »

k__ wrote: post #118
nsonha wrote: post #115

Earlier quoted context omitted.

biggest issue of Svelte (and vue and others) is that mutable state is marketed as a feature. If you don't like mutable state anyway then it just seems like an inferior way of writing code.

Yes. To be fair, after looking how the whole Redux story went, I think the mainstream simply wasn't ready for immutable state.

Redux was shit. It made apps less comprehensible and less performant.

Immutable state isn't really a great idea for stateful applications, and UI development is an almost purely stateful activity. It can easily be said that any UI is fundamentally a state machine...the state of your UI defines the set of actions that are available to it, and the actions taken define the future state of the UI. This is not just true for web UIs, but all UIs. It is just as true for your blender or transmission lever as it is for your react app. And being a stateful problem, you're far more likely to have to change state than you'll have to change how that state is rendered. This puts redux-style solutions squarely on the wrong side of the expression problem. And the fact that your state is essentially a global variable, using it means you spend vast amounts of time trying to thread constantly changing data types through intricately nested pure functions, and it just fucking sucks.

I'm generally a pure functional programming kind of nerd, but when it comes to difficult inherently stateful programming problems like UI dev, game programming, or simulations, nothing is better than plain old encapsulated state via classes (or maybe actors). Anybody who advocates for pure functional approaches to these types of problems has lost the plot.

Post reply on HN