Live data from Hacker News

Comparing Svelte and React

jackfranklin.co.uk

281–290 of 338 posts

Re: Comparing Svelte and React

#281

Earlier quoted context omitted.

Sounds like you're describing Vue. Is their any substantial advantage over Vue that you're aware of? I think a lot of people, including myself, are just uninterested in arbitrarily and subtley different solutions to the same problem. I've used react, and it's just not as compelling as anyone made it out to be. Neither is Vue compared to React for that matter, but it appeals to me a little more.

So I'm a Vue developer who hasn't ever actually built anything in Svelte, but Svelte uses a really cool model that's completely different from Vue and React. Where Vue/React use a virtual DOM, Svelte is compiled to essentially vanilla JS. Instead of having render functions that fully replace a component, Svelte updates just the parts of the DOM that need to be updated. Because of the dramatically reduced overhead, pr…

Stencil has is also a component compiler and has a very clean API (declarative through annotations like in modern angular) and standard TSX.

However the issue with both svelte and stencil is their lack of ecosystem, even if they have interop with webcomponents, today the market is too small.

Re: Comparing Svelte and React

#282
post #128
post #124

Earlier quoted context omitted.

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.

If you mutate through the vueX store then the debugger will give you a commit history of mutations and an ability to revert them individually.

Re: Comparing Svelte and React

#283

I have been maintaining some Svelte components. But as many of them here, my profession is in React as of now. One of things Author didn't directly point out is about JSX. I mean you can build JSX of a component incrementally in your component code. But that's something I am missing in Svelte.

What are some uses cases for it? I always thought that was polluting the class business logic with what should just be subcomponents?

Anyway Stencil is very similar to svelte and support TSX

Re: Comparing Svelte and React

#284
I went with Svelte for my first side-project[1], having never touched a frontend framework or used Javascript before.

The experience was actually really nice. Obviously I don't know how it compares to other options out there, but it was a pretty enjoyable experience overall. I felt like I was able to do exactly what I wanted and wasn't missing anything.

[1]: https://squidpoll.com/

Re: Comparing Svelte and React

#285
post #198

Earlier quoted context omitted.

> I'm sure there are patterns that could help with this. Indeed there are. Again any Turing complete language can do anything another language can with a sufficient dose of design patterns (in the limit design patterns just recreate another language). So everything I say about "classes" and "state machines" needs to be taken as talking about level of effort not possible vs. impossible, since the former, being Turing…

> Redux is the purest expression of a state machine possible Are you sure "pure" is the right word? Last I checked redux very proudly incorporates a certain event-sourcing something idea in it. It's definitely not a "just state machine" library. More like in KFC when you order something, they always make sure that you get their sugar water as well.

What do you mean by "a certain event-sourcing something idea?"

I really do mean "pure." That doesn't mean that Redux doesn't provide other facilities on top, such as React interop, error-handling, logging, etc. But if you don't need any of that and you use the core of Redux, it really is just a state machine representation.

Let's write out the classic finite state machine representation of a locked/unlocked item.

  States: Locked, Unlocked

  State transition table:
  
  Current State | Transition | Next State
  ---------------------------------------
  Locked        | Lock       | Locked
  Unlocked      | Lock       | Locked
  Locked        | Unlock     | Unlocked
  Unlocked      | Unlock     | Unlocked

  Initial State: Unlocked
That's a textbook definition of an FSM.

This is the equivalent Redux code.

  import { createStore } from 'redux';

  const initialState = 'Unlocked';
  
  const reducer = (currentState, transition) => {
    if (currentState === 'Locked' && transition === 'Lock') {
      return 'Locked';
    } else if (currentState === 'Locked' && transition === 'Unlock') {
      return 'Unlocked';
    } else if (currentState === 'Unlocked' && transition === 'Lock') {
      return 'Locked';
    } else if (currentState === 'Unlocked' && transition === 'Unlock') {
      return 'Unlocked';
    }
  };
  
  const store = createStore(reducer, initialState);

  // We're done! Now we can play with our state machine

  console.log(store.getState()); // 'Unlocked'

  store.dispatch('Lock');
  console.log(store.getState()); // 'Locked'

  store.dispatch('Lock');
  console.log(store.getState()); // 'Locked'

  store.dispatch('Unlock');
  console.log(store.getState()); // 'Unlocked'
That's it. That's Redux. This is exactly a 1-to-1 translation of the FSM. I don't see how it could be any more direct (at least in JS). Everything else in Redux is optional.

Re: Comparing Svelte and React

#286
post #127

Earlier quoted context omitted.

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…

Oddly, despite the immense resources that Facebook has available, Facebook in a browser is slow and glitchy, especially after the most recent redesign.

I can't say I share that experience at all - I make quite an effort to avoid installing their invasive apps, always using the browser - but it's an interesting point

Re: Comparing Svelte and React

#287
post #280

Earlier quoted context omitted.

FWIW, Redux has _never_ been a Facebook project. Yes, both of the creators now work on the React team (Dan Abramov and Andrew Clark), but it's always been an independent OSS project, and is currently maintained by myself and Tim Dorr. As far as I know, FB barely even uses Redux at all internally, and that only in isolated particular teams that chose it themselves. My understanding is that they mostly use Relay for th…

