Million: less than 1kb virtual DOM that is fast

by bpierre • 4 years ago

210 167 4 years ago

aordano2• 4 years ago

This 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.

echelon2• 4 years ago

First time I've seen "DX". Developer experience, I assume from context?

That's an awesome term and I'm going to steal it.

aordano2• 4 years ago

Yes, developer experience. I thought it was a common term, maybe not so much.

And I agree, it's a great term :)

8n4vidtmkvmk• 4 years ago

ya,. 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

franciscop2• 4 years ago

I 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

LAC-Tech3• 4 years ago

If this is the first time you've seen DX I've got two words for ya

aidenyb5• 4 years ago

Thanks for the feedback, Million has a React compat layer https://millionjs.org/docs/start-here too

toastercat• 4 years ago

This 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• 4 years ago

Coincidentally, 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

[2] https://mithril.js.org/hyperscript.html

pier25• 4 years ago

Did 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• 4 years ago

I 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-Tech3• 4 years ago

I 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• 4 years ago

Looks 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• 4 years ago

VDOMs 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/

mhoad3• 4 years ago

VDOM 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)

aidenyb5• 4 years ago

Thanks! We're planning on adding a benchmark soon: https://github.com/aidenybai/million/issues/37

nhinck2• 4 years ago

Why is my phone scrolling at 10fps on this page? Not exactly a great first experience.

Crystalin• 4 years ago

I don't want to sound rude... but ...maybe it is your phone ! :p

ImPostingOnHN• 4 years ago

easy way to tell: does it happen with other Javascript frameworks?

realPubkey• 4 years ago

Same for me on mobile chrome

ac130kz• 4 years ago

I also have poor scrolling experience, but I believe it is due to some sort of a "smooth" (sic) scrolling library

smartbit• 4 years ago

Below the heading, I see a mostly black page with a few icons. It does scroll fast though :)

realitysballs• 4 years ago

The video really hypes me up despite lacking any technical depth

collegeburner• 4 years ago

fr its slick af and gives off mad apple commercial vibes

richardfey2• 4 years ago

I wonder how it compares to http://vanilla-js.com/

Blackthorn3• 4 years ago

This 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?

enjoyyourlife• 4 years ago

It's a joke website mocking the proliferation of JavaScript frameworks

bob10292• 4 years ago

We 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• 4 years ago

So, 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• 4 years ago

It’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).

leeoniya6• 4 years ago

as always, take any performance claims with a healthy dose of skepticism; still waiting on 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.ht...

aidenyb5• 4 years ago

Author of Million here -- Don't trust my benchmarks at face value! Always run your own benchmarks

leeoniya6• 4 years ago

you'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.

nprateem• 4 years ago

But is it modern?

lgas• 4 years ago

Forgot to edit the Nextra meta tags.

brundolf2• 4 years ago

Bit 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?

aidenyb5• 4 years ago

Million 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

brundolf2• 4 years ago

To 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• 4 years ago

Ah, 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!

toxicFork2• 4 years ago

Would this be able to support projects like react three fiber?

russellbeattie• 4 years ago

Before anyone gets too harsh or critical, check out the about/research page. The author is in high school.

I feel old.

mr90210• 4 years ago

LOL.

seejayseesjays• 4 years ago

If the benchmarks hold true, (and I don't doubt they will,) this is incredibly impressive! Neat research!

IIsi50MHz• 4 years ago

Wondering 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).

janci2• 4 years ago

Do 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?

janci2• 4 years ago

To 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• 4 years ago

What you are describing sounds closer to how Svelte works.

eldenring• 4 years ago

writing to the DOM is slow, you use VDOM to batch updates and other optimizations

franciscop2• 4 years ago

What do you mean by "state tree" here? And how do you go from the state tree diff to the required dom diff?

speedgoose• 4 years ago

I 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.

naniwaduni• 4 years ago

Why diff trees at all when you can record a changeset and patch DOM based on that?

hajile2• 4 years ago

Preact does this and is also small and react compatible.

sickill• 4 years ago

Sounds more or less like Solid.js

vanviegen• 4 years ago

Yes, that's possible and works really well.

I've written this library [1] as a clean reimplementation of a more complex beast we created for a (now dead) startup. Although the reimplementation has only seen very light use, we've used the concept extensively, and it's a joy to use. Take a look at the examples [2].

[1] https://github.com/vanviegen/aberdeen [2] https://github.com/vanviegen/aberdeen/tree/master/examples

88913527• 4 years ago

