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.

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.

This is why, for example, Solid.js does control flow through <For /> and <Show /> components instead of map/ternaries even though it uses JSX.

Such as:

   import * from "svelte";

   // ...omitted for brevity.
   {
     svelte.each(cats, ({ id, name }) => <p>Hello {name}</p>)
   }
   // ...omitted

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.

So the errors remain compile-time, not run-time.

So the developer must remember a new rule: "JS rules when calling foo.each(), Svelte rules when calling svelte.each()". A little harder to remember. Having a unique non-JS syntax makes the distinction obvious.

(Just playing Devil's Advocate here)

There are also technical reasons why `svelte.each` would be problematic, namely the fact that it is a compile-time concept which does not necessarily compile correctly if you move the call into a library, unless you have an extremely sophisticated compiler (aka: a slow compiler)

I am not suggesting that the svelte.each() call be moved into a library; I'm proposing that the callsite is trivial to identify in the AST. Svelte compiler could then do the same thing that it does now.

Grammar enforces where a grammar construct is allowed to exist. A custom grammar can be very restrictive (which it is, to great effect, in Svelte's case).

If we reuse JS grammar, then that comes with expectations of what should semantically work. For example something as simple as `$ = svelte.each` might evade a not-sufficiently-smart compiler. Or maybe `console.log(svelte.each(...))` might mis-compile because nobody ever thought to handle that case.

Having used systems with compile-time grammar constructs that look like runtime constructs, I can tell you that having your expectations about semantics being changed from under your feet can be a very frustrating experience.

Just to be clear, I am NOT saying that Svelte needed to do this. But merely suggesting options for discussion and learning.

[1]: https://github.com/jeswin-unmaintained/isotropy-ast-analyzer... - Here's for instance, some code I wrote for analyzing a JS sort expression. You'd think it'd take just a few hours, until you get to it. Btw, it uses an AST analysis framework I wrote called chimpanzee - it has only one user though. :) https://github.com/jeswin/chimpanzee

In such a case, I think it's less confusing at the end of the day to just have a custom DSL for looping so that there's no clashing with its list of arbitrary limitations.

Which is why we use JS and allow V8/SpiderMonkey/JSC to do it for us :)

[0]: https://bitbucket.org/sonwh98/mr-clean/src/master/

But with Svelte 3 I actually agree with their choice now:

1. The extra templating syntax is rather small and concise. And explicit.

- There are very few directives, and they follow the same rules: `{# start block }{: alternative branch}{/end block}`

- external data that comes from Javascript is always `{data}`

- properties of html components that can be bound are always `prop:name|modifiers={data}`

This is in contrast to, say, Vue, where the syntax can never decide where it's going.

And compared to React, this isn't Javascript either if we think about it:

   {
     svelte.each(cats, ({ id, name }) => <p>Hello {name}</p>)
   }

2. Your work becomes MVC-ish

Your template/html becomes "I have some data, let's display it". And since the template syntax doesn't allow arbitrary logic, you end up collocating transformations of your data with the code that's fetching it. Instead of doing some weird logic inside the template like `data.map.filter.map`

3. But to each their own :)

What really turned me towards Svelte is going through the tutorial and then trying it. It really is good :)

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

Go watch the original React debut talk and ask yourself if React had/has anything going for it beyond Facebook's backing. I know I, and most developers I know, dropped Backbone/Knockout/whatever instantly to use React because it was so obviously better.

Now that unidirectional flow is the state of the art, the difference between the main frameworks just isn't that big. You gain a few things here, lose a few things there, and write a solution that is similar to what you would have written with the other frameworks.

You skipped a huge step. There was angular before react. Which was horribly bloated and over complicated. People wanted something simpler. React, with it's facebook clout won in the end.

Something more simpler: Svelte

Just try it and give it a chance.

I personally heard that 'objectively better' line incessantly from 2015 onwards, with 'it has the largest community' always being a top highlight. Facebook's backing and the celebrities that developed in the JS community around the time certainly played a part in it.

I was working at Groupon and using Backbone at the time and found nesting components to be a major hassle. We used a framework called Thorax on top of Backbone, which helped but still fell far short of React's convenience.

That's not what I intended to say, of course that's not the only reason people choose React, but I think they are valid reasons to help you decide.

For example let's say two libraries are technically different but equivalent productive and nifty, choosing the one that has a bigger ecosystem is a totally valid choice.

Many people had to sell React to their bosses, and the fact that there was a presentation by Facebook, helped a lot, I don't see how stating the obvious is calling lemmings to anyone.

At the end of the day, it depends on your goals and motivations, I can't talk for everyone, I was actually saying some of the reasons that helped me decide on choosing React.

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.

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

Yep, and my interpretation is that, that (the widely known part) happened because it was backed by Instagram first (if I recall correctly) and then Facebook.

And not to invalidate your point but to add another speculation on why React became more popular...

Yes, Angular was backed by Google, but not used in production in massively successful product as Facebook, or Instagram, and I remember also about writing Directives, Services and it wasn't very inviting for third party packages.

When react came out, I remember the selling point was "it's not a framework, it's a library", "it's the V of MVC" and I think that strategy also helped to let the community create all the other pieces, and long term have a richer ecosystem.

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

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.

You can easily read the compiled Svelte output and see how each piece of template is wired to the state. There is very little cruft in it, and no real runtime library to speak of.

The debugging experience (not that I have needed it much) is light years ahead compared to going through React's internals.

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.

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.

