14 ms·

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

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 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. Svelte has it all built-in. It has the equivalent of CSS modules. It has global reactive state and an incredibly simple state protocol that seems almost stupid if you're coming from Redux. You step out of your daze and realize you don't need all the rituals and boilerplate. The things I've seen built on top of that simple protocol can be incredible. It's not magic. It's just JavaScript. I dare say that Svelte is a joy. But I hesitate to even leave this comment here. Because I know the architecture astronauts are listening, eager to sink their claws into this simple elegant new thing and fill up their Github profiles with soon-to-be abandonware cruft which they will use to pad out article after Medium article which will all pour down upon Hacker News like a shit typhoon. Prodding us to join their cult of Svelte+RxJS. Or Svelte Sagas. Or their random dogma they toss into a giant bucket labeled "Svelte best practices." And, of course, "Ten ways you are doing Svelte wrong." I might be a little bit cynical.

Aeolun 6y ago
Have you ever worked on very large React applications without Redux or Saga? I just cannot imagine any other way of keeping my application sort of understandable.
- buzzerbetrayed 6y ago
  You should look at svelte stores if you haven’t already. They are amazing, and make redux seem so needlessly complex and ineloquent
alfonsodev 6y ago
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[1], to your point of things in Svelte not changing as much as in React, maybe it just a matter of time. Here is the video I had in my bookmarks for a while, I still couldn't make the time to watch, so I hope my comment is not too far from reality. [1]https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=875s https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=875s
- deleted 6y ago
  [deleted]
- dan-robertson 6y ago
  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 you consider backwards compatibility. I would argue that react has some particular merits (for three the whole vdom based architecture, using jsx, and unidirectional data flow), that it was the first (widely known) framework with those merits, and that it has generally been backwards compatible or only required simple changes. I think these do a better job of explaining why react became popular and inertia explains why it is still popular.
  - nawgz 6y ago
    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.
robertoandred 6y ago
How is Svelte "just JavaScript" when it uses custom templates and file types?
- lhorie 6y ago
  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 that throwing promises (as react suspense supposedly does) is a holy grail of frontend development, even though it is "just javascript".
  - nsonha 6y ago
    where do I read about this throwing promises thing?
    - lhorie 6y ago
      The crank.js intro blog post is a good place to start[0] [0] https://crank.js.org/blog/introducing-crank https://crank.js.org/blog/introducing-crank
      - scns 6y ago
        Insightful read, thank you.
  - steinuil 6y ago
    > 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 straying further from normal js because they don't behave like normal functions do and have special rules for being called; hooks are a DSL for encoding incremental computations into js, and suspense is just the react team fawning over algebraic effects/delimited continuations and trying to reproduce them in js. But then again, all of these can be defined in normal JS code as opposed to a DSL which compiles to who knows what, so all the rules applying to normal JS and its tooling apply to them.
cstrat 6y ago
This comment makes me want to seriously give Svelte a try. I've browsed the docs and it looks really cool, I've always just held back because I feel like I am juggling enough JavaScript libraries in my head already and React has been great.
- arxpoetica 6y ago
  FWIW, Svelte has a very easy learning curve.
KaoruAoiShiho 6y ago
Is animations just as easy in svelte?
- andy-dev 6y ago
  Svelte has animations and transitions already built into it, do yeah, it's real easy
  - rubatuga 6y ago
    I found animations a bit of a struggle, especially when combining multiple of them. There were performance bugs with some of the combined animations, and the Svelte documentation didn’t make it clear how animations could affect things like the focus on a text box.
yepthatsreality 6y ago
React, Redux, Jest, and it’s ilk always came off to me as a way for Facebook to remain relevant through tech-debt and lock-in.
- acemarke 6y ago
  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 the new FB.com, and still have a lot of old-school Flux in there as well.
  - acoard 6y ago
    >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 working on that project. [0] https://golden.com/wiki/Dan_Abramov_(software_engineer)-99B8RJM https://golden.com/wiki/Dan_Abramov_(software_engineer)-99B8...
    - acemarke 6y ago
      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 https://www.youtube.com/watch?v=xsSnOQynTHs [1] https://github.com/reduxjs/redux/releases/tag/v1.0.0 https://github.com/reduxjs/redux/releases/tag/v1.0.0 [2] https://twitter.com/dan_abramov/status/671135846830075904 https://twitter.com/dan_abramov/status/671135846830075904
mattgreenrocks 6y ago
IMO, Svelte’s biggest issue is it didn’t come out of FAANG.
- nsonha 6y ago
  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.
  - k__ 6y ago
    Yes. To be fair, after looking how the whole Redux story went, I think the mainstream simply wasn't ready for immutable state.
    - nsonha 6y ago
      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)
    - mattgreenrocks 6y ago
      It’s a shame. Controlled side effects are a big win IMO, especially mutability.
    - darksaints 6y ago
      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.