We don't need VDOM, but we can't live without it either. The problem is too many people are bought into not just React, but all of the open source components out there too (not a problem persay, it's created a ton of value for many). React does have an elegant API surface, not sure how possible is to keep that, but then somehow give it Svelte-like functionality. React is the golden handcuffs of front-end today.

_the_inflator• 4 years ago

The 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

Also Google sheets results show overall, that DOM is faster than any virtual DOM, so why produce overhead? 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.ht...

toxicFork2• 4 years ago

It feels nicer to use functional components with declarative state than set dom attributes imperatively.

jsf01• 4 years ago

Plenty 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.

LAC-Tech3• 4 years ago

lit-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.

baobob• 4 years ago

Over a certain size, some level of abstraction will usually produce a meaningful reduction in code size in most applications. It's possible for some applications a virtual DOM is the abstraction to achieve that, although I don't think I've seen this in practice. It would require an absolute mountain of "document.createElement() / appendChild() / setAttribute()" code before the lighter syntax of a virtual DOM would net a meaningful size reduction with a modern compressor like Brotli.

Just saying there are probably situations where these might still offer a genuine functional benefit, simply by virtue of offering abstraction.

There are a bunch of replies here focusing on how nice to use virtual DOMs can be, would gently encourage those folk find another industry to ruin.

bedatadriven• 4 years ago

The VDom was never intended as a performance optimization over direct dom manipulation.

It is a tool to make functional reactive programming style _almost_ as performant as direct dom manipulation.

The comparison that's relevant here is, how long does it take to repaint the view if I recompute the view as a function of my state every time my state changes?

Compared to rebuilding the dom tree on every change, using a vdoms and diffing offer a huge speedup.

Using jquery/vanilla js to update thr dom in an adhoc fashion in response to user input (when the user clicks "next", then add a class to this dom element, remove this other element from this other random place...) has always had faster runtime, it's just more likely to be coded wrong.

FRP is an abstraction that makes writing and reasoning about correct UIs easier. Vdom is a technique that makes this abstraction practical.

nailer• 4 years ago

The link in the previous comment explains why the virtual DOM is overhead, and you haven’t responded to that. Svelte and other current gen compiler-based approaches allow FRP and do not require a virtual DOM.

peoplefromibiza6• 4 years ago

how long does it take to repaint the view if I recompute the view as a function of my state every time my state changes?

you don't need vdom to make this fast.

you compute your state in whatever data structure you like and then requestAnimationFrame updates the DOM if and where it is needed.

VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW.

edflsafoiewq• 4 years ago

There's reasons more fundamental than speed you can't just blow away the DOM and recreate it all the time. You'd lose stuff like the user's selection, the contents of forms, etc.

acdha• 4 years ago

The VDom was never intended as a performance optimization over direct dom manipulation.

This is untrue as written after a decade of fanboys making this exact claim. I think your point that it’s an optimization for a particular style is correct but starting with this encourages knowledgeable readers to skip your comment.

jesse__5• 4 years ago

The VDom was never intended as a performance optimization over direct dom manipulation.

Performance was definitely it's primary purpose.

Remember Flux? THAT was the architecture that introduced FRP to the masses (based on the Elm architecture). The VDom was invented because large dom trees were too slow when you got to thousands (maybe tens of thousands, I forget) of nodes. Which is hilarious if you think about it .. somehow the C++ DOM update loop was slower than someone clever doing it in single threaded JS.

Using jquery/vanilla js to update thr dom in an adhoc fashion in response to user input [...] has always had faster runtime

This is very incorrect.

it's just more likely to be coded wrong.

While not outright wrong, I find this somewhat debatable. React is pretty complicated these days and it's quite easy to get tangled up if you're not conscious of what you're doing. FRP isn't a silver bullet.

dan-robertson• 4 years ago

I don’t really understand what you’re point is? Isn’t the ‘dom is slow’ thing about comparing to e.g.

- creating actual DOM elements during render and diffing that with the DOM, or

- using the existing DOM as the thing being diffed against your new vdom (slow because calling into the browser many times may be slow and you need to check eg there aren’t attributes to be removed from your elements)

Perhaps it’s also necessary to mention that the main point of vdom was to allow react to offer the API it does performantly but maybe with compiler-based solutions like svelte that isn’t necessary. Lots of people still use react, however.

supermatt2• 4 years ago

To my understanding, the virtual DOM used for efficient "diffing" of the subtrees - i.e. producing the optimal set of DOM updates required.

If you are building any abstraction on top of the DOM to handle that, then you have effectively built a virtual DOM.

Or are you suggesting that setting innerHTML and allowing the browser to re-construct the DOM is now faster? I can assure you that is not the case!

jesse__5• 4 years ago

Look at their benchmarks. They compare against innerHTML and against (I assume) inserting new DOM nodes. Million is slightly faster than the former, slightly slower than the latter. DOM manipulations are fast these days

pyrale• 4 years ago

Then came Google Chrome and their optimizations.

I'd be curious to know whether this holds true for other browsers out there.

hajile2• 4 years ago

InfernoJS uses a vdom is faster than Svelte in the js framework benchmark.

Even if we set that aside, the differences between something like Svelte and React are still likely to be far less than the differences you'll gain from changing to a more efficient algorithm.

pkrumins3• 4 years ago

Why use virtual dom when you can just use regular dom?

zmxz• 4 years ago

Because 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.

pkrumins3• 4 years ago

Right on!

amoerie• 4 years ago

Can you write declarative reactive components with regular dom? If that wasn't an issue, why wasn't React immediately designed that way?

pkrumins3• 4 years ago

What is React?

mouzogu• 4 years ago

I keep seeing this expression "batteries-included" on every javascript library and framework, what does it mean?

Banana6992• 4 years ago

It'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"

onion2k7• 4 years ago

Very 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.

AtNightWeCode3• 4 years ago

SEO

onion2k7• 4 years ago

Your choice of framework should make very little difference to SEO. SSR, SSG, ISR, etc will have far more impact.

Dont forget that Google's crawler is literally Chromium these days. https://searchengineland.com/google-will-ensure-googlebot-ru...

Banana6992• 4 years ago

Why do you think slow web apps are slow?

maccard5• 4 years ago

Poor/no architecture. On the client side - requiring multiple API calls that take tens of ms to respond,doing them serially, trying to mask this with loading transitions that take up to a second that are hit multiple times during common use.

On the server side, a pile of microservices that are designed around team responsibility, with requests that require requests that require requests to respond to common API calls. The desire to write the backend in JS causes a very low perf ceiling on a single instance which means a medium sized web app needs a dns lookup, load balancer hit plus reverse proxy in place for (m)any of the API calls, even if they're internal/trusted.

These apps are tested and benchmarked on the highest performance professional computing devices on local networks with gigabit connections, and then deployed to 5-10 year old computers running on 10Mb connections shared between 4 people. The servers are deployed to a large number of low cost cloud instances running on a virtualization layer inside a virtualization layer on "enterprise grade" (read: slow) hardware with real world disk and network speeds that are orders of magnitude slower than what is used for testing.

Pick any/all of the above!

onion2k7• 4 years ago

Mostly due to developers writing code that synchronously waits for network requests to complete before updating the DOM. The user clicks, then nothing happens while the app sends a request, and app only updates the DOM after the request completes. It's that 'nothing happens' step that makes things feel slow. They do other things like rerendering part of the app every time any part of the state changes rather than limiting the updates to just the bit that matters to that component too, so the app is doing a ton of unnecessary work (React helps here; it ignores state updates that don't change anything).

