Plug: I work on Million.js: <1kb virtual DOM - it's fast!
TL;DR
Virtual DOM needs to leverage the compiler, so that unnecessary di...
For further actions, you may consider blocking this person and/or reporting abuse
I don't understand. What is it that React or another virtual DOM library can do, that Svelte can't?
They both create and update DOM elements - both support loops, conditionals, components, state, and so on.
Something like Sinuous can even do precise updates without virtual DOM, like Svelte, without the compile step or static analysis, JSX being an optional convenience.
What is missing that makes virtual DOM still worthwhile?
Here's a clarification on that point: dev.to/aidenybai/comment/1gkdi
Sorry, that didn't help me either. Can you give a concrete case/scenario where this difference would come into play?
In terms of concrete examples WHILE being very different, other people on dev.to might have more experise to provide a better example. Examples I can think of right off the bat might be:
Why does React have FC while svelte has .svelte files? Why does React have JSX while you can write practically html/css/js in Svelte? Why does React have hooks while svelte you can just declare a function and attach it using a directive?
Generally, I think it's because React depends on vdom, where JSX was basically made for constructing vnodes, FC was made to make components from vnodes, and hooks based off of FC.
Svelte literally compiles down to near imperative operations, meaning that their API design can be much more radical in the sense that it's constrained to certain API decisions, but unrestricted from JavaScript (kind of), while React is constrained to the API of JavaScript, but at the same time is restricted to JavaScript.
I think that's a peculiar point of view. From my perspective, libraries like React or Sinuous aren't restricted to JavaScript, they're enabled by it - the fact that you get access to the entire language gives you degrees of freedom. Whereas something like Svelte or Vue apparently want to usurp or replace JavaScript rather than leverage it.
I mean, I get what you're saying - that e.g. Svelte isn't limited by JavaScript; they can change or enhance it as they see fit. There is more room for creativity. But there's also limitations to that approach - for example, React users naturally got access to Typescript, whereas Svelte users have to wait for the maintainers to make that possible. It kind of exists in it's own little bubble outside the JavaScript ecosystem proper. Whereas React and Sinuous exist within that sphere.
I've never been fond of tools that take away responsibilities from the language and platform and try to reinvent, subvert or displace them. I'm more impressed with projects that attempt to build within the constraints of the language and platform, than with projects that try build around it. Projects that build within are generally simpler, whereas projects that build around tend to be massively complex and have to reinvent the wheel. I like simple things.
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.
Good idea, tho I believe in the future more and more solutions will avoid virtual DOM 😉 Like Svelte, which is essentially a compiler 😉
Like Solid too
What about SolidJS?
What part of SolidJS?
SolidJS compiles down the way Svelte does and runs in the DOM. There is no virtual DOM. And it is extremely fast -- slower only than vanilla JS. And truly reactive, like RxJS. Is uses JSX as its templating language -- no VDOM needed. It can be used with Web Components. You can use native DOM events, etc.
What does Million.js give me that SolidJS lacks? What problem are you solving that SolidJS hasn't already solved? You might chat with @ryansolid about it if you're really interested in hearing an alternative view from the source.
Million.js isn't competing in the same field as SolidJS -- Million.js is a Virtual DOM engine, which libraries can be built off of (e.g. React), and SolidJS is a fully fledged library.
Million.js attempts to use techniques specified to reduce diffing (the main bottleneck of Virtual DOM) by assuming that the library developer will leverage the compiler to optimize.
I see. I guess if you want to stick with React or Vue or whatever (they have huge ecosystems), then it does make sense. I'm not sure I see -- if the SolidJS approach works -- what the advantage is that makes building yet more VDOM-based libraries/frameworks. But maybe it's just me.
Now I have a project I can study and tweak. Thanks for sharing!
Happy to help!
Love the project, still waiting for more posts about Million :D
can we use it with JSX
Yep! It's intended to be used with JSX
how to use it with webpack, and can I use it with next js
You probably have to use a bundler
i have created something like this in the past but its just the conversion from json to html, no editing or other features
Nice!
What about no vdom and no compiler? 🤯
Virtual DOM in only runtime suffers from the pitfalls specified here: dev.to/aidenybai/million-js-the-fu....