MaxBarraclough 6y ago
I've only dabbled with Svelte, but I agree that it looks like an excellent framework, in itself. Powerful abstractions, succinct and approachable syntax, and it compiles down to a truly compact output. (Not the usual only a few hundred kilobytes when gzipped.) I ended up not using it though, as the surrounding ecosystem just isn't there. There are two different material design frameworks out there for Svelte, neither of which I could get to work. I ended up opting for Angular+Angular Material, which worked out of the box.
danjac 6y ago
I did some React development some years ago, and was glad to move away from it because of the ridiculous churn in the ecosystem. It was like building on top of quicksand. At the time, I thought it was because React was new, and new stuff tends to have churn because people are just figuring out the optimum patterns and false starts are to be expected. When I look into React years later, the churn is still going on, which perhaps is a warning sign it just wasn't well thought through to begin with, or that the ecosystem has been captured by architecture astronauts on a lifelong quest for some kind of pure ideal rather than usability and stability.
auganov 6y ago
Neither agree or disagree, but just want to say that's exactly how I felt about Angular when React first came out. It wasn't much of a "framework" at all, just an easy way to render onto the DOM from js. I very much like the idea of compiling code to make direct DOM mutating managable. A very powerful idea regardless of which syntax you end up going with. I wish their website talked more about this instead of having a React comparison on every page.
darksaints 6y ago
> 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.
brailsafe 6y ago
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.
- thomaslord 6y ago
  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, pretty much any UI should run more efficiently under Svelte. I'm still a big fan of the developer experience Vue provides and I'm locked into a framework for my work projects so I won't be switching those over any time soon, but I've been meaning to try out Svelte for a personal project some time.
  - phaedryx 6y ago
    "... instead of having render functions that fully replace a component..." No longer the case. Vue 3 was written to have a "compiler-informed Virtual DOM"; there are a bunch of videos about it on YouTube if you're interested.
  - antihero 6y ago
    > Svelte is compiled to essentially vanilla JS How does this scale to anything remotely complex? I've found that if you have a decent knowledge of React it's hard to make anything slow with it.
    - stevenhuang 6y ago
      Nothing beats vanilla JS in terms of DOM manipulation speed. https://stefankrause.net/js-frameworks-benchmark8/table.html https://stefankrause.net/js-frameworks-benchmark8/table.html And Svelte is fast. It's as fast or faster than React in most synthetic benchmarks. For how and why, see https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead (notably the intelligent compilation step which removes need for vdom)
