Comment by pier25 | Hacker News Reader

Comment by pier25 | Hacker News Reader

State management is one of the reasons I moved away from React and Vue. You need a lot of machinery and plumbing to do something that should be really simple.

MobX is probably the best way I've found to manage reactive state with React, Inferno, etc, but still, it's a huge piece of of software for just this purpose.

I first moved to Mithril because it doesn't need reactivity. You solve the same problem than React/Vue et al in just 10kB. No need for an external router or a state management library. Your state is just vanilla JS. Mithril doesn't need to know when a particular piece of state has changed, it just tries to re-render everything and the vdom takes care of the rest. The performance is comparable to Vue 2 and React [1] but the DX is lightyears ahead. It's a sushi chef knife though, you really gotta know what you're doing[2].

Now I'm using Svelte because it's even better. It does have reactivity but the compiler just figures out the dependency graph so you don't need to ship a huge thing like MobX to do that at runtime. You also write a fraction of the code compared to all the other frameworks I've used which is Svelte's best feature. This compiler approach is a game changer IMO.

[1] https://krausest.github.io/js-framework-benchmark/current.ht...

[2] What I meant by this is that since your app is essentially vanilla JS you're on your own to architecture the thing. If you don't know what you're doing you will shoot yourself in the foot.

Man... I really disliked my experience with MobX. Idk, just too much proxy "magic" for me and I actually like how "hard" it is to update state in Redux. Changing state isn't something that should be taken lightly! I think a problem people run into (in general) is having too much "non-essential" state I their application; especially in the global state. If state can possibly be derived from other state, then it's not essential

That's almost exactly the path I've gone down, and svelte is something I've been seriously researching for a couple months now.

I have a nagging problem that keeps coming back to me though. The declarative state model is the holy grail for UI design, but if you try to mix in any form of imperative logic, it all falls apart. All of a sudden you need to understand and plug into poorly documented and opaque component lifecycle APIs in order to insert your imperative code and have it work correctly. And that really messes up the nice clean solution, making it look more like a chimera of two state models.

Some of that is fixed by libraries that create components native to your framework of choice, implementing the appropriate lifecycle hooks as necessary. But now you're relying on a library that adapts one library to another library, and now you've got a dependency sync problem on top of it all.

It wouldn't be such a problem if there weren't so many extremely useful libraries that depend on imperative code. Personally, I've run into massive problems trying to use D3, Leaflet, and Bootstrap, as well as a handful of others. I'm sure there are thousands more.

Not trying to take away from your point. When these declarative state models work well, it's a beautiful thing to behold. But there's always some point where the abstraction leaks.

https://svelte.dev/tutorial/onmount

https://reactjs.org/docs/state-and-lifecycle.html

https://blog.logrocket.com/introduction-to-vue-lifecycle-hoo...

https://mithril.js.org/lifecycle-methods.html

I wrote some about my experiences using Leaflet with Svelte: https://imfeld.dev/writing/leaflet_with_svelte

I found you have to do some extra work to keep track of things to convert from declarative style to Leaflet’s imperative style, but overall I actually had a pretty good experience with it. Feel free to ping me on Twitter (same username) if you have any questions.

>> If you don't know what you're doing you will shoot yourself in the foot.

Can confirm. My team of mostly fullstack devs that prefer backend ran into lots of issues with too much freedom in Mithril.

> should be really simple

Ummm... no, state management is pretty much the only hard problem in programming.

Can you support that? This doesn't seem like anything approaching the truth in the vast majority of web applications (where things like React are typically used). Mostly, in my experience, front end development is made unnecessarily complex by the developers involved.

"Just code up 6 these screens, we already have everything working in sketch - how long could it take"

Then you realize the "6 screens" actually turn in to a 50 step state machine that shares state between screens and changes screen logic conditionally on other screens, and the designer created sketches for the happy path.

And your "really simple straightforward state management" now has you going through 10 steps and 3 screens before you can arrive your state 11 which you are working on, you can't unit test the logic because your state is tightly coupled to UI and the HTTP stack, you can't reason about state updates because it's happening all over the place and is written by 3 other people concurrently, and coming to the project 6 months later makes you quit on the spot.

I've written plenty of WinForms to JQuery UI to know that "simple state management" is anything but.

Redux has initial overhead but down the line it pays for it self in these scenarios many times over. Going over requirements/flow with product owner and then writing tests for a reducer specifying the expected states is incredibly powerful in ironing out miscommunication in requirements and much faster than sending iterations of UI app to testing.

Like the parent said - the hairy part of the app ends up being dealing with the state machine - shuffling data over the HTTP is trivial, CSS/layout/animation are not that hard if you know what you're doing and don't need to support ancient browsers.

I don't mind complexity when it's necessary, but things like persistence and authentication are things that have long been table stakes for server-rendered apps.

I see state planning as one of the major barriers to designing a team workflow with idealized Microsoft Access.

This might be obnoxious, but could you share some insights on what svelte is doing correct in your opinion? I've never worked with it but am curious to what is the secret sauce that made you feel like it was the correct abstraction.

With React you can always use a very simple global store, and re-render the whole React tree when changing data in the store, or something more fine-grained like this hook https://gist.github.com/caub/1ab1190ae9e309318905be734364b65....

Completely agreed about Redux and other over-engineered state management

This is called “convention over configuration” and I don’t know where the front end software world went wrong in ignoring it. Ember.js is still a great example of a “batteries included” front end framework that makes all the decisions for you and prevents you from going off the rails. The downside is a high learning curve but once you’re experienced you can make reliable apps quickly

I definitely shot myself in the foot with mithril in terms of performance, and I somewhat assumed that I must've made some sort of architecture mistake somewhere along the way.

By the way did you ever look at http://meiosis.js.org for managing state?

Reply on news.ycombinator.com