There's a lot of problems in web apps that make them feel slow, but they mostly distill down to developers following some bad practises that are easily avoidable. Web apps that are slow because they're maxing out what the framework is capable of are very, very rare. Making a faster framework won't fix the ones that are just coded badly. Making a more intelligent framework might.

pygy_2• 4 years ago

Slicing big updates and prioritizing some of them could also be achieved by tweaking the reactive core of Solid or Svelte.

onion2k7• 4 years ago

Of course, but until those libraries actually do it I don't see the value in saying so. Any library could do it.

dham• 4 years ago

React does everything wrong: vDom, components rendering multiple times instead of once then reacting to changes, manual memoization techniques. Hence why Svelte and Solid are not only have a better dev experience, they're also much, much, much faster and eventually will take over React as it will go the way of jQuery, Knockout, Backbone, etc

v0idzer0• 4 years ago

Svelte is already 6 years old and nowhere near competitive with React in terms of popularity

cercatrova3• 4 years ago

Anything that has me write in templates in HTML like it's PHP is a no go for me. JSX reigns supreme for a reason.

beanjuiceII• 4 years ago

I work on a gigantic react app...It would take me days to explain everything this app does..and we've not once had performance concerns with react..so I'm really wondering what the hell kind of apps everyone else works on that they have so many issues with it.

CapsAdmin• 4 years ago

I have not explored why, but facebook.com seems incredibly slow.

sporkland• 4 years ago

Been a while since I worked on WebApps. I agree with your sentiment that a lot of up front and then small changes over time. VDOM and Just refresh the whole page seem like consequences of how we express our DOM construction.

I'm curious if anyone is working on and had success with using differentiable (in the math sense) expressions of dom construction from state/events in order to allow the runtime to easily calculate diffs given state changes/events.

thrownwayne• 4 years ago

Just 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• 4 years 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.

rrishi3• 4 years ago

Why 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)

anonymoushn2• 4 years ago

Might it have something to do with being forced to use it?

peoplefromibiza6• 4 years ago

we'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.

carapace• 4 years ago

Pretty much. I keep asking people "Why not Elm?" ( https://elm-lang.org/ ) but no one has a very good answer.

The weird thing to me is that the two main customers or consumers of front-end programming (publishers and users) never see and do not care about the underlying language or implementation! Businesses and other orgs (schools, NGOs, etc.) as well as individuals (FB users, WordPress blogs, etc.) that publish sites/apps on the web and their visitors and users never see under the hood except when something goes wrong or they deliberately click "View Source", eh?

Ergo, all this whole Javascript ecosystem is solely for the developers. It's like a giant and largely irrelevant MMORG that we play that produces mostly-working websites and apps almost as a side effect.

"Change my mind?"

jmull3• 4 years ago

The question is really “Why not Javascript, and if not, then why Elm?”

amelius• 4 years ago

Why 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• 4 years ago

I 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• 4 years ago

Just 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• 4 years ago

I 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• 4 years ago

Welcome 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• 4 years ago

Does 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.

Million: less than 1kb virtual DOM that is fast

Related Stories