DEV Community

Discussion on: Million.js - The Future of Virtual DOM

aidenybai profile image
Aiden Bai Author

I get where you're coming from, and that's a really good point. I also add that a library can be both enabled and restricted by a language.

I really like your perspective! I have a question though: From my personal experience, libraries like React do simple things really well, but as more and more complexity is introduced in your application, it becomes more and more unweildy. You could argue that increased abstraction could simplify complex use cases but make simple use cases very difficult. Sort of like a balancing act.

Thread Thread
mindplay profile image
Rasmus Schultz

You could argue that increased abstraction could simplify complex use cases but make simple use cases very difficult.

That sounds right (and I promise I'm not just trying to be Mr. Opposite here) but again, my experience is the opposite: more abstraction tends to favor simple use-cases - the ones the author was able to conceive of.

Big libraries tend to make easy things easier, which I find unnecessary and restrictive. Complex abstractions tend to be tailored towards a very specific "happy path" - whatever the author thought was "right", or whatever the pattern he got tired of repeating. It tends to get in the way of complex use-cases, if they don't happen to fit well with the abstraction.

On the other hand, they can of course speed the development of things that are a good fit - but that's what I would call "large" or "repetitive" use-cases, rather than really "complex", by which I would mean something that isn't your average everyday problem.

Where I grow tired of the big, complex libraries, is that, if a project is large or runs long enough, you will run into one of these cases that requires you to break outside the "happy path". At that point, you're going to "pay back" some of what you saved by making easy things easier.

So I'd just rather not. I like small, simple things that focus on the hard problems and don't try to make things easier if they're already easy. In many cases, the big abstractions are focused on reducing lines of code or making things more "elegant", which usually also means taking away choices and options, increasing (but hiding) overall complexity, and making things less transparent.

To provide you with a real world example, consider state management in React. When you first learn about it, it's just setState or useState, which seems really simple, until you realize it only really works well for control state, and not so well for application state. So you end up with props, component state, and some form of application state, maybe contexts, some patterns, or even more abstraction: a third-party library. Complexity spreads.

Now in contrast, consider the state management mechanism in Sinuous: observables, which work exactly the same everywhere. If you want component state, you create observables in your component - if you want application state, you create them somewhere outside your components. There's only one way to create and use state. You have to learn one pattern and use it correctly, and it's maybe a bit more verbose than some of your favorite state management approaches in React, but then that's it. You're done. It generalizes really well. You're not going to learn bit by bit how to solve this or that state problem, and you're not going to evaluate a bevy of state management libraries, or spend months becoming an expert at various state management patterns that might be better or worse for this or that.

Don't get me wrong, I'm not promoting Sinuous (which, full disclosure, I really do enjoy) and it might have drawbacks in other areas where React or Vue or whatever does better - but in this one area, it's just a beautiful example of "right amount of abstraction", which, in my book, tends to be "as little and as general as necessary".

Do you know Rich Hickey? If you haven't seen "Simple made Easy", go watch that. In my opinion, it's the most important video on software development there is. Completely changed my perspective, in ways that have made me much more productive, successful, and happy with software development. In many ways, successful software development is less about picking the right tools, and more about avoiding complexity - choosing simplicity. 😄♥️

Thread Thread
aidenybai profile image
Aiden Bai Author

Wow, thanks so much for this. Sinuous looks really cool! It looks like a really great hybrid between the Vue composition API (which I think was derived from the concept of observables) and lit-html, and I can see why you would think it's great. I've been looking around for a daily-driver library for a while, and this seems like it is a really good fit!

Side note: I was looking through the readme and I'm not sure if this was an inconsistency or a progression of timeline I missed:

Tagged templates transform the HTML to h calls at runtime w/ the html`` tag or, at build time with sinuous/babel-plugin-htm.

The html`` tag returns a native Node instance and the components are nothing more than simple function calls in the view.

I'll be sure to watch that video. Thanks so much for your time, this has made me realize I still have so much to learn and experience