7 ms·

The over-engineering in React land is really getting long in the tooth for me, and I think will be its downfall. This took under 10 minutes, including creating

The over-engineering in React land is really getting long in the tooth for me, and I think will be its downfall. This took under 10 minutes, including creating the modal, and I barely had to think: https://svelte.dev/repl/0299705b5e9e46be9e87fe4fef035bec?version=3.32.1 https://svelte.dev/repl/0299705b5e9e46be9e87fe4fef035bec?ver... No 'finicky useEffect', no race conditions, easily packaged as a component, no dependencies and maybe a couple KB in size. Easy to understand for everyone.

purplecats 6y ago
agreed. some workplaces use it as a competitive tool. build an overengineered product to make it look like you're contributing more value than your coworker etc.
mssundaram 6y ago
Right, but your example has nothing to do with a state machine. Nearly the same code could be written in React. I don't share the author's same view of "finicky useEffect" etc. Using a state machine for a modal is pretty overengineered, but I don't think that's reason to switch away from React altogether.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
dceddia 6y ago
OP here! Thanks for putting together the Svelte demo. I'm a big fan of Svelte too, and I concur... everything I've tried to build with it so far has felt simple and easy compared to React. FWIW this post wasn't written around the idea that modals in React are so hard they require a state machine to get them right, more that I wanted a minimal-ish example to show off how to build something with a state machine, and ideally something real-world-ish, but that wouldn't require special domain knowledge. It's always a tough balance to strike when choosing examples... too simple and they come off as overengineering, too complex and you lose the forest for the trees. Thanks for checking it out, at any rate!
- steve_adams_86 6y ago
  I think some people just don’t get the point of state machines, whether they understand them or not. Much like people who think static typing is just cognitive overhead, or things like exhaustive pattern matching just get in the way. To me these things are indispensable tools for keeping users happy by preventing me from breaking even more shit.
onion2k 6y ago
Is it common practice to put main thread blocking async await Fetch requests in UI components in Svelte? That's a very bad idea. The user can't so anything else in the app until that request completes. If they're on a slow mobile connection the UX is going to be pretty horrible, especially as the component doesn't give the user any feedback that something is happening or any option to cancel.
- PaulBGD_ 6y ago
  To start off, putting an async function there just means the promise will be executed somewhere, not that the UI thread will stop. Svelte does not wait for promises in events on elements. As well in a full application, Svelte actually has an {#await} syntax that allows you to wait on a promise. I personally would then have a variable representing the currently waiting promise, then use await to show the status/error of the promise.
tunesmith 6y ago
The article wasn't "To handle simple modals, try a state machine." It was "To handle things with a lot of complicated changing state, try a state machine, and here's a simple example." When you have state explosion, it gets complicated really fast as they get bigger. State machines help you manage that by telling you when you've missed something. They scale in a way that a bunch of hooks doesn't.
- rualca 6y ago
  > It was "To handle things with a lot of complicated changing state, try a state machine, and here's a simple example." Right you are. We should also acknowledge that state machines are a fundamental tool of GUI development. Either you use them, or you use them even though you're oblivious to them. There is no way around them. Some GUI frameworks like Qt even develop and support their own state machine framework to drive their UIs. https://doc.qt.io/qt-5/statemachine-api.html https://doc.qt.io/qt-5/statemachine-api.html I mean, what do UI design people think a UI flow diagram is supposed to be? Of all things to complain about React, state machines aren't one of them.
- torginus 6y ago
  Except state machines aren't that good at handling complexity. This generally boils down to: - The number of possible transitions scales quadratically with the number of nodes - They're not very composable Plus, there are many things that compile down to state machines, such as Regex or async/await, because they're a pain to write directly.
  - davidkpiano 6y ago
    That's why statecharts exist.
  - rkangel 6y ago
    State machines do compose, but usually in a message passing environment. That might be a message passing programming environment like Erlang, or it might be a message passing system such as a protocol stack. Every layer in your stack be it bluetooth, IP, or whatever is a state machine communicating with messages to the layers above and below (whether or not it is written using an explicit state machine, most protocol layers implicitly are a state machine). The number of possible transitions thing isn't really an issue. For embedded applications I usually use a (home grown) Python tool that generates C code from a CSV file. The CSV file is 4 columns - start state, event, end state, action function (optional). That list of transitions can get to hundreds of lines, but grouped by starting state it is fairly easy to manage and understand - e.g. you're looking at the list of things that can happen when the device is 'CHARGING' (such as charger disconnect, power on).
karmasimida 6y ago
State Machine is just state machine. I don't understand the immediate association you implied with over-engineering. It is essential for developing complex component, where to accomplish a single transaction requires a series of actions that is inseparable from each other, e.g. creating a viewable configuration object that has internal dependency among itself, or complex annotation tools. To keep you sanity to handle the dependencies, and failure case, you need a state machine, period, or you invented your own without knowing, or your code is just too broken to be fixed.
- josephg 6y ago
  Sure; but with redux the state machine is site-wide, and needs to be modelled with actions and reducers. With svelte, a state machine is just a variable or two, that you can just assign to. Rendering (and programmatic hooks) react to those variables changing without any effort on your part. And those variables can be local or shared between components, just like any other piece of code. It’s still, obviously a state machine - but because you can implement it with half as much code, you’ll have half as many bugs and you’ll finish faster. The outcome is the same, but the expression is better in my opinion. (There is something to be said for having all your state in one place - but you can just organise your svelte code like that if you really want to.)
  - richeyryan 6y ago
    The transitions between states in the Svelte example are also completely uncontrolled and there is no guaranteed flow from state A => B => C. That is completely fine in many cases, most cases I would say. The problem is when you encounter a scenario where predetermined flow and guaranteed state transitions matter and you're trying to cobble it together. Robot and XState aren't React libraries, they're just Javascript libraries. Not every solution needs them but to dismiss the idea as overengineering or React specific because you can assign to variables in Svelte is missing the point.
    - josephg 6y ago
      Sure; but you can handle that as we do in other programs: if it makes sense to do so, make a single method responsible for modifying a state variable and call that instead of assigning directly. And that can manage side effects. Alternately, trigger other changes off the state variable changing using svelte’s reactive code blocks. This style of programming can scale up and down in complexity like any other code you write, and you can scope it and refactor it along with everything else.
29athrowaway 6y ago
When I worked integrating payment gateways I learned to love state machines. They make code easier to maintain. State machines helped me get rid of the chainsaw juggling with 10 different boolean flags that was responsible for countless bugs and bad customer experience. It's not over-engineering, it's about keeping things predictable and under control.
notretarded 6y ago
This kinda sucks, while functionally correct it really violates a lot of good programming practices. I mean for starters you're mixing application logic with presentation logic, which really sucks. Now try using your same methods to create a flow that involves 5, 10, 50 states. Yeah, not so nice is it.
molszanski 6y ago
We can over-engineer "hello world" in any framework or language :) I think React has a bad vibe because articles promote adding redux with reselect or other complex systems to login forms or counters, thus normalising overkill. Also, Svelte is amazing. It provides observables and computed properties which are very productive tools for state management! If you want them in React, `npm install mobx`.
- prionassembly 6y ago
  Related: https://willamette.edu/~fruehr/haskell/evolution.html https://willamette.edu/~fruehr/haskell/evolution.html