jeswin 6y ago
But I wish new frameworks stayed away from inventing new language syntax. Not only is it a cognitive burden on programmers, it throws all the tooling off. From Svelte: {#each cats as { id, name }, i} JavaScript already has facility for loops and mapping, and relying on that will automatically get you tooling/IDE support. React handles this aspect quite well, and to me that's a point in favor of React. I do agree with your post - especially on hooks being a step backward.
- lhorie 6y ago
  I agree that gratuitous syntax differences are tiring, but in this case, there's actually a very good reason why it's not just using JS. When it comes to reactive systems, you need to be able to statically analyze control flow structures in order to compile to efficient code. In JS, a for loop is a loop, but so is array.map, Object.keys and someLib.each. The loop could be hidden three layers deep in a higher-order function composition from some third party library, it could be tail call recursion, etc. Dealing with this sort of complexity when writing optimizing compilers is very very hard, compared to coming up with dedicated loop syntax, because at any point it's possible there's a value of polymorphic type, a Proxy, a getter/setter side effect or some other crazy JS shenanigan going on. This is why, for example, Solid.js does control flow through <For /> and <Show /> components instead of map/ternaries even though it uses JSX.
  - jeswin 6y ago
    I understand why they did it, but there are alternatives. Such as: import * from "svelte"; // ...omitted for brevity. { svelte.each(cats, ({ id, name }) => <p>Hello {name}</p>) } // ...omitted This is easy to parse and transform, while being fully within JS.
    - swsieber 6y ago
      Until you try to do something svelte doesn't understand. Then it'd silently break. Templates are powerful _because_ of the restrictions they place, not in spite of them. I think a much better recommendation would be an existing template language, iff svelte could understand it with perfect parity. I hate being handed normal syntax to use when not all of it is normal, or when using it has different semantics than the syntax usually carries.
kitsune_ 6y ago
But it's not JavaScript. It's something similar to JavaScript.
ainiriand 6y ago
I agree with your impressions. When I first started working with react professionally one year ago I was thinking I was dumb for not being able to find the logic behind the different moving parts. Now I know that there's none.
StreamBright 6y ago
For me Svelte is between React and Elm. It has some of its own syntax and operator for some benefits. It is better than React in some sense (obviously not in maturity) yet it is worse than Elm (no ML features). If I need to learn some new syntax it is better worth it (no run time exceptions). I am not sure what is the long term plan for Svelte. Is there any plan to address the shortcomings of JS (for example: undefined is a not a function)?
danjac 6y ago
I'd agree on the architecture astronauts, but it would still be useful to see some good open source code bases using Svelte beyond the "todo list" level. For example: - has a test suite - integration with some backend framework (including secure auth) - complex global state management requirements - routing

Aeolun 6y ago

Have you ever worked on very large React applications without Redux or Saga? I just cannot imagine any other way of keeping my application sort of understandable.

buzzerbetrayed 6y ago
You should look at svelte stores if you haven’t already. They are amazing, and make redux seem so needlessly complex and ineloquent

alfonsodev 6y ago

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[1], to your point of things in Svelte not changing as much as in React, maybe it just a matter of time. Here is the video I had in my bookmarks for a while, I still couldn't make the time to watch, so I hope my comment is not too far from reality. [1]https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=875s https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=875s

deleted 6y ago
[deleted]
dan-robertson 6y ago
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 you consider backwards compatibility. I would argue that react has some particular merits (for three the whole vdom based architecture, using jsx, and unidirectional data flow), that it was the first (widely known) framework with those merits, and that it has generally been backwards compatible or only required simple changes. I think these do a better job of explaining why react became popular and inertia explains why it is still popular.
- nawgz 6y ago
  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.

robertoandred 6y ago

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

lhorie 6y ago
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 that throwing promises (as react suspense supposedly does) is a holy grail of frontend development, even though it is "just javascript".
- nsonha 6y ago
  where do I read about this throwing promises thing?
  - lhorie 6y ago
    The crank.js intro blog post is a good place to start[0] [0] https://crank.js.org/blog/introducing-crank https://crank.js.org/blog/introducing-crank
    - scns 6y ago
      Insightful read, thank you.
- steinuil 6y ago
  > 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 straying further from normal js because they don't behave like normal functions do and have special rules for being called; hooks are a DSL for encoding incremental computations into js, and suspense is just the react team fawning over algebraic effects/delimited continuations and trying to reproduce them in js. But then again, all of these can be defined in normal JS code as opposed to a DSL which compiles to who knows what, so all the rules applying to normal JS and its tooling apply to them.

cstrat 6y ago

This comment makes me want to seriously give Svelte a try. I've browsed the docs and it looks really cool, I've always just held back because I feel like I am juggling enough JavaScript libraries in my head already and React has been great.

arxpoetica 6y ago
FWIW, Svelte has a very easy learning curve.

KaoruAoiShiho 6y ago

Is animations just as easy in svelte?

andy-dev 6y ago
Svelte has animations and transitions already built into it, do yeah, it's real easy
- rubatuga 6y ago
  I found animations a bit of a struggle, especially when combining multiple of them. There were performance bugs with some of the combined animations, and the Svelte documentation didn’t make it clear how animations could affect things like the focus on a text box.

yepthatsreality 6y ago

React, Redux, Jest, and it’s ilk always came off to me as a way for Facebook to remain relevant through tech-debt and lock-in.

acemarke 6y ago
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 the new FB.com, and still have a lot of old-school Flux in there as well.
- acoard 6y ago
  >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 working on that project. [0] https://golden.com/wiki/Dan_Abramov_(software_engineer)-99B8RJM https://golden.com/wiki/Dan_Abramov_(software_engineer)-99B8...
  - acemarke 6y ago
    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 https://www.youtube.com/watch?v=xsSnOQynTHs [1] https://github.com/reduxjs/redux/releases/tag/v1.0.0 https://github.com/reduxjs/redux/releases/tag/v1.0.0 [2] https://twitter.com/dan_abramov/status/671135846830075904 https://twitter.com/dan_abramov/status/671135846830075904

mattgreenrocks 6y ago

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

nsonha 6y ago
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.
- k__ 6y ago
  Yes. To be fair, after looking how the whole Redux story went, I think the mainstream simply wasn't ready for immutable state.
  - nsonha 6y ago
    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)
  - mattgreenrocks 6y ago
    It’s a shame. Controlled side effects are a big win IMO, especially mutability.
  - darksaints 6y ago
    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.

MaxBarraclough 6y ago

I've only dabbled with Svelte, but I agree that it looks like an excellent framework, in itself. Powerful abstractions, succinct and approachable syntax, and it compiles down to a truly compact output. (Not the usual only a few hundred kilobytes when gzipped.) I ended up not using it though, as the surrounding ecosystem just isn't there. There are two different material design frameworks out there for Svelte, neither of which I could get to work. I ended up opting for Angular+Angular Material, which worked out of the box.