I think this is cherrypicking at generalities. It's just as easy to run into a wall with "regular code" because some API doesn't provide what you need. Conversely, DSLs often have escape hatches (e.g. https://www.smarty.net/docsv2/en/language.function.php.tpl)

DSLs are useful sometimes. Heck, the entire web is built on top of DSLs: HTML, CSS, SQL, even JSX. I agree that there are valid criticisms to be made about specific implementations of specific DSLs, but I don't agree that those criticisms are generalizable to the concept of DSLs as a tool in a framework designer's arsenal.

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

That's not the case with Vue, Angular or Svelte. There's framework specific syntax that you need to learn. Eg: '{#each things as thing}' from Svelte's documentation.

Counter in this example is likely a proxy object that knows when it‘s changed and tells svelte to re-render.

It‘s also not immutable, which can cause very confusing interactions in global state.

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.

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.

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.

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.

That's one way to do it, tying discoverability to coding convention (which is usually how collocation is enforced), as opposed to being an inherent property of the code.

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.

Mutating state is actually the de-facto standard across most of the industry. Look at Vue or iOS or Android or Unity or Rails or J2EE... People literally use ORMs to make things more mutable than SQL.

Yes, you can use React setState, but surely it's not lost on you that this is wrapping over a lot of mutable operations too? Worth mentioning as well that setState semantics have some amount of complexity that is attributable to mutability leaking out of the immutability abstraction (e.g. the callback argument, what happens when things like multiple calls to setState occur synchronously, etc). This is the "curse of abstraction" that comes when you are trying to implement semantics that don't exist natively and the abstraction themselves have semantic weaknesses due to the chicken-and-egg problem of the required semantics not existing natively.

I've seen codebases with messy redux and codebases with messy non-redux architectures, and conversely also clean codebases with both types of architecture. There really is no silver bullet technology. The "you can write cobol in any language" thing is always going to be a looming plague.

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

I think they simply don't need it.

This doesn't make sense to me as a criticism of Redux. Redux is a giant state machine. That's all it is. Actions are transitions and the store is the current state. The state transition table is the reducer.

The Redux architecture (and the Elm architecture that inspired it) is about the purest expression of a state machine you're likely to find in any architecture. The fact that a UI is just a giant state machine is the whole reason these architectures were created in the first place.

Redux is tricky and boilerplate-y because of some interactions with React, because it doesn't come with a built-in mechanism for handling interactions with the world "outside" the UI (e.g. interactions with the backend), and because JS doesn't have facilities for immutability out of the box and rather you must bolt on post-hoc solutions.

1. The datastore is a massive global. This already brings to it many of the pitfalls that have caused programmers everywhere to avoid global variables like the plague. But in addition to that, for incredibly complex apps, it is a massive burden to maintain all of your state in one place, without any ability to encapsulate or localize trivial local states. Why do I need a global state tree to determine which option is selected in my select dropdown? Why should I bundle the varying hyperlocalized implications of onChange actions vs onSelect actions with the business implications of things like payment submission states? Why does the state of one button for basic user A have to be bundled in the same data structure as an input element three tabs over, two levels deeper, meant for admin user B with privileged access?

2. Robbed of the concept of benign localized state, all state transitions must be weaved through the entire complex functional tree that renders it. Small refactors of your UI, like moving a widget from one place to a different location in your application "tree", involve not just refactoring the component which renders the widget, but every single component that it passes through, to reroute the data to the right location. It is extremely high touch refactoring, exacerbated by javascript's dynamic nature which is already hard to refactor, and Redux's inability to play nice with static typing tools like Typescript.

Redux's bad ideas do not come from the fact that it models a state machine, it comes from the fact that it models it poorly and forces you into using a giant state machine, intricately threaded and tightly coupled throughout your entire application, when smaller state machines are easier to understand and easier to compose.

Luckily, there is another programming construct that allows you to easily model state machines, and allows you to build them arbitrarily large or small to meet your demands, and allows you to encapsulate data and actions extremely well so that state and associated actions do not leak. They're called classes.

- https://redux.js.org/faq/organizing-state#do-i-have-to-put-a...

- https://redux.js.org/style-guide/style-guide#evaluate-where-...

- https://redux.js.org/tutorials/essentials/part-2-app-structu...

A single global state machine and a bunch of small state machines can be losslessly transformed from one to the other. And indeed Redux offers tooling to transform from one to the other depending on preference (this is the Redux Toolkit).

And indeed in that world they don't have to be bundled together. You can have separate state machines for different parts of the page.

> Robbed of the concept of benign localized state, all state transitions must be weaved through the entire complex functional tree that renders it.

As you say, this is really just a specialization of 1 right rather than a separate problem?

> They're called classes.

Classes of course can model state machines since any Turing complete style of programming can model state machines. However, they are significantly different from the classic representation of state machines in that the important part of representing state machines is that you can inspect their state. Classes are meant to be opaque; as you say their encapsulation is a feature.

But their opaqueness prevents the usual state machine composition, which is to link different state machines together based on the states they are currently in. Whether or not that's a good thing depends on the circumstances, but they make it painful when you really do want to represent things as a state machine proper, and not simply as a stateful component. And to the extent that you want a UI to be a state machine, that's a bad thing.

Of course not all parts of your UI should be a state machine, especially things that involve continuous states rather than discrete ones. For truly mind-numbingly benign stateful details (such as which frame a button should be in while performing an animated transition from one color to another) you can just put it directly in the React component and ignore the store altogether, and that's definitely where you really don't want explicit state machines, but rather encapsulated black boxes that are stateless from the perspective of the overall system (which is effectively what a component-based/class-based system looks like when interacting with a state machine).

Why? Is that because you need to know if a transition is valid for a given state? Do you have a citation for this?

> Classes are meant to be opaque; as you say their encapsulation is a feature.

This is true, but in practice, people do expose things in classes. I regularly implement state machines in classes as immutable builders.

> But their opaqueness prevents the usual state machine composition.

Not sure what you're refering to by this. Sounds like it's based on a specific implementation. 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 complete in most cases, can always model the latter.

But to return to the meat of your questions:

> Why? Is that because you need to know if a transition is valid for a given state?... Not sure what you're refering to by this.

In a manner of speaking yes this is about validity of transitions, but it only shows up when you're making a bigger state machine from smaller ones.

What I meant by "state machine composition" and "important part of representing state machines is that you can inspect their state" relates to the combinatorial explosion of states that occurs when you build a larger state machine from smaller state machines.

When you combine state machines naively you get a new state machine that is the combination of all its child states (the n-tuple of all the child states). These usually (but not always) are not all valid states at the parent state level. That is usually, at the parent state level, only some subset of the combination of every possible child state is a valid overall state.

This means, if you're thinking of things purely as state machines all the way down, you don't want your child state machines to be black boxes. Instead, you want to be able to form relationships between the different child states to be able to constrain them in different ways. In a statically typed language with algebraic data types this might show up as various different sum types that are subsets of tuples. In a language without sum types this often ends up being basically the visitor pattern. In a dynamically typed language this might show up as various assertions about the overall n-tuple. Either way, you need some way to "open up" the child states to inspection by the parent state.

Now sometimes, your parent state truly is the n-tuple of all its child states, i.e. the child state can be any state at all and this is still a valid parent state. At the UI level, this is usually true for anything a user would be unlikely to care about if the page were to refresh and that state was reset, for example the state that governs the animation of a flashing button, or a drop-down menu being open or closed. This is what I meant when I said "black boxes that are stateless from the perspective of the overall system." From the parent system's perspective, if the child component is a black box, you could substitute that child component with a completely stateless placeholder (e.g. a static button) and the overall system would not be in an incorrect state.

And it is precisely these places where it is most convenient to use opaque child states to model things.

However, most "significant" things in a UI are things where we do care about constraining the n-tuple of child states to a subset. We often want certain parts of the UI to gate other parts of a UI (e.g. greying out certain parts of a UI), or want certain actions in one part of the UI to cascade in a specific way across the rest of the UI.

Don't get me wrong, getting back to the beginning of my reply, I'm by no means saying that this is impossible with opaque classes. After all there have been people making perfectly functional UIs with opaque classes for a long long time. It's merely more annoying and bug-prone.

If all your child states are opaque, then all this subsetting of valid states is implicit in control flow rather than explicit in data definitions. And as Fred Brooks put it: "Show me your flowchart [control flow] and conceal your tables [data definitions], and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."

I'm not sure what you would want from a citation? Somebody other than me saying that the important part of representing state machines is being able to inspect their state? Would you accept prior art? Languages that are explicitly built to model state machines, such as TLA+, generally expose the state explicitly by default and build all their reasoning facilities around manipulating the state directly (TLA+ is indeed generally not an executable language, but there aren't many executable languages I can think of at the moment that really go all-in on making everything a state machine like TLA+ does and so aren't great illustrations of what pure state machines are like; Elm does this as well, but Elm and Redux are the same core approach so it doesn't really count in a discussion about Redux).

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.

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

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'