Aeolun 6y ago
What in hells name is an #await doing in the HTML render function?
- dceddia 6y ago
  The #await is a Svelte feature that lets you handle promises, and show different content when the promise is unresolved/loading, resolved, or rejected. Check out the demo in the docs: https://svelte.dev/tutorial/await-blocks https://svelte.dev/tutorial/await-blocks
monadic3 6y ago
You know the constant stream of hot takes from this forum gets really, really, really old after a while.
duxup 6y ago
React really is best used for larger applications. If we're going the very simple here, then you could just use plain old JavaScript...

purplecats 6y ago

agreed. some workplaces use it as a competitive tool. build an overengineered product to make it look like you're contributing more value than your coworker etc.

mssundaram 6y ago

Right, but your example has nothing to do with a state machine. Nearly the same code could be written in React. I don't share the author's same view of "finicky useEffect" etc. Using a state machine for a modal is pretty overengineered, but I don't think that's reason to switch away from React altogether.

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

dceddia 6y ago

OP here! Thanks for putting together the Svelte demo. I'm a big fan of Svelte too, and I concur... everything I've tried to build with it so far has felt simple and easy compared to React. FWIW this post wasn't written around the idea that modals in React are so hard they require a state machine to get them right, more that I wanted a minimal-ish example to show off how to build something with a state machine, and ideally something real-world-ish, but that wouldn't require special domain knowledge. It's always a tough balance to strike when choosing examples... too simple and they come off as overengineering, too complex and you lose the forest for the trees. Thanks for checking it out, at any rate!

steve_adams_86 6y ago
I think some people just don’t get the point of state machines, whether they understand them or not. Much like people who think static typing is just cognitive overhead, or things like exhaustive pattern matching just get in the way. To me these things are indispensable tools for keeping users happy by preventing me from breaking even more shit.

onion2k 6y ago

Is it common practice to put main thread blocking async await Fetch requests in UI components in Svelte? That's a very bad idea. The user can't so anything else in the app until that request completes. If they're on a slow mobile connection the UX is going to be pretty horrible, especially as the component doesn't give the user any feedback that something is happening or any option to cancel.

