Hacker News new | comments | ask | show | jobs | submit login
Show HN: HyperApp – 1k JavaScript framework for building web applications (github.com)
303 points by starbuzz 8 months ago | hide | past | web | favorite | 162 comments

If you're interesting in a reactive template library that doesn't require a compiler for non-standard JavaScript syntax, check out a library I've been working on for a little while now, lit-html: https://github.com/Polymer/lit-html

Where JSX would look like this:

    const view = (state, actions) => (
        <button onclick={() => actions.down(1)}>-</button>
        <button onclick={() => actions.up(1)}>+</button>
The lit-html would be:

    const view = (state, actions) => html`
        <button onclick={() => actions.down(1)}>-</button>
        <button onclick={() => actions.up(1)}>+</button>
Nearly identical. lit-html uses `<template>`s and cloning, so that it doesn't have to do any expensive VDOM diffs.

> Nearly identical. lit-html uses `<template>`s and cloning, so that it doesn't have to do any expensive VDOM diffs.

So… it's not doing reconciliations and is just replacing the entire tree on every render, losing things like cursor position and forcing the browser to re-render and re-layout the entire thing?

Highly recommended to watch https://youtu.be/Io6JjgckHbg

Yeah nah, I'm not watching a 30mn video on something I'm not interested in to get what amounts to a 2-paragraphs answer.

30m sends you home? Watch it on 2x and skip parts you aren't interested in.

I really want a way to get a generated voice recognition transcript for all that content people really think needs to be in video form. 2x playback is still 14:45 too long in this instance.

It's not that anyone thought it _needed_ to be in video form, it's just a conference talk. For reading there's the readme here: https://github.com/Polymer/lit-html and documentation site here: http://polymer.github.io/lit-html/

They both go into how lit-html works and how it doesn't just throw away and recreate the DOM on re-renders, though I admit the docs could still be better.

Great video!

Relevant part is at 8:30: "at first it will render the DOM and after that it will update what's already there"

Thanks for the link, lit-HTML looks pretty neat.

No, not at all. It marks the places in the DOM that can change and on updates only changes those.

Actually it does not :)

> so that it doesn't have to do any expensive VDOM diffs.

I am wondering, how is it possible that such non-expensive algorithm is more expensive than many VDOM libraries in this benchmark[1] ?

1. https://rawgit.com/krausest/js-framework-benchmark/master/we...

Please note:

1. benchmarks have zero information value

2. be careful about wording, react does effective DOM update, but effective does not always mean fast - what I mean is that compiled templates are usually much faster than doing vdom diffing along with all of that destructuring and other unoptimizable (prepack might help, but it's far from being usable) stuff

> 1. benchmarks have zero information value

Statements without any proof is more valuable than "benchmarks with zero information value"?

> what I mean is that compiled templates are usually much faster than doing vdom diffing

If they are usually much faster, why it is so hard to make them perform faster than vdom libraries in this benchmark? Or maybe any other benchmark, please just show me something that I can measure.

Also check out https://viperhtml.js.org/hyper.html, original inspiration for lit-html.

Same principle, different implementation, takes advantage of special string literal properties to achieve impressive speeds.

Template strings loses all the actual benefits of JSX, in that you can have your editor parse it for validity and type hinting in the same way as if it was all createClass class (but more convenient).

Loving Polymer 3.0 and the new lit-element (which I believe just straight up used lit-html behind).

That looks just like choo!

choo https://choo.io/ uses tagged templates too.

It's 4kilobytes.

The equivalent would be https://github.com/choojs/nanomorph, choo's diffing engine based on morphdom.

You should check out https://github.com/choojs/choo (similar framework in 4kb) and other packages in its ecosystem — https://github.com/choojs/nanohtml (template strings to HTML elements)

> ... expensive VDOM diffs

Wait, I thought VDOMs were supposed to be fast(er).

Note: I'm not a FE Dev, so I'm only going by stuff I (think I) read, not write.

It ultimately comes down to Amdahl's law: doing something in a browser requires updating the DOM. Since you always have to do the DOM processing, the only way adding the extra virtual DOM work will be a net win is if it makes it easier to avoid unnecessary updates or allows something like ordering updates to avoid triggering repeated layouts / reflows[1].

Since updating the DOM is relatively fast in modern browsers it's not particularly hard to find cases where the work the virtual DOM has to do cancels out any savings.

1. See e.g. https://developers.google.com/web/fundamentals/performance/r..., a list of triggers at https://gist.github.com/paulirish/5d52fb081b3570c81e3a, and https://github.com/wilsonpage/fastdom for a common technique to avoid it by manually ordering read operations before writes.

Here’s a moderately detailed explanation I made a few months ago: https://news.ycombinator.com/item?id=15957517.

fast(er) is relative. and _not_ doing a thing is often faster than doing a thing.

Replacing the entire tree is very rarely, if ever, faster than doing the fast thing.

True, but neither virtual-dom nor lit-html replace the entire tree.

Isn't vdom diff a way to not do things?

You have to do the diff, which is a thing. lit-html doesn't do the diff because it knows from the template what parts actually change. No need to diff the parts that never change.

Then you need to send lit-html over to the client also. This would be a great alternative if one doesn't already use Babel, but what's the selling point otherwise? Is there an easy way to combine lit-html's render with the HyperApp one?

IMO, the problem of composing renderers is solved at the component level. Each component should be able to freely choose its rendering library and control its own encapsulated DOM without interfering with other components, or leaking it's choice of template library to the outside.

Web Components and Shadow DOM make this possible. You can mix and match components that use lit-html, Polymer, Preact, etc., and mostly likely HyperApp.

But mixing and matching causes your page to bloat due to needing to download all the different libraries, right?


I think within your own components it makes sense to stick with a single library setup for this reason, but atleast if you want to use a third-party component you don't have to rule out components that use different rendering machinery. You just have to weigh that additional download penalty.

Well... At this point you can't e.g. include two web components when one of them uses Polymer 1 and one of them uses Polymer 2, for example...

That's only because Polymer 1 and 2 installed themselves on the `window.Polymer` global, so they would conflict, and Polymer 1 used the old Web Components v0 spec. Polymer 3.0 doesn't write to any globals and can intermix with LitElement, other Web Components libraries, and future Polymer 4.0 and beyond.

That's a great step forward :) And how about using two Web Components that depend on a third component? For example, what if I'm using two third-party components that both depend on LitElement, but on different versions of LitElement? Will those still conflict?

But then you miss out on html syntax highlighting and jsx eslint.

Or is there tooling that works for the tagged template approach?

This is an exceptionally simple library to use in place of React. Both its performance and the development experience have been great.

My company's been using it in production for more than a year now without any issues. Highly recommend giving it a look.

Just out of curiosity, what was your use case that you deemed this a better option than react for?

We use Hyperapp to power our most complex UIs (decision trees, onboarding sequences, etc.). We didn't need any of the existing React ecosystem for that, and by removing React, we saw several benefits:

1. Smaller library for faster page loads

2. Simpler API, docs and library made it easy to get started and understand what's happening behind the scenes as well as debug any issues we faced

3. We aren't supporting a project run by Facebook, which I personally view as a good thing given Facebook's many previous issues. Facebook's patent clause (while it no longer exists) was a factor in our original decision.

I would choose Hyperapp again for my company, and I use it for personal projects as well.

Why not Preact?

It came down to preference. I find HyperApp's codebase simpler to read/reason about (it's a pretty straightforward single file), and I prefer its API over React/Preact's.

Because Preact and Hyperapp are solving slightly different problems.

Hyperapp is Elm-like state management (and soon effects and subscriptions in 2.0) on top of an ultra-lightweight virtual DOM diff engine.

Preact is a React 15 clone at best. Check out also https://github.com/NervJS/nerv for another React clone that is closer to React 16 (but still no fiber).

people should really give it a book

I guess look? :)

There's a book though: https://booth.pm/ja/items/825889 (Japanese)

It's not very performant compared to other v-doms https://rawgit.com/krausest/js-framework-benchmark/master/we...

Hyperapp is not optimized to be the fastest framework at the expense of worse developer experience. Having said that, we're definitely working on improving our runtime performance (see https://github.com/hyperapp/hyperapp/issues/499). So much to do!

I want to point out that while these benchmarks are very useful to detect underlying, potentially serious runtime and memory performance issues in your algorithm/framework, the implicit idea that even the slowest framework according to this list (e.g. choo) is a poor choice or inadequate for frontend development is ridiculous (the js-framework-bench creates > 80,000 nodes).

Please don't do that to your users, regardless of the framework you are using. Even the most complex user interface will have < 10,000 nodes. Tables/grids may get you there faster, however.

Still, in the case of Hyperapp we're talking about 100 to 200 milliseconds slower in the worst test (i.e., partial update) for a worst-case scenario.

This is an old benchmark, we're in the same ballpark as React now. Hyperapp is also not just a virtual DOM, but also a state management "all-in-one" kind of thing.

It's not old, it was last updated two days ago:


I meant the benchmark is using an older version of Hyperapp.


The js-framework-benchmarks is very much maintained and actively developed. It's our go-to benchmark when fine-tuning for a new release.

In addition to that, the latest code on master (still unpublished) includes some notable improvements:


Wow kudos to the author! Very nice resource

hyperhtml - which this is based on, similar API - can be found at the left end of the table.

I've seen "Show HN: HyperApp" type of submissions at least 5 times earlier. Congrats, you made a 1Kb JS library. Please stop spamming HN though.


I don't even get why it is important that it's 1kb. Give me a library with great API and easy to use. Nobody cares if library is 1kb or 100kb (minified).

Don't assume that everyone is happy with whatever level of mediocrity _you_ think is acceptable. It's because of developers prioritizing developer experience and other baggage over user experience that I despise my mobile web surfing experience.

Plenty of people do care about frontend performance (as evidenced by the plethora of efforts ranging from small alt vdom libs by solo devs to large corporate efforts like AMP or m.uber.com[1])

[1] https://eng.uber.com/m-uber/

>>Don't assume that everyone is happy with whatever level of mediocrity _you_ think is acceptable.

So large library size == mediocre?

Jesus christ, HN is full of extremists.

A large library is perfectly fine if it provides enough functionality to pull its own weight. But these days just about every site on the web has dozens if not hundreds of bloated libraries for the stupidest things and large bundle sizes due to that have become a pretty good indication of wrong priorities from the developer's part.

And I, as a user, am left waiting several seconds waiting for pages larger than the original Doom executable to load. It's gotten so bad that my wife had to be selective of when to use her phone because browsing normally without wifi from starbucks etc would get her over the plan limit by mid-month. I mean, how much browsing are you really supposed to be able to do when every page is several MBs of JS alone, and you have a 300MB/mo plan to work with? Not every country has cheap/good mobile plans.

^ This

The irony is you are the extremist for thinking HN is full of extremists! :)

Also, library size !== mediocrity at all. No one builds an unreasonably large framework on purpose either.

Given an equal feature set (and similar performance), a larger lib is worse, yes.

If your problem space requires a lot of code, then off course not.

HyperApp has a great API, and for Web client code, size does matter.

> Nobody cares if library is 1kb or 100kb (minified).

You do if your app needs to be mobile-friendly. 100kb can easily add an extra second or two to the page load on a bad enough mobile connection.

Article has 300kb+ of javascript on mobile, loads pretty fast on 3G. I don't know what you're talking about.

Mobile google.com loads 200kb+ of javascript and I've never heard anyone complain about loading speeds for it.

Loading time doesn't always result in complaints (that depends on the user's expectations) but has a significant effect on likelihood of repeat visits, length of visits, and amount of interaction.

Hyperapp has a great API, it's easy to use and it's 1 kB.

Some of those results refer to HyperTerminal, the Electron-based terminal app. Other results refer to Hyperapp-like libraries (not Hyperapp). The most recent submission related to Hyperapp was 8 months ago and Hyperapp has come a long way since then.

Here is another angle to this: go into React type of submissions and ask them to stop spamming HN with that?


You are a joke.

Show HN: 1 KB JavaScript library for building front end apps 242 points jbucaran 8 months ago 2 comments (https://github.com/jbucaran/hyperapp)

Show HN: 1 KB JavaScript framework for building front-end applications 216 points jbucaran 8 months ago 42 comments (https://github.com//hyperapp/hyperapp)

Show HN: 1kb JavaScript library for building front end applications 187 points jbucaran a year ago 40 comments (https://github.com/hyperapp/hyperapp)

Show HN: 1 KB JavaScript library for building applications 116 points jbucaran 7 months ago 8 comments (https://github.com/JorgeBucaran/hyperapp)

Show HN: 1 KB JavaScript library for building front end apps 40 points jbucaran 5 months ago 0 comments (https://github.com/hyperapp/hyperapp/releases/tag/1.0.0)

Show HN: (1KB) JavaScript library for building fast and feature-rich web apps 9 points jbucaran 5 months ago 4 comments (https://github.com/hyperapp/hyperapp#hyperapp)

Show HN: 1kb JavaScript library for building front end applications 4 points jbucaran a year ago 0 comments (https://github.com/hyperapp/hyperapp)

1kb functional JavaScript library for building UI applications 3 points jbucaran a year ago 2 comments (https://github.com/hyperapp/hyperapp)

Show HN: Less is More (1KB) JavaScript library for building user interfaces 2 points JorgeBucaran 4 months ago 0 comments (https://github.com/hyperapp/hyperapp#hyperapp)

JavaScript meets Elm 2 points jbucaran a year ago 0 comments (https://github.com/hyperapp)

> You are a joke.

Wow, so you're right. Do you need to be so rude about it?

In the same vein there's Mithril. It's 8kb but includes a router and a fetch polyfill!

I love these little JS frameworks :)


Mithril is nice. One downside is it doesn't lend itself really well to compound components. Everything has to be passed down through attributes.

You can define components as simple functions and avoid passing things down through attributes. If you use TypeScript with it, the compiler will always make sure you pass the right arguments to the component, so it's very easy to compose your UI.

I also avoid keeping state on components. I know this is controversial and it requires a bit of overheard. However, the simplicity offered by having all state in a single object is worth it for me.

True, but by passing the same object as an attribute to a pair of Mithril components, I can have them share state. (Can be restricted to the scope of a parent component if desired.) Is there an additional requirement for compound components?

There isn't a built-in way to detect type of component. It would be useful when you want a parent component to encapsulate certain logic/behavior but not hard-code the presentation. I know there's name() but it only works if my component is a function. Otherwise I think I need to assign some special identifier, which sucks.

You can see a great presentation of the technique in this video: https://youtu.be/hEGg-3pIHlE

Just want to second Mithril here. It is an awesome and refreshing approach. I love it too.

Oh, Mithril! All folk desired it. This one is great too.

I love hyperapp! As someone who thinks Elm’s architecture is ideal for building webapps, it’s great to be able to almost replicate it in JS. It’s simple enough to get started quickly but still robust enough to build actual apps and not just toys.

Hyperapp will be a lot more Elm-like in a future release, see this too: https://github.com/hyperapp/hyperapp/issues/672

I got confused thinking this was a new thing from Zeit -- who made Next.js and Hyper.app (https://hyper.is/)


This makes me almost want to write web code again - compared to things like React and Angular 1-2-3-4-5-6.

Just curious what intrigues you about this framework in ways that React does not?

Hyperapp is Elm for the rest of us. I wouldn't compare it to React as they are solving slightly different problems. Hyperapp's state management is built-into the framework. In this way, Hyperapp is a tad more "high-level" (abstract) than React.

> Hyperapp is Elm for the rest of us.

Curious who you think Elm is for?

Elm is for anyone. I love Elm.

"for the rest of us" is a common English language idiom/phrase.


I know the idiom mostly from For Dummies' books. I'm implying that Elm, while great, is not as user-friendly, intuitive or easy to use as Hyperapp.

I'm saying that Hyperapp is deeply inspired by Elm, but also designed with extreme devotion to details, minimalism, and simplicity.

> I'm implying that Elm, while great, is not as user-friendly, intuitive or easy to use as Hyperapp

First, Elm is designed to be user friendly. The designers of the language have put effort into ensuring the error messages are understandable. The messages even include information on how to potentially resolve them! Elm's error messages are much more friendly than most Javascript error messages I've seen.

Second, there is nothing intuitive about programming. If there were we wouldn't need years of training to gain proficiency: you could simply give a human being a computer and they would be able to do it in the absence of conscious reasoning. Despite our best efforts and research there has yet to emerge a language that is intuitive.

> designed with extreme devotion to details, minimalism, and simplicity

I believe Elm is also designed with these concepts in mind.

It sounds like it's not the kind of simplicity you're used to and that may be why Hyperapp is _for you_.

I interpreted the phrase, for the rest of us, to be a false equivalence between all programmers that do not use Elm and programmers with the same opinions and needs as you. I think I understand your point better now but it would have been clearer if you had left out that phrase and enumerated why it's better for people who need X instead.

Also curious.. Wwat would you miss from React if you only used hyperapp?

I agree. The more alternatives to react and angular the better.

React has a massive API for what is something essentially quite simple.

Personally my favourite "alternative" rendering library is hyperdom. Fast, simple and just gets the job done.


Not sure what your problem with React is, is it the configuration?

React is a ghetto, basicly + vdom has its own size. IMO thing like hyperhtml or lit-html are the way forward - especially with new templating proposals. Not to mention react is not interoperable really with other solutions - I'd expect webcomponents win long term, since they are built into clients.

What does "a ghetto" mean here? None of the definitions I know seem to fit.

> http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto

> https://www.theatlantic.com/education/archive/2016/02/will-t...

> https://jelastic.com/blog/functional-programming-is-a-ghetto...

The concept is that placing a focus on a specific technology is a path to decay (poverty, obsolescence, self-destruction, etc).

Hyperapp and Web Components are a great pair.

I've tried hyperapp and liked it a lot. I loved that can read full source code and actually understand what it is doing under the hood.

This is a crucial aspect of Hyperapp that often goes unnoticed because simply no one in their sane judgment expects it.

This looks pretty awesome! Inspired by hyperscript I assume?


Question: I was looking over the source and noted that you weren’t building your virtual dom with the document fragment API https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra...

Is there any particular reason why? I’m curious because it’s my general understanding that creating a document fragment and attaching your vnodes to that and then pushing to the dom is more efficient especially for diffing

I have heard that as long as elements aren't actually in the DOM, they are as fast as fragments, so you can use document.createElement instead of fragments. No idea if that's true or not.

Hyperapp is based on virtual DOM and yes, I guess you could say it's inspired by Hyperscript in the same way as all virtual DOM based libraries or frameworks.

This is the best thing I discovered since leaving React. x10 dev speed for me, not to speak about loading times. Superb work!

So far, the Infinite monkey theorem is just giving us an infinite number of javascript frameworks, and no Shakespeare

I'd disagree. React is very much a "Shakespeare" of javascript frameworks. It has solved UI dev by making even the most complex types of UIs predictably programmable. (Note: not including redux in this, which no developer who owns their time would use)

>>It has solved UI dev by making even the most complex types of UIs predictably programmable.

What's that they say about each and every framework. IMHO there is no Shakespeare and all JS frameworks will eventually die once web assembly is in place.

> So far, the Infinite monkey theorem is just giving us an infinite number of javascript frameworks, and no Shakespeare

Not even funny IMO. This is the kind of toxic comment that don't motivate progress in this community.

Take it easy, it's just a joke that I post to every JS framework thread on HN:)

How does this compare to Preact?

I replied to another similar comment but the TL;DR is that both are solving different things. Preact is a React 15 clone.

Hyperapp is basically Elm in JavaScript.

Side question: Isn't it grossly inefficient that in Redux, you have reducers that return an entirely new state object? Wouldn't it be better to return some kind of data that represents just the diff you intend to make, like {op: INCREMENT, arg: 1, key: "Foo"}?

It's doubtful that state changes are the bottleneck for application performance, for most applications. Rendering and managing the lifecycle of your components usually yields much more tangible perf. gains.

It depends. If you are making a shallow copy every time via `Object.assign` or the `{...obj}` syntax, then yes, it is rather inefficient. But a) for many (most?) apps it's Good Enough™, and b) you can always use a specialized library like Immutable.js to greatly reduce the overhead.

I'm not sure about what would be the benefit of the scheme you are proposing. Are you proposing that the diff then gets applied directly to the state (`state.foo += 1`)? If so, you would remove a powerful assumption that Redux gives you: that a state object will never change from underneath you after being returned from the store. If, instead, you would make a shallow copy of every value affected by the diff, then you haven't gained anything over Redux, and in fact have made the API significantly more complicated for no benefit (aside from maybe slightly less boilerplate for deep paths).

Oh right, immutable data structures are good for exactly this situation. I've been in mutation land for a while now. :)

However, now I'm newly confused: Yes, I'm proposing that the diff then get applied directly to the state by the Redux infrastructure, and I don't understand why that would break any important assumptions provided by Redux. Is there an example you could give of how this might create a problem?

You would have to be much more disciplined with your approach. With Redux, if I store a reference to any part of the state, I am guaranteed that the value will never be changed by Redux itself (so, unless I manually mutate it, it is guaranteed to be frozen [0]). Because of this, I can do things like safely store a value off of the Redux state inside a component, and when the state changes, I can compare the new value against my stored value to see if it has changed. If you directly mutate state, then the reference would update in-place, so there is no way to compare changes locally without first making a copy.

It also goes the other way: I can't accidentally change the state by mutating the object I get back. With your scheme, any "accidental" mutation on any part of the state will actually change the state. This opens up a whole world of bugs, because any time you want to store part of the state locally (inside a component, for instance), you have to remember to make a copy if you want to guarantee that no unwanted side effects occur. (Plus, getting into the convention of "everything is immutable" means you can generally be much more confident about passing objects around without fear of them being mutated unexpectedly.)

Edit: Now that I think about it, what you are proposing sounds pretty similar to MobX.[1] You should check it out if you haven't already. I personally strongly prefer Redux for the reasons I mentioned, but it's a pretty solid library either way.

[0]: In development, it's very easy to enforce this with Redux by simply calling `Object.freeze` on the state in the root reducer, completely preventing the state object from being mutated.

[1]: https://mobx.js.org/

That is exactly what a Redux action returns. It's a representation of a diff against the current state. At some point though, that diff has to be applied in some form, either atomically (as currently) or through mutation. Actions trigger the reducer that applies the diff to the store.

Basically, I'm not certain exactly what you're getting at.

If just the diffs were returned, you'd need to constantly reapply them to recreate the latest state. By returning the entire state the previous reference can be discarded.

Well, I'm thinking that Redux would apply the diffs to the state destructively, so I'm not sure why we would need to "constantly" reapply them in order to recreate the latest state... we would simply have the latest state on-hand already. But if we're in a context where a lot of rewinding and fast-forwarding of state is happening for some reason, or where these state diffs can't easily be reversed/inverted, then I can see why this would be inefficient.

You might be interested in skipping Redux and just using a state pattern like this http://meiosis.js.org

That looks awfully complicated.

Sorry is that sarcasm? 3 lines of code for a state pattern. Redux is the one that's awfully complicated.

Sorry, no, it's my honest opinion. I am the kind who is more interested in ideas and patterns than in libraries or frameworks, so I had a look, but this looks like the typical work of a design-disabled programmer. I am not saying that is garbage, but I don't like neither the execution or API design.

Redux can be complicated, but Redux is way simpler and easier to reason about than the Meiosis patterns.

> Think Redux, MobX, Cerebral, React Context, etc. but without having library imports everywhere and being tied to a framework API. Instead, just plain functions and objects.

Undelivered promise.

Objects in JavaScript are references so internally it's just a pointer being passed around.

Hmm, but reducers are supposed to return references to new state objects, right? So clearly something more substantial than a pointer has to be created/duplicated.

New object => new pointer.

How does this compare to Inferno, which you can also use JSX and Hyperscript with - https://github.com/infernojs/inferno

This seems smaller in footprint, but does it also win in runtime performance and stability?

Hyperapp can use JSX via the transform-react-jsx plugin.

I've really enjoyed using Hyperapp so far. Looking forward to building more with it.

Does it work well with inputs? (text, checkboxes, radios, selects)

It looks more like Elm

If all goes according to plan, it will look even more like Elm in the next major release (2.0).

Wow, there's an overwhelming total of 2 comments in the source file. The first indicates a constant value. The second lacks all context. Looks like typical JavaScript code.

This comment violates both the site guidelines ("Please don't post shallow dismissals, especially of other people's work.") and the Show HN guidelines: see "In Comments" in https://news.ycombinator.com/showhn.html.

Understood. I'll refrain from such comments in the future.


Maybe there's simply nothing else to say.

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

Surely there are many more ways.

Another Virtual DOM thing - which is obviously wrong.

It's not ok to post like this to HN, and especially not in Show HN threads. Here are some of the rules it breaks:

Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.


Be respectful. [...] Instead of "you're doing it wrong", suggest alternatives. [...] don't be gratuitously negative.


Can you explain (or link some source) why is Virtual DOM wrong? Actually curious.

Hi. I'm the author of Mithril (one of the virtual dom frameworks mentioned elsewhere in this thread), so I think can answer that.

To be honest, there's nothing inherently "wrong" with it. There are various techniques to implement templating engines and they all have pros and cons.

Lately, VDOM performance in micro benchmarks has sort of plateaued, and recently non-vdom systems like Svelte (an AOT compilation system) and Surplus (a KVO system) have been making some splash as potential candidates to surpass vdom performance. One could argue that it would be "wrong" or "a waste of time" to try to one-up template performance by attempting to make a new vdom implementation because existing ones are pretty much as optimized as they can be. Since there hasn't been nearly as much effort put into alternative algorithms, it probably would be more fruitful to explore a non-vdom approach instead.

Do note though that I'm talking about R&D sort of stuff above. For people building actual apps, vdom performance is generally good enough for a vast majority of real-world use cases (evidenced by React's popularity) and one of its appeals is that it lends itself to being manually optimizable it if you do end up with a ridiculously ginormous DOM.

> Since there hasn't been nearly as much effort put into alternative algorithms

Angular2+ team is actually have done an awesome job at experimenting in this problem space. And they've moved away from generating code that is similar to what Svelte does long time ago.

Care to provide more details? Why is it wrong?


This one is 25 bytes gzipped http://vanilla-js.com/

The dependencies add up though, it's more like it's 17 Megabytes on the server


Or 30 MB for the client side


You do realize that this is simply a page that advocates using plain JavaScript and isn’t an actual “framework” right?

I mean I can see the point you are trying to make, but it feels mildly disingenuous to link to this without explaining what you really mean.

People really enjoy pulling this up every time a JS framework is talked about, and it's really tiring.

I say this as someone whose entire job is writing "vanilla JS" without any sort of framework!

People do have a tendency to overdo tooling and lean too heavily on frameworks to get things done, but if you're building something without one you end up creating a lot of abstractions and boilerplate yourself to do anything relatively advanced and end up with a micro-framework of sorts at the end of the day, not unlike what was posted here! There's a lot of value in taking something small like this and building off of it.

Just linking to that vanilla JS site is snarky and unproductive.

It's just a joke really.

I have a better one.

Knock knock... blank page... <Ctrl>+<Shift>+<I>: "Uncaught TypeError: cannot read property 'a' of undefined."

vanilla-js is really powerful! One incredible feature they don't even list yet is Web Components.

Preach! we on the vanilla JS train can speak of it's performance, easy to deploy. <script type='module'>. <template> and template literals can your app scoring 90s on lighthouse, as if server rendered.

Hyperapp and Web Components is a great combo, especially because they can help with the problem of maintaining local component state, not a feature of Hyperapp.

0 bytes unzipped!

Except, OP is showcasing a framework, and this is a library. And mostly native to browsers already.

Excuse me, is native.

> mostly native to browsers already


That, no one can beat.

Does it work in ie9?

Yes. Not IE8, though.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact