7 ms·

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.
    - nsonha 6y ago
      > 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 Could you please elaborate this?
      - darksaints 6y ago
        Maybe, it's a bit hard for me to describe succinctly. Your UI as an application likely has dozens, if not hundreds or thousands of potential states. And the more you develop the feature set of your UI, the more states you will introduce to it. The data that represents these various states is going to constantly evolve to be able to represent them: you'll have evolving business state, evolving widget states, evolving URL states, etc. The expression problem can be summarized as a practical comparison of two types of extensibility: writing functions, which extend through composition, and writing classes, which extend through inheritance. The choice of which one is better starts with asking what is more likely to change: your data or your computation over that data. If you have a problem where your data types are relatively static, but the computations you do on that data are constantly changing, pure functional programming is where it is at. You just write different functions to do different things, and then compose them together to do what you want. This sort of processing is perfect for a ton of usecases...things like data pipelines and etl, machine learning, web services, etc. If you have a problem where your data types are constantly changing but your computation is relatively static, you're going to have a very bad time with a pure functional approach. You'll end up having to edit multiple functions just to change a single data type. When you decide that you no longer want to represent your state with an Array<number> and instead want to represent it with a Set<CustomObject>, you're gonna have to refactor every single function that the original version passed through. And with a massive global state object like Redux, that means not just refactoring the component that renders it, but potentially every single component above it in the HTML tree, modifying them so that they can pass it through to its final destination. That is the sort of burden that happens when you fall on the wrong side of the expression problem. For reference: https://wiki.c2.com/?ExpressionProblem https://wiki.c2.com/?ExpressionProblem
    - dwohnitmok 6y ago
  - progx 6y ago
    When people not use something, they are not ready for it? I think they simply don't need it.
  - masterofmisc 6y ago
    Yeah, I feel for dirty admitting this in this forum, but I still use React & MobX for state management. I get to use simple classes with observable state management. Works just dandy for me.
- lhorie 6y ago
  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.
  - nsonha 6y ago
    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.
    - lhorie 6y ago
      Not necessarily. Discoverability is a function of colocation, not of immutability. One can write convoluted Redux monstrosities spanning a multitude of files where it's difficult to mentally follow how a dispatched action translates into state deltas (potentially because of too much higher-order abstractions, but also because one action may affect multiple reducers, and that in turn may affect a multitude of React tree nodes because Context or whatever). Svelte reactivity generally only staying within a single file (with some exceptions) is one approach to align system limitations with "pit of success" in a way that happens to use explicit mutation idioms.
      - nsonha 6y ago
        could you stop saying redux, in my other comment I said the solution could be anything from react's setState to old-style encapsulation. The point is, it's kind of odd that someone'd put mutating states in their tutorial proudly as a "feature". It's a thing that you do very conservatively at best.
ampdepolymerase 6y ago
In terms of influence on society, the New York Times is just as pernicious as any of the FAANGs.
- dimitrios1 6y ago
  This was true before the age of Trump and the ongoing internal war, highlighted by Bari Weiss and more, between the old guard and the new ideologues. I am most definitely not alone when I say the weight of their words have diminished greatly.
danjac 6y ago
Neither did Vue, or Django, or Rails or dozens of other successful and widely adopted technologies. Svelte's issue is probably that it came out a little too late: companies have adopted React, Vue or Angular, and have sufficient inertia (existing codebases and hard-won experience) that there is little incentive to switch just for a slightly nicer syntax or state management model.

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.
  - nsonha 6y ago
    > 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 Could you please elaborate this?
    - darksaints 6y ago
      Maybe, it's a bit hard for me to describe succinctly. Your UI as an application likely has dozens, if not hundreds or thousands of potential states. And the more you develop the feature set of your UI, the more states you will introduce to it. The data that represents these various states is going to constantly evolve to be able to represent them: you'll have evolving business state, evolving widget states, evolving URL states, etc. The expression problem can be summarized as a practical comparison of two types of extensibility: writing functions, which extend through composition, and writing classes, which extend through inheritance. The choice of which one is better starts with asking what is more likely to change: your data or your computation over that data. If you have a problem where your data types are relatively static, but the computations you do on that data are constantly changing, pure functional programming is where it is at. You just write different functions to do different things, and then compose them together to do what you want. This sort of processing is perfect for a ton of usecases...things like data pipelines and etl, machine learning, web services, etc. If you have a problem where your data types are constantly changing but your computation is relatively static, you're going to have a very bad time with a pure functional approach. You'll end up having to edit multiple functions just to change a single data type. When you decide that you no longer want to represent your state with an Array<number> and instead want to represent it with a Set<CustomObject>, you're gonna have to refactor every single function that the original version passed through. And with a massive global state object like Redux, that means not just refactoring the component that renders it, but potentially every single component above it in the HTML tree, modifying them so that they can pass it through to its final destination. That is the sort of burden that happens when you fall on the wrong side of the expression problem. For reference: https://wiki.c2.com/?ExpressionProblem https://wiki.c2.com/?ExpressionProblem
  - dwohnitmok 6y ago
- progx 6y ago
  When people not use something, they are not ready for it? I think they simply don't need it.
- masterofmisc 6y ago
  Yeah, I feel for dirty admitting this in this forum, but I still use React & MobX for state management. I get to use simple classes with observable state management. Works just dandy for me.
lhorie 6y ago
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.
- nsonha 6y ago
  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.
  - lhorie 6y ago
    Not necessarily. Discoverability is a function of colocation, not of immutability. One can write convoluted Redux monstrosities spanning a multitude of files where it's difficult to mentally follow how a dispatched action translates into state deltas (potentially because of too much higher-order abstractions, but also because one action may affect multiple reducers, and that in turn may affect a multitude of React tree nodes because Context or whatever). Svelte reactivity generally only staying within a single file (with some exceptions) is one approach to align system limitations with "pit of success" in a way that happens to use explicit mutation idioms.
    - nsonha 6y ago
      could you stop saying redux, in my other comment I said the solution could be anything from react's setState to old-style encapsulation. The point is, it's kind of odd that someone'd put mutating states in their tutorial proudly as a "feature". It's a thing that you do very conservatively at best.

ampdepolymerase 6y ago

In terms of influence on society, the New York Times is just as pernicious as any of the FAANGs.

dimitrios1 6y ago
This was true before the age of Trump and the ongoing internal war, highlighted by Bari Weiss and more, between the old guard and the new ideologues. I am most definitely not alone when I say the weight of their words have diminished greatly.

danjac 6y ago

Neither did Vue, or Django, or Rails or dozens of other successful and widely adopted technologies. Svelte's issue is probably that it came out a little too late: companies have adopted React, Vue or Angular, and have sufficient inertia (existing codebases and hard-won experience) that there is little incentive to switch just for a slightly nicer syntax or state management model.