However, I should point out something that is not actually trivial about your code, by proposing a refactor: your FSM adequately models a car lock button interface, but not the lock itself. If we are modeling the lock, you have two invalid transitions...because it is impossible to lock an already-locked lock, and it is impossible to unlock an already-unlocked lock.

Classes actually shine quite well here.

    class On {
      constructor(){
        console.log('turned on')
      }
      turnOff(){
        console.log('turning off...')
        return new Off();
      }
    }
    class Off {
      constructor(){
        console.log('turned off')
      }
      turnOn(){
        console.log('turning on...')
        return new On();
      }
    }

    const toggle = new On();
    toggle.turnOff().turnOn().turnOff().turnOff()
    //     ^ cool,    ^ cool, ^ cool.   ^ oh shit, typescript really doesn't want to let me do this. 

However, Redux is meant to be for UI work, which is a side effect. You cannot control side-effect. You cannot guarantee that user will not try to turn switch off twice.

Even in idiomatic Redux, the switch case for reducer always include `default:` which mean everything else go here.

As you said, the Redux FSM models a car lock button interface which is exactly what Redux try model.

It is indeed all a matter of taste in the end, but I mean it's the exact transcription of a textbook FSM. I don't think your example would get that much simpler with a stable identifier, which brings me to:

> I don't have to create a monolithic state transition table logic

