Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: HyperApp – 1k JavaScript framework for building web applications

github.com

Post reply on HN
Print view View original

151–160 of 169 posts

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#151

Post by starbuzz »

bufferoverflow wrote: post #148
starbuzz wrote: post #120

Earlier quoted context omitted.

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: https://github.com/krausest/js-framework-benchmark/commits/m...

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

https://github.com/krausest/js-framework-benchmark/tree/mast...

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:

https://github.com/hyperapp/hyperapp/pull/663

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#152

Post by elbear »

dsego wrote: post #77
gandreani wrote: post #47

In the same vein there's Mithril. It's 8kb but includes a router and a fetch polyfill! I love these little JS frameworks :) https://mithril.js.org/

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.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#153

Post by Vinnl »

seabrookmx wrote: post #51
simplify wrote: post #43

Earlier quoted context omitted.

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

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

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#155

Post by starbuzz »

owlfarm wrote: post #37

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

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#156

Post by starbuzz »

sAbakumoff wrote: post #150

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

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

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#157

Post by sAbakumoff »

starbuzz wrote: post #156
sAbakumoff wrote: post #150

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

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

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#158

Post by pygy_ »

enraged_camel wrote: post #147
lhorie wrote: post #100

Earlier quoted context omitted.

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…

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

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.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#159

Post by starbuzz »

enraged_camel wrote: post #147
lhorie wrote: post #100

Earlier quoted context omitted.

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…

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

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.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#160

Post by chrismorgan »

JustSomeNobody wrote: post #45
spankalee wrote: post #35

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) => ( {state.count} actions.down(1)}>- actions.up(1)}>+ ) The lit-html would be: const view = (state, actions) => html` {state.…

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

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