16 ms·
Million: less than 1kb virtual DOM that is fast
- aordano 4y agoThis reminds me so much of MithrilJS, and i also remember how terribly unergonomic it was, a terrible DX. The Vite JSX plugin is nice tho, I can see myself using this for something, but i will probably get tired of the ergonomics once i hit some complex component. I am currently in early stages of writing a lightweight reactive framework more of the likes of Alpine and there are some things in this source that can prove fruitful. The rendering process is one of the most interesting things here imo.
- echelon 4y agoFirst time I've seen "DX". Developer experience, I assume from context? That's an awesome term and I'm going to steal it.
- aordano 4y agoYes, developer experience. I thought it was a common term, maybe not so much. And I agree, it's a great term :)
- 8n4vidtmkvmk 4y agoya,. developer experience. thought it was kind of a lame term and first but now i kinda love it. dx all the way. aint using no framework i have to fight with even if it produces optimal ux. sorry users, i love me more than you
- hinkley 4y agoCode that doesn’t work for the developers eventually won’t work for anyone else, either.
- franciscop 4y agoI just used "dev experience" yesterday when I was going to use "DX" at first, just in case someone didn't know the term. I thought I was being silly and that by now everyone would know the term, but apparently I did the right thing to be a bit over paranoid here! Thanks for confirming: https://twitter.com/FPresencia/status/1553263166796308481 https://twitter.com/FPresencia/status/1553263166796308481
- LAC-Tech 4y agoIf this is the first time you've seen DX I've got two words for ya
- echelon 4y agoI've heard "developer experience" a million times. My last company had a few teams devoted to it, and the existential need is palpable. I've just never seen it in abbreviated form, and that's kind of shocking to me because it's so obvious.
- aidenyb 4y agoThanks for the feedback, Million has a React compat layer https://millionjs.org/docs/start-here https://millionjs.org/docs/start-here too
- toastercat 4y agoThis looks nothing like Mithril.js outside of the superficial comparison of the hyperscript helper using `m` instead of `h`, but almost every popular reactive front-end lib has a hyperscript-like API.
- divbzero 4y agoCoincidentally, the same command can work for both Million [1] and Mithril [2]: m('div', {id: 'box'}, ['hello']) [1]: https://millionjs.org/docs/api/basics/m https://millionjs.org/docs/api/basics/m [2]: https://mithril.js.org/hyperscript.html https://mithril.js.org/hyperscript.html
- pier25 4y agoDid you try Mithril with JSX? When I used it I thought the DX was great. Router and Http client included. No need for state management libs.
- wruza 4y agoI actually like hyperscript DX more than JSX/HTML. What I’ve found out though is that most “prettifiers” and formatters in editors (unlike vim) suck so much at hierarchical calls formatting.
- LAC-Tech 4y agoI really don't find not having JSX a big deal. If left to my own devices I won't even code preact/react with JSX so I can avoid a transpile.
- kylecordes 4y agoLooks like a VDOM, but is faster like a compiler; I wonder how it compares to the (well established, excellent) SolidJS? BTW... docs point out it is written by a high school student. A very, very impressive high school student!
- game-of-throws 4y agoVDOMs aren't inherently slow... Inferno uses a VDOM and scores within a few % of SolidJS on js-framework-benchmark. (Never used it myself) https://www.infernojs.org/ https://www.infernojs.org/
- mhoad 4y agoVDOM is an outdated 2012 concept when running in a 2022 browser though. Completely unnecessary and just doubles the data structures and fights against the browser itself. None of the fastest modern frameworks use it as far as I know (solid, lit, fast, svelte and stencil)
- onion2k 4y agoVDOM is an outdated 2012 concept when running in a 2022 browser though. Is every user running a 2022 browser?
- mhoad 4y agoI mean generally, yes? Evergreen browsers have been the standard for many years now in all major browsers. The worst offender I guess is Safari which has historically tied updates to a few times a year rather than much shorter cycles used in Edge, Firefox and Chrome. Whatever delays there may be in those update cycles I’m confident that you shouldn’t need to be catering to 2012 browsers. VDOM just isn’t necessary as a performance hack and hasn’t been for many years at this point.
- dodyg 4y agoVue still uses VDOM https://vuejs.org/guide/extras/rendering-mechanism.html#render-pipeline https://vuejs.org/guide/extras/rendering-mechanism.html#rend...
- nhinck2 4y agoWhy is my phone scrolling at 10fps on this page? Not exactly a great first experience.
- deleted 4y ago[deleted]
- Crystalin 4y agoI don't want to sound rude... but ...maybe it is your phone ! :p
- ImPostingOnHN 4y agoeasy way to tell: does it happen with other Javascript frameworks?
- realPubkey 4y agoSame for me on mobile chrome
- ac130kz 4y agoI also have poor scrolling experience, but I believe it is due to some sort of a "smooth" (sic) scrolling library
- smartbit 4y agoBelow the heading, I see a mostly black page with a few icons. It does scroll fast though :)
- realitysballs 4y agoThe video really hypes me up despite lacking any technical depth
- collegeburner 4y agofr its slick af and gives off mad apple commercial vibes
- richardfey 4y agoI wonder how it compares to http://vanilla-js.com/ http://vanilla-js.com/
- Blackthorn 4y agoThis was downvoted but as someone not too familiar with modern frontend design I'm actually wondering about the comparison myself. When would you use this?
- deleted 4y ago[deleted]
- enjoyyourlife 4y agoIt's a joke website mocking the proliferation of JavaScript frameworks
- Blackthorn 4y agoI know what the vanilla-js website is. I'm wondering what the virtual dom library actually does for you.
- richardfey 4y agoI think it's more subtle than that: it's mocking specifically the small size boast of JavaScript frameworks.
- bob1029 4y agoWe use Vanilla JS exclusively these days. It is staggering to me the quantity of developers who are still made uncomfortable by the notion that you can construct a high-quality, modern web experience without pulling down a single 3rd party javascript or css dependency. I really hope the pendulum starts to swing back the other way. It is so fast & easy now. MDN makes life a breeze. In 2022, there really isn't an excuse to not use direct DOM manipulation and bare-ass JS, other than pedantic ideological arguments such as "why is my hammer this shitty color?" and "My monster.com filter can't find 'vanilla js' skilled employees". As noted by other posters, VDOM is essentially just overhead. It is both faster & easier to grab that element by its id and change it directly. Playing around with intermediate UI representations, 3rd party frameworks and splitting state between client & server is where 99% of your hell comes from on web development. When you understand 100% of your javascript, setting breakpoints and tracing things in devtools has a lot more power. Hiding from the realities of the open web is only going to cause a prolonged suffering for the junior web developer. Frameworks will come and go. document.getElementById() will be here until the end of time.
- quelltext 4y agoSo, is this a replacement backend for JSX? Or what is it actually? Is ot tied into React (is React's virtual DOM implementation pluggable by design?)? I don't quite get how a framework can be described as "it's a virtual DOM that's fast". I kind of get what they mean, but is there no better term? E.g. "virtual DOM engine", "virtual DOM runtime", "virtual DOM renderer", maybe?
- eyelidlessness 4y agoIt’s not tied to React at all. JSX is (intentionally) designed to have unspecified semantics, and be used as a compiler mechanism to implement arbitrary semantics. Most usage compiles to something resembling a function call or a memo of same. AFAIK all VDOMs use that approach. Some non-VDOM JSX libraries like Solid use it as a static analysis target for optimal output. Some libraries including React use it to target non-browser render targets. Yes, React is designed to render to arbitrary views or even non-views. It’s used for rendering WebGL, native mobile apps, TV interfaces, CLIs, PDFs and probably a lot else. As far as what’s described here, “that’s fast” is meant as “which is fast”, it’s distinguishing itself from slower VDOMs (such as React, which is exceedingly well engineered but seldom wins performance contests in recent years).
- leeoniya 4y agoas always, take any performance claims with a healthy dose of skepticism; still waiting on https://github.com/aidenybai/million/issues/37 https://github.com/aidenybai/million/issues/37 it's pretty hard to break into the sub-1.15 factor club without code smell. in fact, mikado is suspiciously fast for not having any caveats listed; something about its impl might be unusually bench-specific. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
- aidenyb 4y agoAuthor of Million here -- Don't trust my benchmarks at face value! Always run your own benchmarks
- leeoniya 4y agoyou're definitely the most qualified to do a js-framework-benchmark implementation. it's pretty odd that this hasnt been done given how much the marketing leans on performance claims. "do your own benchmarks" is too handwavy a dismissal, imo. btw, my own framework is in this list, and has been for a long time, to keep me honest.
- aidenyb 4y agoThat's a fair point, seems like the current issue owner is inactive on the task, I'll go in myself and start work on a benchmark. Million started out as only a virtual dom (and therefore was never added to the js-framework-benchmark). Only recent was the React compat added, which is when we were comfortable to start working on benches. My intention wasn't to dismiss your point at all btw. My intention was if there wasn't any 3rd party benchmark for a library (like js-framework-benchmark), you shouldn't take claims at face value unless you've done due diligence. It's great to hear that you're keeping yourself accountable, hopefully Million will also sometime soon :)
- leeoniya 4y agogreat, i hope it does well :)
- nprateem 4y agoBut is it modern?
- lgas 4y agoForgot to edit the Nextra meta tags.
- brundolf 4y agoBit of feedback: marketing it as just "a virtual DOM" and not "a framework" or "a React alternative" made me think it would just be a VDOM, and not include things like state/hooks. Instead, it looks more like a Preact type thing: a framework that's mostly API-compatible with React, aiming to make different tradeoffs around bundle size, performance, etc. Is that accurate?
- aidenyb 4y agoMillion was originally created as a Virtual DOM -- and still ships as a Virtual DOM. More recently, Million added an optional react compat library in order to make it easier for users to learn about Million. I'm open to different ways to market Million if there is a specific tagline you have in mind
- brundolf 4y agoTo my mind React is a couple different things: - A VDOM (a library that lets you construct a virtual-dom, and then reconciles it with the previous one, and patches the real DOM accordingly) - A state management/reactivity system (state hooks, effects, etc, and really also class components and their state/lifecycle) - A framework which ties the above two together into a cohesive package for building web UIs For me, the term "VDOM" only refers to that first point; i.e. you could combine a VDOM library with some other stuff to make a React-like framework That could just be me, though
- toomim 4y agoAh, this is important new information for me! I just visited the website, and looked for a virtual DOM API that I can use inside of my library. Unfortunately, when I read the actual "getting started", it showed me how to import react libraries for hooks, and use JSX, and so I concluded that: (a) This is actually a React replacement, like Preact, not just a virtual dom. (b) The homepage marketing is misleading! The project lost a bit of integrity for me at that point, and I started trusting it less. If the homepage marketing is declaring it to be a virtual dom, then I want to see how to use the virtual dom API so that I can verify what it is! If it then on top of that has a React Compatibility layer, that's just awesome and makes me really excited to understand it, and I'll probably want to look at that layer so that I can see what React is beyond a virtual dom. Anyway, do you have a pointer to how to use it as a plain old virtual dom? I happen to be in the market for one, right now!
- toxicFork 4y agoWould this be able to support projects like react three fiber?
- russellbeattie 4y agoBefore anyone gets too harsh or critical, check out the about/research page. The author is in high school. I feel old.
- mr90210 4y agoLOL.
- seejayseesjays 4y agoIf the benchmarks hold true, (and I don't doubt they will,) this is incredibly impressive! Neat research!
- IIsi50MHz 4y agoWondering how in compares with Imba.io … which is the first way I heard of virtual DOM. I vaguely remember watching Imba demo videos and being astonished to discover that, despite the playback controls, they were _not_ videos but rather fully interactive and you could edit them on the fly. Imba seemed amazingly performant at the time, but then I never had a project the could really use it (except one the sunsetted before I could make major alterations to it).
- janci 4y agoDo we need VDOM for fast rendering? Would it be possible to make expressions that are re-evaluated only when their inputs change and bind them directly to real DOM? I mean using immutable values and pure functions gives you the first (already used with react) and in the end VDOM mutates the DOM, so why not skip the VDOM altogether?
- janci 4y agoTo better explain myself: VDOM takes two versions of the element tree, makes a diff and patches the DOM accordingly. Why not take two versions of the state tree, diff that and patch DOM directly? What benefit the VDOM brings?
- ivanvanderbyl 4y agoWhat you are describing sounds closer to how Svelte works.
- eldenring 4y agowriting to the DOM is slow, you use VDOM to batch updates and other optimizations
- megous 4y agoNo it's not. It's pretty close to browser's native HTML parsing speed. And VDOM just writes to the DOM in addition to doing a lot of other throwaway work and allocations. Reading from DOM may be slow, if you read one of the properties that would trigger layout/style calculactions.
- franciscop 4y agoWhat do you mean by "state tree" here? And how do you go from the state tree diff to the required dom diff?
- speedgoose 4y agoI remember that historically DOM used to be very slow on some browsers and virtual DOM was a huge performance boost. You could compute very quickly the difference in JavaScript and minimise the calls to the slow DOM browser API. Now that Internet Explorer is really deprecated and DOM are fast enough in every browser, VDOM is not necessary.
- _the_inflator 4y agoThe virtual DOM idea is nowadays a myth. It stems from the time when Facebook was still a Web App and was running on IE8 and IE6. It was a decent idea to optimize for these browsers and FB's nature of featuring hundreds of comments etc. that could be updated somewhere outside your view port and cascade nevertheless into repaints and reflows. Remember the FB feed? I also worked on virtual DOM optimizations back then for these IEs, but have long since abandoned optimizations. I take it with Svelte: https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead Also Google sheets results show overall, that DOM is faster than any virtual DOM, so why produce overhead? https://millionjs.org/benchmarks https://millionjs.org/benchmarks Virtual DOMs are a thing that people long time ago forgot why and for what technology it was invented. Then came Google Chrome and their optimizations. For benchmarks, I think this is still the best around: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
- toxicFork 4y agoIt feels nicer to use functional components with declarative state than set dom attributes imperatively.
- jsf01 4y agoPlenty of libraries have functional components and a react-like experience without the need for a virtual dom. Lack of vdom does not necessitate imperative dom usage.
- hinkley 4y agoIt’s the same observation TDD makes. If you can figure out what a sane interface looks like, it doesn’t matter how it’s implemented underneath. You might even want to change your mind for performance or new feature purposes.
- LAC-Tech 4y agolit-html is similar to the render method of a react component, uses a declarative html'esque syntax, and doesn't use a VDOM AFAIK. No one is saying update DOM elements manually. They're saying there's better strategies for view libs than VDOM.
- pkrumins 4y agoWhy use virtual dom when you can just use regular dom?
- zmxz 4y agoBecause it adds to mystique and yields a huge amount of imaginary internet points, which are main currency when it comes to trying to impress someone with your vocabulary.
- pkrumins 4y agoRight on!
- amoerie 4y agoCan you write declarative reactive components with regular dom? If that wasn't an issue, why wasn't React immediately designed that way?
- pkrumins 4y agoWhat is React?
- 5350-uiop-1130 4y agoI keep seeing this expression "batteries-included" on every javascript library and framework, what does it mean?
- Banana699 4y agoIt's a subjective context-dependent phrase used by someone to say that you don't need extra things with the tool, e.g. "Python is batteries-included, it can load json, send http and talk to an sql DB without any additional packages"
- onion2k 4y agoVery few apps that use React require sustained, fast DOM changes for a long period. Most web apps sit idle 99% of the time, and then need to manipulate a handful of DOM elements based on a user action - the user clicks a button or types in a box and a few things around the page update. That means the framework needs to make 4 or 5 DOM changes in one frame (about 10ms including the browser's overhead to render things.) The fact that this is slow in some web apps is beyond disappointing. They're doing practically nothing and they still feel terrible. This is where I think React is getting things right. The work that's been done on React 18 attempts to work out what events are most important, and schedules the DOM changes from those interactions ahead of changes from other events. It batches the changes over a number of frames if there's a lot of them. This means that a UI made with React will probably be slower than other frameworks, but it'll feel faster. The changes that result from your interaction happen first. That's what users want. Ultimately every framework has an upper bound for performance, and if you're not hitting it then the framework speed doesn't really matter. If you are hitting it though, then React's approach is better because it optimizes for the bit the user cares about. The fact that Solid, Svelte, etc are technically better, and therefore faster, means there's lots of additional headroom for using that speed, but once you actually cross the threshold of what they can do things will start to feel slow very quickly. And this is where that matters - many web developers just aren't great at writing code, so if the framework can scale a 'fix' for what they build that will result in a better user experience than simply giving the developer more speed. A faster VDOM is a good thing, and no VDOM at all is an even better thing, but ultimately you could make the fastest framework ever and some developers will still write things in ways that feel slow. The right approach for fixing UI on the web is to make a framework that focuses on doing the important DOM changes first, even if it does them a bit slower than the other approaches.
- thrownwayne 4y agoJust maybe change your logo icon. The imagery that jumps to mind is all T&A and once you've seen it as a mushroom-tip... it's impressive how many NSFW boundaries it manages to blend together.
- mavu 4y ago> Million ships <1kb brotli bundles after tree shaking and minification. Get fast bundle load times! The whole Javascript ecosystem needs to be burned to the ground and never spoken of ever again.
- rrishi 4y agoWhy did that quote cause this reaction from you ? Also, that reaction is so widespread at this point, it's become boring to hear it. It's a lot more interesting figuring out how the JS ecosystem has been resilient and has not gone down the drain (unlike a lot more "critically" acclaimed languages like Lisp)
- anonymoushn 4y agoMight it have something to do with being forced to use it?
- rrishi 4y agoUsing JS is not enforced on anyone. Several (successful) websites are powered by alternatives to JS. Infact, HN itself does not use JS. You could argue there is a lot more economic incentive to use JS to to the sheer number of jobs, but no one is being forced.
- peoplefromibiza 4y agowe'll never know what could have happened to JavaScript if browsers supported more than a language (Lisp, for example, Brendan Eich plan was to write Scheme for the browser but then Java came out, Netscape had a deal with Sun already and so JavaScript was born) When things were not settled like they are today, Microsoft IE supported multiple languages and many people were using VBscript because it made more sense than JavaScript at the time. Also, many new languages that transpile to JavaScript exist, because, well, for many people JS simply sucks. I hear TypeScript is pretty big in that space. Who knows if JS will survive WASM that promise to free programmers from having to use a single language to write web apps.
- amelius 4y agoWhy don't browsers make their DOMs into Virtual DOMs? Then every application can be fast ... and websites don't have to carry the weight of their own vdom implementation.
- mbar84 4y agoI wouldn't be surprised if some people at google are working on a transactional approach to DOM manipulation, or perhaps something even exists already I'm not aware of. I think what we already have is implicit transactions, where updates are batched, so long as they don't depend on each other.
- deltathreetwo 4y agoJust make a whole new thing. Html and css are technologies with decades of technical debt. Like a remake of a movie, we are long overdue.
- brap 4y agoI don't need this, but I just wanted to say that everything Vercel puts out looks very nice and polished. Top UX in my opinion.
- nojvek 4y agoWelcome the take on tiny fast libraries. I do like that it is react ish in terms of its api. Svelte is a bit too far into the world of custom syntax and special compiler magic. Solid.js is great as it is compatible with jsx tools. The future is definitely libraries that keep fine grained track of state and how it’s bound to the view, and then efficiently reconcile. React is great and I’ve used it in prod for multiple years, but it does get slow at times due to too much CPU spent running vdom diff on large trees.
- leke 4y agoDoes this require node for development? From the getting started, it looks like it does, but wondering if there was a way to include the library as a script, like with AlpineJS. Million looks nice, but I'm not into developing with node at all.