It doesn't have to be monolithic. I just created a monolithic function because it's easier for this small example. It could just as easily dispatch on state (which is what you're doing here), or on transition (which is impossible with your hierarchy), or mix and match them. I can write those examples if you're curious.

Your class example is a good example of a state machine trace (e.g. one that you might often use to create an ephemeral config object), but it's not an example of an actual persistent state machine. As soon as you use a stable identifier the type safety goes out the window.

  let stateMachine = new On();
  // Wait a bit for the user to do something
  stateMachine = statemachine.turnOff();
  // Wait again for the user to do something
  stateMachine = stateMachine.turnOn();

Indeed if you just care about a state machine trace the same type safety holds in the explicit state transition table case if you just use TS's literal types in the reducer's type annotations. You just explicitly call the reducers you need however many times and then persist the state machine at the very end.

That is your type safety doesn't come from the representation as an object, but rather that there is no stable state machine between invocations, but only an ephemeral trace of one whose intermediate states are immediately destroyed. Traces are valuable! But you could generate the exact same trace with an explicit state transition function and you would get the exact same type safety that way. I can write it out for you if you're curious.

> I will never have to worry about the combinatorial explosion that can happen in a global transition table.

Again you don't have to worry about a combinatorial explosion in a global transition table either if you dispatch on actions or states.

The fundamental difference between what you've outlined here and the explicit state transition table is that in your approach states are first-class and transitions are not (but rather methods attached to states), whereas the explicit state transition function treats both of them as first-class entities.

For places where you really only need an ephemeral state machine trace, rather than a state machine that persists between calls, you don't need first-class transitions because the transitions are all ephemeral and cannot be dynamically called at runtime.

Where you do have users able to dynamically call transitions at runtime, you end up needing to represent those transitions somehow, and you end with something approaching Redux (indeed I think an interesting exercise would be to implement On and Off where the user either presses "a" or "b" at the keyboard to turn on and off with your classes. I suspect you end up with just the Redux approach all over again).

EDIT: I want to emphasize I don't think Redux is free of faults. There are many things I really dislike about it and the React ecosystem it integrates into. But I don't think any of that can be chalked up to a poor representation of a state machine.

whose type signature has start and end state

> first-class entities

a string

As do the reducers. For example the following is a valid type signature.

  function onToOff(initialState: "on", transition: "toggle"): "off"

I chose string for simplicity (string literals happen to be distinct types on their own, I could easily use anything else other than strings, e.g. interfaces). Heck it could just be integers and be even simpler.

> Heck it could just be integers and be even simpler.

statement that has zero point, why make them?

> As do the reducers

like this? A | B | C => B | C | D

does that look like a state machine? Because state machine is this A => B & B => C & C => D

The other commenter gave example of implementation as type safe immutable builder. You can even simplify their implementation further by using plain functions instead of classes.

> Redux's bad ideas do not come from the fact that it models a state machine, it comes from the fact that it models it poorly

So to me it doesn't really matter whether class is the best tool to implement state machine.

If the argument is "you can do it with class/function/language feature x, however it's a lot of work to achieve composition or whatever", then the same can be said about redux: it kind of looks like a state machine, but in order to have composability/validation/static types etc, you still have to apply a bunch of "patterns". So it's just as effective (or ineffective) as the approach of rolling your own state machine.

Again, Redux is the purest expression of a state machine possible in a general-purpose programming language (as opposed to a specialized one like TLA+). It maps one-to-one with the usual textbook definition (technically textbooks don't have a rigorous definition for state machines, but rather finite state machines, but usually by "state machine" we just mean you take a normal FSM and just relax the finite bit by introducing some infinite component into the overall state such as an arbitrarily long list). The store is the state, the actions are transitions, and the reducer is the state transition table.

Redux's infelicities come precisely from the fact that it needs to interact with things that are not modeled as state machines! Namely, interacting with black box children and the outside world (mostly sending stuff to the outside world, Redux comes with stuff out of the box to deal with just one-way inputs from the world). And Redux doesn't come with ways out of the box to deal with those so you need to layer more stuff to make it all play nicely together. But you need at some point to interact with them to work with the JS ecosystem so you need that stuff.

If you had state machines all the way down you don't need any particular patterns other than the fundamental state machine description! Especially with Typescript's structural types, everything just works (you just pull out chunks of your store into little stores and pull chunks of your big reducer out into little reducers, it's literally just cut-and-pasting chunks of your code and giving it a new name and making new state machines all the way down).

The friction comes from interacting with React, dealing with the outside world, and figuring out various decisions of what to do about data structures that the JS stdlib doesn't decide for you out of the box (e.g. what immutable library should one use). Even the choice of mutable vs immutable is something that is decoupled from Redux proper (it turns out for incidental reasons it's easier for type systems to properly scope local effects with immutable data structures than mutable ones, but that's more an artifact of Typescript than Redux, see e.g. Rust's type system for a counterexample).

If all of that was just more state machines (and the stdlib issues were taken care of) then Redux would be absolutely lovely.

And that's not just a pie-in-the-sky hypothetical. E.g. Elm is basically what Redux would be if everything was state machines and works great in all the places Redux doesn't (Elm's infelicities in turn are of a different variety that stem from some limitations of its type system to properly express some of the structural types you'd like state machines to have, in particular a lack of structural union types that often requires duplicating the state transition table in certain ways as you break a larger state machine down into smaller state machines).

A global state object is one of the nicer features when dealing with redux.

Could you please elaborate this?

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

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.

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.

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.

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.

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 (notably the intelligent compilation step which removes need for vdom)

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.

My commentary is more directed at React and Jest (as I try to steer away from that ecosystem, even though it's ideas aren't all bad):

- As GP indicates, React has had multiple API implementations to solve similar problems, feature bloat, leading to opinionated and differing best practices, mixed in with Junior devs can be a nightmare

- With Jest, I find the entire thing as a very aggressive wrapper and very tied to React itself, features like unit test `snapshots` are developer slack-off bait and have the benefit of further entrenching itself into the repository, arguably an e2e test would validate the same thing

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)-99B8...

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

- has a test suite

- integration with some backend framework (including secure auth)

- complex global state management requirements

- routing

I don't understand this worry, but I guess that happens when you try to do everything with hooks, the way I settled in my approach is to use React components just for the view without hooks, nor lifecycle logic, just dumb components with ocasional local state (useState)

Then using Controller pattern, within the controller I use 4 types of hooks, 1 navigation (useHistory), 2 read global state (useSelector), 3 dispatch an action (useDispatch), 4 useEffect() to execute on props change or component mount.

That's it, that's where the realm of React and UI ends for me, everything else is in Ducks, Ducks are single file or folder per module that contains Actions, Epics (Obervables) or Sagas (generators), Reducers, initial state of store and Typescript types.

I really like this separation of concerns:

- dumb components: to worry just about the looks and local state.

- controllers: to worry about data in, actions out, life cycle and navigation.

- Ducks: Management of data fetching and global state.

I wrote this from the top of my head, but if anyone is interested I'm thinking about writing a demo repository and document this approach, maybe others have done it already this is not new, but practices that I've been collecting along the way.

Let's break down the terminology:

- hooks

- useEffect

- useHistory

- useSelector

- dispatch

- action

- useDispatch

- ducks

- Actions

- Epics (Observables)

- Sagas (generators)

- Reducers

Most of those terminologies don't come from a general programming paradigm, but are the domain language of specific libraries. And I've seen more, with some places establishing patterns like Compound/Molecule/Atom and such. There's no consistent, underlying principle with them, though. If you're invested in Sagas then you're stuck with a bizarre threading model implemented with generator functions and it's pretty much all-or-nothing. If you're invested in Redux then there's no breaking out of that either, you're always going to be contending with shared global state.

I really hate to think how many collective hours have been wasted on new coders who learn JavaScript as their first language --- especially when starting with React and Redux, as it's often taught --- and end up spending most of their time spinning their wheels on these domain-specific complexities, when they haven't even gotten to "while loops" yet. This may even be harder for beginners than understanding, say, one of the classic CS sorting algorithms. New coders don't realize though that whatever degree this stuff is harder, it's a sign of bad tooling or documentation, not that it's somehow intrinsically a harder problem in math / CS, since if you're new you don't know what to expect

That alone is a concern, because any junior programmer getting an introduction through React is going to get a twisted understanding of the language itself.

But in terms of the industry-standard practices/ecosystem, it is a terrible first language if you want to gain a generalized understanding. What you describe here is extremely true; I've seen it in practice:

> any junior programmer getting an introduction through React is going to get a twisted understanding of the language itself

I've talked with otherwise very capable JS devs who have built impressive things with multiple frameworks, but don't have a good handle on fundamental concepts like the difference between the two kinds of function syntax (they may have only ever used one), how Promises behave outside of a narrow subset of situations, what NodeJS actually is (despite having used it), or even the difference between passing by reference vs value.

Many of these frameworks create such a narrow lens into the language itself, add what are effectively (sometimes literally) their own DSLs on top, sprinkle in some magical behavior, and when all is said and done you hardly end up using JS at all.

Obviously there's a benefit from doing things this way or it wouldn't have happened. But I can't help but think the technologies that work well for industry are having a detrimental effect on a generation of new programmers.

And so much of the industry everywhere is about “do X to get Y result” and any further reflection is kindof a luxury. How does your package manager work? Part of the point is not to know, which works until it doesn’t. So we all get trained into basically a culture of issuing commands in a manner not too different from the machines we ask to do the work, and developing a model of what’s going on is either bonus study or earned by running your hands over the sharp edges when you’re bucked onto the unhappy path.

Which definitely happens outside of JS. I suspect it happens more inside because JS functions as maybe the biggest funnel into the field.

There is more than 2 now. :)