>Yes, both of the creators now work on the React team (Dan Abramov and Andrew Clark), but it's always been an independent OSS project, and is currently maintained by myself and Tim Dorr. The source I have says that Dan Abramov created Redux while working at Facebook on React[0]. So while Redux has never been under the official governance of FB, it was created by FB employees for a FB project (React) while in parallel…

That's wrong. Dan created Redux while he was actually unemployed. I'd have to check the exact timeline, but I believe he left Stampsy in late 2014 or early 2015, and was actually getting some funding from an OSS collective-type thing while he developed Redux in preparation for React Europe.

Redux was developed in June/July 2015, and demoed at React Europe on July 5, 2015 [0].

Redux 1.0 was released on Aug 14, 2015 [1].

Per the tweet linked from that page [2], Dan didn't join Facebook until November 2015, well after Redux had been released.

So, he most definitely was _not_ working at FB when he developed Redux.

[0] https://www.youtube.com/watch?v=xsSnOQynTHs

[1] https://github.com/reduxjs/redux/releases/tag/v1.0.0

[2] https://twitter.com/dan_abramov/status/671135846830075904

Re: Comparing Svelte and React

#288
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…

> JSX is not "Just Javascript" It's very thin syntactic sugar over a function call. It has a very simple 1:1 mapping to the output code, as opposed to "magically reactive `foo = bar`. > I'm sure not many people would be willing to argue that throwing promises (as react suspense supposedly does) is a holy grail of frontend development, even though it is "just javascript". I'll give you that hooks and suspense are stra…

> It's very thin syntactic sugar over a function call

Actually, it's not. It's a set of AST nodes. What they compile to is entirely implementation-specific. Look at Inferno.js or Solid.js compiled code for example; it looks nothing like simple function calls. Although obscure, there are also other spin-off ideas floating around like compiling to math expressions or to file system APIs. Even within the scope of React, the idea of allowing configuration for optionally compiling to `h` instead of `React.createElement` for minification purposes has been brought up (and is doable in React proper in user space, and out of box with Preact).

The idea of adding JSX to JS got brought up before and it got shot down precisely because the compilation semantics of JSX are not formally specified.

> all of these can be defined in normal JS code as opposed to a DSL

Right, but my point is that "just javascript" is not a good guiding light if the goal is implementing a pit of success. The crank.js blog post talks about how its author thinks React has gone off the rails pursuing some notion of purity. DSLs are not automatically bad things. I've mentioned Solid.js before and it has a component-based DSL for control flow, and honestly that looks quite reasonable. At some point if one jumps the shark, so to speak, and starts making uncomfortable contortions to stay within the confines of "just javascript" and avoid DSLs at all costs, that amounts to leaving a useful tool unused at the table, where it could have been effective. "When all you have is a hammer", etc.

Re: Comparing Svelte and React

#289
post #288

Earlier quoted context omitted.

> JSX is not "Just Javascript" It's very thin syntactic sugar over a function call. It has a very simple 1:1 mapping to the output code, as opposed to "magically reactive `foo = bar`. > I'm sure not many people would be willing to argue that throwing promises (as react suspense supposedly does) is a holy grail of frontend development, even though it is "just javascript". I'll give you that hooks and suspense are stra…

> It's very thin syntactic sugar over a function call Actually, it's not. It's a set of AST nodes. What they compile to is entirely implementation-specific. Look at Inferno.js or Solid.js compiled code for example; it looks nothing like simple function calls. Although obscure, there are also other spin-off ideas floating around like compiling to math expressions or to file system APIs. Even within the scope of React,…

> It's a set of AST nodes.

Ok, but you could make the same point about plain JS as in Svelte. I haven't looked into it too much, but from the readme Solid.js looks more like a compiler than a library, so whatever it outputs when it sees JSX doesn't have much to do with what JSX is usually used for, imo. I've only ever seen it used as syntactic sugar for function calls, be it `React.createElement` or `h` or `jsx`.

> At some point if one jumps the shark, so to speak, and starts making uncomfortable contortions to stay within the confines of "just javascript" and avoid DSLs at all costs, that amounts to leaving a useful tool unused at the table, where it could have been effective.

Personally I find it much more likely that I'll have to bend over backwards when I'm dealing with a DSL rather than just plain code, because the DSL will be really well optimized for one usecase, but has omitted another usecase that I will need at some point, and then I'll have to find some hack to accomodate the DSL rather than just add that one line of code that I could've used if it was just Plain Code.

The downside is that some other things will look kind of awkward and since you're now dealing with a turing-complete language you'll lose analizability, but IMO for UIs those are worth losing if I can just use plain code.

Re: Comparing Svelte and React

#290

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

It took a month to teach angular and a year to become proficient. Knockout or backbone + handlebars were similarly large commitments. React took a day or two to learn and less than a a month to completely master.

I also hear about “react doesn’t have one way of doing thing’s built in”, but it wouldn’t have been as successful if it had. It ate up other frameworks because it was so easy to integrate.

Need more performance in your angular app? Just add an ng-react component. Have an extensive backbone project? You can just gradually swap in react to replace your mustache templates and leave backbone alone. Have a jQuery widget that’s getting hard to maintain? Change to React and the rest of the page renders on the server like it always did.

And of course, you could greenfield with flux, rxJS, or whatever other thing worked for your company. But if they hadn’t been flexible from the start, there wouldn’t have been room to create and test things like reactive programming, redux, mobx , etc

Post reply on HN