danjac 6y ago

I did some React development some years ago, and was glad to move away from it because of the ridiculous churn in the ecosystem. It was like building on top of quicksand. At the time, I thought it was because React was new, and new stuff tends to have churn because people are just figuring out the optimum patterns and false starts are to be expected. When I look into React years later, the churn is still going on, which perhaps is a warning sign it just wasn't well thought through to begin with, or that the ecosystem has been captured by architecture astronauts on a lifelong quest for some kind of pure ideal rather than usability and stability.

auganov 6y ago

Neither agree or disagree, but just want to say that's exactly how I felt about Angular when React first came out. It wasn't much of a "framework" at all, just an easy way to render onto the DOM from js. I very much like the idea of compiling code to make direct DOM mutating managable. A very powerful idea regardless of which syntax you end up going with. I wish their website talked more about this instead of having a React comparison on every page.

darksaints 6y ago

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

brailsafe 6y ago

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.

thomaslord 6y ago
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, pretty much any UI should run more efficiently under Svelte. I'm still a big fan of the developer experience Vue provides and I'm locked into a framework for my work projects so I won't be switching those over any time soon, but I've been meaning to try out Svelte for a personal project some time.
- phaedryx 6y ago
  "... instead of having render functions that fully replace a component..." No longer the case. Vue 3 was written to have a "compiler-informed Virtual DOM"; there are a bunch of videos about it on YouTube if you're interested.
- antihero 6y ago
  > Svelte is compiled to essentially vanilla JS How does this scale to anything remotely complex? I've found that if you have a decent knowledge of React it's hard to make anything slow with it.
  - stevenhuang 6y ago
    Nothing beats vanilla JS in terms of DOM manipulation speed. https://stefankrause.net/js-frameworks-benchmark8/table.html https://stefankrause.net/js-frameworks-benchmark8/table.html And Svelte is fast. It's as fast or faster than React in most synthetic benchmarks. For how and why, see https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead (notably the intelligent compilation step which removes need for vdom)

jeswin 6y ago

But I wish new frameworks stayed away from inventing new language syntax. Not only is it a cognitive burden on programmers, it throws all the tooling off. From Svelte: {#each cats as { id, name }, i} JavaScript already has facility for loops and mapping, and relying on that will automatically get you tooling/IDE support. React handles this aspect quite well, and to me that's a point in favor of React. I do agree with your post - especially on hooks being a step backward.

lhorie 6y ago
I agree that gratuitous syntax differences are tiring, but in this case, there's actually a very good reason why it's not just using JS. When it comes to reactive systems, you need to be able to statically analyze control flow structures in order to compile to efficient code. In JS, a for loop is a loop, but so is array.map, Object.keys and someLib.each. The loop could be hidden three layers deep in a higher-order function composition from some third party library, it could be tail call recursion, etc. Dealing with this sort of complexity when writing optimizing compilers is very very hard, compared to coming up with dedicated loop syntax, because at any point it's possible there's a value of polymorphic type, a Proxy, a getter/setter side effect or some other crazy JS shenanigan going on. This is why, for example, Solid.js does control flow through <For /> and <Show /> components instead of map/ternaries even though it uses JSX.
- jeswin 6y ago
  I understand why they did it, but there are alternatives. Such as: import * from "svelte"; // ...omitted for brevity. { svelte.each(cats, ({ id, name }) => <p>Hello {name}</p>) } // ...omitted This is easy to parse and transform, while being fully within JS.
  - swsieber 6y ago
    Until you try to do something svelte doesn't understand. Then it'd silently break. Templates are powerful _because_ of the restrictions they place, not in spite of them. I think a much better recommendation would be an existing template language, iff svelte could understand it with perfect parity. I hate being handed normal syntax to use when not all of it is normal, or when using it has different semantics than the syntax usually carries.

kitsune_ 6y ago

But it's not JavaScript. It's something similar to JavaScript.

ainiriand 6y ago

I agree with your impressions. When I first started working with react professionally one year ago I was thinking I was dumb for not being able to find the logic behind the different moving parts. Now I know that there's none.

StreamBright 6y ago

For me Svelte is between React and Elm. It has some of its own syntax and operator for some benefits. It is better than React in some sense (obviously not in maturity) yet it is worse than Elm (no ML features). If I need to learn some new syntax it is better worth it (no run time exceptions). I am not sure what is the long term plan for Svelte. Is there any plan to address the shortcomings of JS (for example: undefined is a not a function)?

danjac 6y ago

I'd agree on the architecture astronauts, but it would still be useful to see some good open source code bases using Svelte beyond the "todo list" level. For example: - has a test suite - integration with some backend framework (including secure auth) - complex global state management requirements - routing