You have the keyword function, you have

const myFunc = (param) => { //body }

and then you have the various types that can occur within a class, which can have a little bit different behavior based on which syntax you use.

Fun times!

And remember, arrow functions within a class have a this, but arrow functions outside of a class don't have a this!

This is not correct. Arrow functions have the `this` value of the outer context.

I recommend this article to understand `this`: https://web.dev/javascript-this/

You are correct, I wasn't clear. I was describing the end effect of free floating arrow functions VS an arrow function declared within a class.

When free floating, trying to access 'this' can (will) result in unexpected behavior, when inside a class arrow functions operate exactly as people expect a class member function to operate in other languages. (In contrast to having to otherwise bind JS functions to 'this')

In both cases the arrow function is acting the same way, but most intro to JS lessons don't explain it.

Indeed the way it was originally explained to me is that "arrow functions in classes auto bind to this" which is hilariously inaccurate, but the end effect is as if that was happening.

You can only pass by value in JS so maybe that's why. It is a bit confusing because of how objects work that it feels like you are passing by reference. You are passing reference as the value.

I once talked to someone with >5 years front-end experience, including some team-lead experience, who thought the difference between == and === was that === compares objects deeply. That is very, dangerously wrong. The only way I can imagine he got by for so long with that misconception is that he'd always used ImmutableJS.

A variable stores reference to the original object and when you pass it to a function, it passes the actual reference as the value.

I think the last part you mentioned is actually confusing in js because lack of clear guidance.

isXyz, Xyz.isXyz, Object.is, and other ways are used in practice to do the same thing but they all have different behavior which trips people.

    function someFunc(v) {
      v.myvar = 456;
      v = someOtherObject;
    }

    var foo = someObject;
    foo.myvar = 123;
    someFunc(foo);
    // foo still refers to someObject
    // foo.myvar is 456

Passing a reference to an object is not "pass by reference". Your example works the same in Java and C# and probably Swift and many other languages. But you aren't "passing by reference". "pass by reference" specifically means passing a reference to the variable, not the variable's value. Javascript always passes the value of the variable, it has no ability to pass a variable by reference.

Having spent my career in languages with pass by reference it feels unnatural not to have it. I suspect if I started with JS this wouldn't be such a problem.

It's still pass by value, you are passing the reference of the object as a value.

  let a = { foo: "bar" }
  let b = { foo: "bar" }

  console.log(a === b)  // false

  let a = { foo: "bar" }
  let b = a

  b.foo = "blah"

  console.log(a.foo)  // "blah"

The distinction is that, if JS truly was pass-by-reference for objects, you could change what the reference was pointing to. But you can't.

I agree with you that objects/references are a stumbling block for new programmers in JS. You have to understand how these things work but there's no explicit concept of a reference, which means it can be tricky to learn.

That's only true if you're passing the pointer by reference. That's different from passing the object itself by reference.

I did just look up the C++ semantics and learned something: technically reference-arguments don't have to be implemented by the compiler as pointers, though in practice they mostly are. So in that sense it's technically more correct to say that JS works with object pointers and not references. But we're really getting quite deep into the weeds at that point.

https://stackoverflow.com/questions/5893873/pass-by-referenc...

That's how all mainstream languages with a GC work, Java, C#, Ruby and Python, it's not particular to JS. And this why why languages like Clojure are nice to work with.

but it also isn't important

It's important if you really want to know why your examples work they way they do.

We're specifically talking about new programmers who haven't used any of those languages, and who are being reared in the JavaScript ecosystem where certain patterns reign that obscure this language behavior. That's what the original discussion was about.

> It's important if you really want to know why your examples work they way they do.

It's really not. Pass-by-reference and pass-a-pointer-by-value are subtly different concepts even in the C++ world, and using terminology that involves the word "pointer" opens up a whole other can of stuff that needs explaining.

That said, vanilla JS can be hard like this as well, especially as "solved" legacy issues still regularly crop up in tutorials and code-bases. Many times I remember helping newer folks with challenges they found online that seemed to them like they were testing hard computer science problems, but were more just trivia to navigate some bad design decisions of JS (eg gotcha problems on "this" / binding, IFFE, hoisting, async/promises/callbacks, to name a few)

As a beginner, you should start with plain JS/TS. When you dealt with the hell of manipulating DOM elements all over the place and untraceable UI updates after hours of debugging, you should move on to some UI library. Only then will you understand and see what problem it solves. Then you should go with React, but not hooks or redux. Use plain old classes. When you felt the pain of distributed mutable state all over place, you will be open to hooks or redux etc. Still, do not add a library for thunks. Only after you realize how much boiler plate code you write to deal with async stuff, you will see a value in the added abstraction.

A beginner should start simple, and really feel the pain. Only then will there be an "a-ha!" moment where you can judge if a library/framework actually helps you and provides value.

The biggest issue in FE world is people proclaiming some given conglomerate of a library/framework soup as the silver bullet to all problems.

Don't feel to bad for them, that's our entire craft. `while(true)` and sorting algorithms are not.

Bad (but popular) tooling isn't new --- I remember learning PHP4 was like an encyclopedia of gotchas and defensive programming --- but I feel that even a disaster like PHP4 was a lot more approachable for new coders than the state of the art now, and that the skills learned overcoming these things were more portable outside of the framework / language. All of this definitely makes my job more secure, but, I dunno, still feels like a real shame.

- Dependency Injection/IoC - Containers, Resolvers, Scopes - Microservices (Circuit Breaker anyone?) - DDD + CQRS (i could fill a whole page with terms coined by those) - Mediator Pattern etc.

If you buy into a certain techstack, it will always bring associated patterns that have nothing to do with the original language/idiom.

Once you understand hooks in general, any specific hook should be quite straightforward so they can collapse into one. Hooks are quite novel, but I don't find them to be overly complicated unless you're dealing with an already complex situation.

Dispatch, actions and reducers can be collapsed into one since they rely on each other. I think this paradigm is not too dissimilar to message passing with something like RabbitMQ. Reducers are a common concept.

Ducks and Actions, Epics and Sagas are just a convention. It's not required to use React or Redux.

If you try to learn everything at once, of course you're going to get overwhelmed. But the same is true for almost any area of Software Engineering.

To me the proxy object (or proxy class) is really the best abstraction - much like valtio. Or a compiler like svelte.

There’s no reason for ducks, epics, sagas, etc etc. We have a programming language already, we should use it.

It's the same explaining a fully kitted out backend (Routing, caching, authentication, etc) and then going "see, it's so complicated!". Well duh, it's a big and complex system.

I think the issue with valtio is that there's no central store. As far as I can see, you'll end up having these proxies scattered around your codebase or you'll end up re-creating Redux and centralizing them.

Also, I have ironically never heard of valtio.

Also, you can easily wrap valtio with:

  const createStore = (name, store) => {
    if (window.stores[name]) throw 'store already exists'
    window.stores = {
       ...window.stores
       [name]: valtio(store)
    }
  }

If you ever did VB development in the 90s, you will know how easy it was to get a basic app running with those fancy Drag'n'Drop RAD tools. But there was no networking, everything worked offline. But then came the web and the networks, and now everything has to be a distributed system.

If you eventually get access to the data, does not matter how many layers are in-between (REST, SOAP). You still got the data, so that's a "god mode" in the same sense.

Dispatch is how you emit an event (pub in pub/sub). Action is the event being emitted.

Ducks is a code organization paradigm (colocation, organize by feature instead of layer).

Reducers are what they sound like: a reduce function.

Sagas and observables are how to perform side-effects in your application.

There is nothing new here. You could argue that hooks are the weird ones but they are heavily inspired by algebraic effects.

Not really? Most of these concepts can be linked back directly to earlier from CS theory and/or other languages. For example, Redux taking inspiration from FRP and functional lenses, or (most pertinent for this thread) hooks being a facsimile of algebraic effects in JS. As much as I like these concepts in general, I feel some go too far against the grain of what is idiomatic in the language and incur unnecessary friction/spooky action at a distance because of it. For example, here [1] are some well thought-out critiques of hooks and why people struggle with them from experienced JS framework authors.

[1] https://news.ycombinator.com/item?id=22903967

I agree. Frontend is tough, but so is development. ;)