PaulBGD_ 6y ago
To start off, putting an async function there just means the promise will be executed somewhere, not that the UI thread will stop. Svelte does not wait for promises in events on elements. As well in a full application, Svelte actually has an {#await} syntax that allows you to wait on a promise. I personally would then have a variable representing the currently waiting promise, then use await to show the status/error of the promise.

tunesmith 6y ago

The article wasn't "To handle simple modals, try a state machine." It was "To handle things with a lot of complicated changing state, try a state machine, and here's a simple example." When you have state explosion, it gets complicated really fast as they get bigger. State machines help you manage that by telling you when you've missed something. They scale in a way that a bunch of hooks doesn't.

rualca 6y ago
> It was "To handle things with a lot of complicated changing state, try a state machine, and here's a simple example." Right you are. We should also acknowledge that state machines are a fundamental tool of GUI development. Either you use them, or you use them even though you're oblivious to them. There is no way around them. Some GUI frameworks like Qt even develop and support their own state machine framework to drive their UIs. https://doc.qt.io/qt-5/statemachine-api.html https://doc.qt.io/qt-5/statemachine-api.html I mean, what do UI design people think a UI flow diagram is supposed to be? Of all things to complain about React, state machines aren't one of them.
torginus 6y ago
Except state machines aren't that good at handling complexity. This generally boils down to: - The number of possible transitions scales quadratically with the number of nodes - They're not very composable Plus, there are many things that compile down to state machines, such as Regex or async/await, because they're a pain to write directly.
- davidkpiano 6y ago
  That's why statecharts exist.
- rkangel 6y ago
  State machines do compose, but usually in a message passing environment. That might be a message passing programming environment like Erlang, or it might be a message passing system such as a protocol stack. Every layer in your stack be it bluetooth, IP, or whatever is a state machine communicating with messages to the layers above and below (whether or not it is written using an explicit state machine, most protocol layers implicitly are a state machine). The number of possible transitions thing isn't really an issue. For embedded applications I usually use a (home grown) Python tool that generates C code from a CSV file. The CSV file is 4 columns - start state, event, end state, action function (optional). That list of transitions can get to hundreds of lines, but grouped by starting state it is fairly easy to manage and understand - e.g. you're looking at the list of things that can happen when the device is 'CHARGING' (such as charger disconnect, power on).

karmasimida 6y ago

State Machine is just state machine. I don't understand the immediate association you implied with over-engineering. It is essential for developing complex component, where to accomplish a single transaction requires a series of actions that is inseparable from each other, e.g. creating a viewable configuration object that has internal dependency among itself, or complex annotation tools. To keep you sanity to handle the dependencies, and failure case, you need a state machine, period, or you invented your own without knowing, or your code is just too broken to be fixed.

josephg 6y ago
Sure; but with redux the state machine is site-wide, and needs to be modelled with actions and reducers. With svelte, a state machine is just a variable or two, that you can just assign to. Rendering (and programmatic hooks) react to those variables changing without any effort on your part. And those variables can be local or shared between components, just like any other piece of code. It’s still, obviously a state machine - but because you can implement it with half as much code, you’ll have half as many bugs and you’ll finish faster. The outcome is the same, but the expression is better in my opinion. (There is something to be said for having all your state in one place - but you can just organise your svelte code like that if you really want to.)
- richeyryan 6y ago
  The transitions between states in the Svelte example are also completely uncontrolled and there is no guaranteed flow from state A => B => C. That is completely fine in many cases, most cases I would say. The problem is when you encounter a scenario where predetermined flow and guaranteed state transitions matter and you're trying to cobble it together. Robot and XState aren't React libraries, they're just Javascript libraries. Not every solution needs them but to dismiss the idea as overengineering or React specific because you can assign to variables in Svelte is missing the point.
  - josephg 6y ago
    Sure; but you can handle that as we do in other programs: if it makes sense to do so, make a single method responsible for modifying a state variable and call that instead of assigning directly. And that can manage side effects. Alternately, trigger other changes off the state variable changing using svelte’s reactive code blocks. This style of programming can scale up and down in complexity like any other code you write, and you can scope it and refactor it along with everything else.

29athrowaway 6y ago

When I worked integrating payment gateways I learned to love state machines. They make code easier to maintain. State machines helped me get rid of the chainsaw juggling with 10 different boolean flags that was responsible for countless bugs and bad customer experience. It's not over-engineering, it's about keeping things predictable and under control.

notretarded 6y ago

This kinda sucks, while functionally correct it really violates a lot of good programming practices. I mean for starters you're mixing application logic with presentation logic, which really sucks. Now try using your same methods to create a flow that involves 5, 10, 50 states. Yeah, not so nice is it.

molszanski 6y ago

We can over-engineer "hello world" in any framework or language :) I think React has a bad vibe because articles promote adding redux with reselect or other complex systems to login forms or counters, thus normalising overkill. Also, Svelte is amazing. It provides observables and computed properties which are very productive tools for state management! If you want them in React, `npm install mobx`.

prionassembly 6y ago
Related: https://willamette.edu/~fruehr/haskell/evolution.html https://willamette.edu/~fruehr/haskell/evolution.html

Aeolun 6y ago

What in hells name is an #await doing in the HTML render function?

dceddia 6y ago
The #await is a Svelte feature that lets you handle promises, and show different content when the promise is unresolved/loading, resolved, or rejected. Check out the demo in the docs: https://svelte.dev/tutorial/await-blocks https://svelte.dev/tutorial/await-blocks

monadic3 6y ago

You know the constant stream of hot takes from this forum gets really, really, really old after a while.

duxup 6y ago

React really is best used for larger applications. If we're going the very simple here, then you could just use plain old JavaScript...