You don't even realize how bad the boilerplate is until it's all gone. With svelte and some writable and readable stores, I can build apps in a fraction of the time because every time I want to make a change I don't have to start with an action creator, than integrate that into the reducer, then write a selector, then pull it into my component. Oh I guess I need to write an epic with rxjs to fetch the data.

Svelte has 2 primitives that replace all of this: readable and writable. You can create a writable store and you call `.update` or `.set` like react setState. Want to separate your update logic from your component logic like in redux? Easy, just export functions to update the store instead of calling `.update` in your components.

Then, there's readable. Now, readable can be used like a reselect selector, but it's also far more powerful. You can subscribe to changes from a writable, or even other readable stores. You can create a readable that fetches your data. You can create a readable that subscribes to firestore collection or document. You can make a readable that combines data from multiple sources. It's all clear and composable. And I didn't have to write an action creator with an action constant called `LOADING_PRODUCTS`, and one called `LOADED_PRODUCTS`, and then one called `UPDATED_PRODUCTS`, and for good measure we should also create an action "PRODUCTS_REQUEST_FAILED" that we'll emit from the epic.

This sounds very similar to the experience of using MobX. I evangelize it as an alternative to Redux every chance I get; it's incredible how practical and pleasant it is to work with.

I also evangelize it whenever I can -- I don't want MobX to be forever doomed to its status as a cult hit!

1) Observables are properties on objects; when their getter is called, it becomes "tracked" (subscribed to) by the currently-running tracked function. When their setter is called, it publishes to all subscribers. This happens through JS proxies for plain objects, and class decorators for class instances.

2) A tracked function is anything that must be re-evaluated when an observable it depends on is modified. This includes React render functions, computed functions, and any other side-effects you've created via autorun(), reaction(), etc. Though the idea is to avoid side-effects, so 90% of the time it's just render functions and computed functions. In these cases it amounts to a cache-clear on a pure function: "the return value will be different, so re-evaluate it and use the new return value". A computed function is an observable property getter that's also a tracked function (it doesn't have a corresponding setter; instead, it publishes when it's published to).

3) Tracking works by a) marking global state before a tracked function is run, b) making note of any observables that report back during that time, c) clearing the global state (and subscribing to the observables) when the tracked function completes. Because this is done temporally based on before/after the function has executed, any nested function calls get treated exactly the same as the top-level function call. There's no special magic necessary for that.

That's about all there is to it. Everything else in the library is just another permutation on these concepts.

It's a heavily-commented, minimal reproduction of MobX's core functionality for the purpose of understanding

And I don't have them, instead this is how you create a type safes actions with typesafe-actions package.

  export const signIn = {
    request: createAction("auth/signin/request")(),
    success: createAction("auth/signin/success")<{ user: User }>(),
    error: createAction("auth/signin/error")<Error>(),
  };

Not trying to sell you on Redux, just to address your point about the constants.

About having to write many Epics, well, end of the day, all the Epics have this shape.

  export const signInEpic = (action$: Observable<Action>) =>
    action$.pipe(
      filter(isActionOf(signIn.request)),
      switchMap(() =>
        from(signInLogic()).pipe(
          map((user: User) => {
            return signIn.success({ user });
          }),
          catchError((error) => of(signIn.error(error)))
        )
      )
    );

I'm not claiming it's superior approach or faster, it's an approach that worked for me for medium/large apps, to collaborate with other developers.

I'm pretty sure you are right about the Svelte cool things you saying I wish I had more time to look into it.

https://redux-toolkit.js.org

https://rtk-query-docs.netlify.app

We're working on finalizing that API and will be merging the functionality and docs back into RTK itself for an upcoming RTK release:

https://github.com/rtk-incubator/rtk-query/issues/175

I 100% agree with this, I also started out working with Redux in the fairly early days of React and while I do feel that I did learn a lot from it and have used Redux-inspired patterns for certain parts of applications since then, the productivity gains I got from switching to MobX for state management can't be overstated.

Sure, you could argue it's less "clean" or whatever, but honestly 99% of the time it just works, and I'm happy to have the 1% of time where you're debugging where you forgot to add "observable" or whatever in exchange for the 99% productivity boost.

Svelte does look really interesting and follows a similar kind of model to how I work with React and MobX, and does away with some boilerplate/gotchas.

My main concern using it would be around maturity of libraries... while it does seem pretty batteries-included, I have got used to being able to just pull in a library for x, y or z in React and I'd be worried if I started a big Svelte project, I might find myself kicking myself down the line e.g. if I need some component (data table or whatever) that has a mature option available in React. Perhaps people who've worked with Svelte professionally can comment on whether this is a valid concern?

If you get a chance, I strongly recommend reading through the newly rewritten official tutorials in the Redux docs, which have been specifically designed to show both how Redux works and show our recommended practices:

- "Redux Essentials" tutorial [0]: teaches "how to use Redux, the right way", by building a real-world app using Redux Toolkit

- "Redux Fundamentals" tutorial [1]: teaches "how Redux works, from the bottom up", by showing how to write Redux code by hand and why standard usage patterns exist, and how Redux Toolkit simplifies those patterns

The older patterns shown in almost all other tutorials on the internet are still valid, but not how we recommend writing Redux code today.

You should also read through the Redux "Style Guide" docs page [2], which explains our recommended patterns and best practices. Following those will result in better and more maintainable Redux apps.

Finally, we've got an upcoming "RTK Query" API that we're finalizing and adding to Redux Toolkit (inspired by tools like React Query and Apollo) , which should drastically simplify the data fetching story for Redux apps.

[0] https://redux.js.org/tutorials/essentials/part-1-overview-co...

[1] https://redux.js.org/tutorials/fundamentals/part-1-overview

[2] https://redux.js.org/style-guide/style-guide

[3] https://rtk-query-docs.netlify.app

Oh, look, slices, and thunks, and asyncThunks, and extraReducers, and adapters, and fifteen files to tie all this together for every small piece of api or data that you want to send around.

Most of it just comes from the fact that Javascript doesn't have a good built-in way of doing these cycles fo data/store updates. And still, I don't know where the sweet spot of Redux it: it's an overkill for small apps, it's unmanageable in big apps.

However, I will concede that the new hooks like `useDispatch` are nice

It's also definitely _not_ "15 files to tie this all together". In fact, we specifically recommend writing all the Redux logic for a given feature in a single "slice file":

- https://redux.js.org/style-guide/style-guide#structure-files...

- https://redux.js.org/tutorials/essentials/part-2-app-structu...

The page is a tutorial for a TODO list with only the simplest and the happiest paths. It's not a forum just because you called it a forum, by the way.

OT: I wish the JS world would stop doing TODO lists. A TODO list is a glorified `Array.push`. If it takes your library/framework 10 000 words to explain how to do Array.push, it doesn't mean that a TODO list is a good example on which to base a tutorial. It means your library sucks. If you want to show how great you library is, implement this: https://tonsky.me/blog/datascript-chat/ (demo: http://tonsky.me/datascript-chat/) and manage to describe it in as many words as on that page.

Back to the topic at hand.

The problem with Redux is: it's concept is very simple. The implementation is a poorly specified DSL with isolated parts that barely fit each other, if at all. And even with all the simplifications it can barely manage to make a TODO list with happy paths.

Here's where it all falls apart:

- It looks like I can't use async functions in `createSlice`. I must use a separate `createAsyncThunk`. Because reasons. Because in a world where every single app needs async data fetching "if you want to have async logic interact with the store by dispatching or checking the current store state? That's where Redux middleware come in.": https://redux.js.org/tutorials/essentials/part-5-async-logic

So, suddenly, it's not "we've simplified everything", it's the same old: we need thunks, and middlewares, and whatnot to do data fetching.

Note in that page how `createSlice` (which is an action creator with reducers and stuff) and `createAsyncThunk` (which is an action creator for which you have to provide a store separately, and reducers to that store separately) don't ever fit with each other except through additional boilerplate code. This is especially visible in `features/posts/postsSlice.js` towards the end of the page

And why does everything need a dispatch anyway? Can't everything already be wrapped in a dispatch so that you just call a function?

- There's almost nothing about errors that will inevitably pop up.

Almost no part of the tutorial ever shows how to deal with errors except the "ah, it will magically dispatch an error message to the store, we store the message on the store".

What happens if I run into an error in a "reducer" (which is reducer-slash-action-creator) in `createSlice` and want to dispatch some action? Oh, wait, you can't dispatch actions from a reducer.

What happens if I run into an error in an action created with `createAsyncThunk` and I need to not only return an error, but dispatch some other actions?

- All this is just so, so badly specified. Everything is hidden behind "detailed explanations" that actually try to explain what's going on

For example, the fact that createAsyncThunk magically creates `.pending`, `.fulfilled` and `.rejected` on an action is not explained except sort of in passing.

And there's suddenly a magical `unwrapResult` function that's not even mentioned anywhere. What is the result of an action? It's not in Part 1 or Redux Concepts and not in Part 1 of Redux Fundamentals. I very quickly scanned the rest of the War and Peace novel, and I can't say I found it.

And there's more. I just can't quickly read and grok the 20 volumes of dense prose just to figure out how to push data into an array.

"Async logic and data fetching are always a complex topic." Nope. It's not. Redux makes it a complex topic.

---

So yeah, it all very quickly devolves into the very same "15 different files for every small action". You may collocate some of them in a single file, but that doesn't make them even closely related to each other in any meaningful way.

That's why I said, "I don't know where the sweet spot of Redux it: it's an overkill for small apps, it's unmanageable in big apps."

And it's not all bad. The biggest step towards simplifying Redux have been hooks. `useDispatch` and `useSelector` are really good. Even though we have to admit that they are solving the issues that Redux introduced in the first place :)

I agree that React folks (me included) tend to reach out to Redux much too soon, though.

As an fyi for anyone not aware, there are eslint/tslint plugins for this to help avoid it.

Not that the answer to a complaint of a complex toolchain is more tools in the chain, but it's a wonderful development experience once you develop a collection of tools you really like.

The UI components all have an else render if for some reason they're missing something / it avoids a crash (along with other easy to see / figure out protections)

Of course, what you see is just a tip of the iceberg, having implemented a nice admin and moderator dashboard, keyboard shortcuts, animations, 12 different color themes (in light and dark mode), and more. Svelte just made it all so easy to do. Having done a good bit of React and Angular professionally, and tinkered with Vue, I can safely say (for now) that all I want to do is Svelte. The rest just seem so heavy handed in comparison.

Self promotion: I also run a YouTube channel where I'm slowly building out a Svelte app with Rails API backend. If you're interested in Svelte, please check it out: https://www.youtube.com/user/iamdavidwparker

The one issue I had with Svelte was Sapper - I didn't get on with it (it wasn't a good fit for either of my projects). SvelteKit was released in beta a couple of days ago - I've no idea how much that changes things. I'm hoping I don't have to relearn a whole bunch of stuff to use the new shiny.

[1] - https://rikverse2020.rikweb.org.uk/ (Warning: Poetry!) [2] - https://scrawl-v8.rikweb.org.uk/ - I was quite proud about getting my canvas library to play nicely with Svelte

I plan on migrating to SvelteKit once it's stable, and may start migrating some of my smaller sites over in the meantime.

Also, no need to warn about poetry- more people should write from their heart IMO.

Quick question: which color scheme are you using in VSCode? It looks a lot like jellybeans for vim, which I love.

I think I'm just using the default dark color theme. (dark+)

It's easy to use but it adds 55kB gzip to your project.

https://bundlephobia.com/result?p=@firebase/auth@0.16.4

A couple of comments on the Svelte code.

1) It doesn't makes much sense to use onMount() with listenForAuthChanges(). Just modify the currentUser writable whenever onAuthStateChanged() has an update. Now simply import and use $currentUser in your components.

2) You don't need to use currentUser.subscribe() from your .svelte files as you can use the reactive $: notation for this. You can, if it makes more sense to you, but I wouldn't say it's idiomatic.

For Firebase, will ES modules help with code splitting? The new Svelte kit framework is built by Vite (runs on ES build underneath).

I also trigger init code from my entry point (eg: main.js).

My only complaint is that the Typescript support isn't quite perfect yet, but it's already very functional.

* Last time I checked. I could be wrong now.

See my example here: https://codesandbox.io/s/clever-neumann-89tnx?file=/src/App....

See my example here at line 26: https://codesandbox.io/s/clever-neumann-89tnx?file=/src/App....

Typescript will inherit the type automatically.

Compilation actually has nothing to do with it. Svelte is fast because it doesn't do all the Virtual DOM stuff, and the DOM diffing. You could very well build Svelte as a library without the compiler, and it would be just as fast.

But the compiler helps a bit with the ergonomics - it's cleaner to do count+=1, rather than setState({count:count+1}).

Last I checked, svelte compiled different code paths for every single component.

This means that most DOM manipulations in real-world applications (not micro benchmarks using the same components repeatedly) won’t ever optimize in Svelte. Meanwhile, the vdom code runs constantly and is hand-tuned to help ensure deopts don’t happen. Likewise, potential optimizations to reuse old nodes and other “garbage” are much easier to implement with a unified DOM implementation. Finally, once you implement the vdom once, you don’t do it again. With Svelte, your code is recreated for every component. This may give smaller component in the short term, but there’s an inflection point (and it’s in the small-medium range) where svelte starts shipping more code for the same work.