10 ms·
Show HN: HyperApp – 1k JavaScript framework for building web applications
- isakkeyten 8y agoThis one is 25 bytes gzipped http://vanilla-js.com/ http://vanilla-js.com/
- starbuzz 8y agoThat, no one can beat.
- jordan801 8y agoExcept, OP is showcasing a framework, and this is a library. And mostly native to browsers already.
- no_wizard 8y agoYou 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.
- danlugo92 8y agoIt's just a joke really.
- cpburns2009 8y agoI have a better one. Knock knock... blank page... <Ctrl>+<Shift>+<I>: "Uncaught TypeError: cannot read property 'a' of undefined."
- ericwood 8y agoPeople 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.
- throwaway413 8y ago0 bytes unzipped!
- squeaky-clean 8y agoThe dependencies add up though, it's more like it's 17 Megabytes on the server https://nodejs.org/dist/v8.11.2/ https://nodejs.org/dist/v8.11.2/ Or 30 MB for the client side https://www.google.com/chrome/ https://www.google.com/chrome/
- spankalee 8y agovanilla-js is really powerful! One incredible feature they don't even list yet is Web Components.
- dzonga 8y agoPreach! 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.
- starbuzz 8y agoHyperapp 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.
- wolco 8y agoDoes it work in ie9?
- starbuzz 8y agoYes. Not IE8, though.
- curiousreacter 8y agoSide 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"}?
- kevmo314 8y agoIf 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.
- curiousreacter 8y agoWell, 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.
- RussianCow 8y agoIt 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).
- curiousreacter 8y ago
- czechdeveloper 8y agoI'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.
- starbuzz 8y agoThis is a crucial aspect of Hyperapp that often goes unnoticed because simply no one in their sane judgment expects it.
- no_wizard 8y agoThis looks pretty awesome! Inspired by hyperscript I assume? https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript 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/DocumentFragment 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
- dlbucci 8y agoI 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.
- starbuzz 8y agoHyperapp 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.
- coldcode 8y agoThis makes me almost want to write web code again - compared to things like React and Angular 1-2-3-4-5-6.
- gramstrong 8y agoJust curious what intrigues you about this framework in ways that React does not?
- lukejacksonn 8y agoAlso curious.. Wwat would you miss from React if you only used hyperapp?
- starbuzz 8y agoHyperapp 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.
- agentultra 8y ago> Hyperapp is Elm for the rest of us. Curious who you think Elm is for?
- starbuzz 8y agoElm is for anyone. I love Elm. "for the rest of us" is a common English language idiom/phrase. https://english.stackexchange.com/questions/41687/meaning-of-the-phrase-for-the-rest-of-us https://english.stackexchange.com/questions/41687/meaning-of... 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.
- 8y ago
- deleted 8y ago[deleted]
- vtange 8y agoHow does this compare to Inferno, which you can also use JSX and Hyperscript with - https://github.com/infernojs/inferno https://github.com/infernojs/inferno This seems smaller in footprint, but does it also win in runtime performance and stability?
- Karupan 8y agoHyperapp can use JSX via the transform-react-jsx plugin.
- hellcow 8y agoThis 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.
- pault 8y agoJust out of curiosity, what was your use case that you deemed this a better option than react for?
- hellcow 8y agoWe 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.
- m0meni 8y agoWhy not Preact?
- hellcow 8y agoIt 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.
- starbuzz 8y agoBecause 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 https://github.com/NervJS/nerv for another React clone that is closer to React 16 (but still no fiber).
- Karupan 8y agoI 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.
- fouc 8y agoYou might be interested in this: https://github.com/pakx/the-mithril-diaries/wiki/Coming-From-Elm https://github.com/pakx/the-mithril-diaries/wiki/Coming-From...
- starbuzz 8y agoHyperapp will be a lot more Elm-like in a future release, see this too: https://github.com/hyperapp/hyperapp/issues/672 https://github.com/hyperapp/hyperapp/issues/672
- oron 8y agoThis is the best thing I discovered since leaving React. x10 dev speed for me, not to speak about loading times. Superb work!
- cpburns2009 8y agoWow, 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.
- starbuzz 8y agoMaybe there's simply nothing else to say.
- commandlinefan 8y agoThere 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.
- starbuzz 8y agoSurely there are many more ways.
- dang 8y agoThis 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 https://news.ycombinator.com/showhn.html.
- cpburns2009 8y agoUnderstood. I'll refrain from such comments in the future.
- dang 8y agoAppreciated!
- devmunchies 8y agoHow does this compare to Preact?
- starbuzz 8y agoI 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.
- c0brac0bra 8y agoI've really enjoyed using Hyperapp so far. Looking forward to building more with it.
- janci 8y agoDoes it work well with inputs? (text, checkboxes, radios, selects)
- ricardobeat 8y agoSeems so https://codepen.io/anon/pen/yjrydY?editors=0010 https://codepen.io/anon/pen/yjrydY?editors=0010
- madmaniak 8y agoAnother Virtual DOM thing - which is obviously wrong.
- czechdeveloper 8y agoCan you explain (or link some source) why is Virtual DOM wrong? Actually curious.
- lhorie 8y agoHi. 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.
- localvoid 8y ago> 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.
- dang 8y agoIt'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. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Be respectful. [...] Instead of "you're doing it wrong", suggest alternatives. [...] don't be gratuitously negative. https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html
- spankalee 8y agoIf 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 https://github.com/Polymer/lit-html Where JSX would look like this: const view = (state, actions) => ( <div> <h1>{state.count}</h1> <button onclick={() => actions.down(1)}>-</button> <button onclick={() => actions.up(1)}>+</button> </div> ) The lit-html would be: const view = (state, actions) => html` <div> <h1>{state.count}</h1> <button onclick={() => actions.down(1)}>-</button> <button onclick={() => actions.up(1)}>+</button> </div> `; Nearly identical. lit-html uses `<template>`s and cloning, so that it doesn't have to do any expensive VDOM diffs.
- malydok 8y agoThen 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?
- spankalee 8y agoIMO, 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.
- simplify 8y agoBut mixing and matching causes your page to bloat due to needing to download all the different libraries, right?
- seabrookmx 8y ago
- owlfarm 8y agoIt's not very performant compared to other v-doms https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...
- gandreani 8y agoWow kudos to the author! Very nice resource
- ricardobeat 8y agohyperhtml - which this is based on, similar API - can be found at the left end of the table.
- starbuzz 8y agoThis 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.
- bufferoverflow 8y agoIt's not old, it was last updated two days ago: https://github.com/krausest/js-framework-benchmark/commits/master/webdriver-ts-results/table.html https://github.com/krausest/js-framework-benchmark/commits/m...
- starbuzz 8y agoI meant the benchmark is using an older version of Hyperapp. https://github.com/krausest/js-framework-benchmark/tree/master/frameworks/hyperapp-v1.2.0-keyed 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 https://github.com/hyperapp/hyperapp/pull/663
- 8y ago
- mmanfrin 8y agoI got confused thinking this was a new thing from Zeit -- who made Next.js and Hyper.app (https://hyper.is/ https://hyper.is/)
- starbuzz 8y agoHyperTerminal
- gandreani 8y agoIn 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/ https://mithril.js.org/
- soapdog 8y agoJust want to second Mithril here. It is an awesome and refreshing approach. I love it too.
- starbuzz 8y agoOh, Mithril! All folk desired it. This one is great too.
- dsego 8y agoMithril is nice. One downside is it doesn't lend itself really well to compound components. Everything has to be passed down through attributes.
- davegauer 8y agoTrue, 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?
- dsego 8y agoThere 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 https://youtu.be/hEGg-3pIHlE
- elbear 8y ago
- mychael 8y agoWhy?
- ninjaturtles 8y agoI'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. https://hn.algolia.com/?query=hyperapp&sort=byPopularity&prefix&page=1&dateRange=all&type=story https://hn.algolia.com/?query=hyperapp&sort=byPopularity&pre...
- romanovcode 8y agoI 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).
- pygy_ 8y agoHyperApp has a great API, and for Web client code, size does matter.
- RussianCow 8y ago> 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.
- brlewis 8y agoIt isn't just on bad connections: https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e https://medium.com/dev-channel/the-cost-of-javascript-84009f...
- romanovcode 8y agoArticle has 300kb+ of javascript on mobile, loads pretty fast on 3G. I don't know what you're talking about.
- romanovcode 8y agoMobile google.com loads 200kb+ of javascript and I've never heard anyone complain about loading speeds for it.
- josephrluck 8y agoThis is amazing. Very similar to ideas I was exploring when building Helix (https://github.com/josephluck/helix https://github.com/josephluck/helix) however I went down the fully typesafe route, which is nice but the API isn't as clean as hyperapp. If it wasn't for reacts ecosystem, I'd consider using hyperapp for more projects.
- niksmac 8y agoIt looks more like Elm
- starbuzz 8y agoIf all goes according to plan, it will look even more like Elm in the next major release (2.0).
- supercarsw 8y agoanything is better than facebooks sandboxes
- sAbakumoff 8y agoSo far, the Infinite monkey theorem is just giving us an infinite number of javascript frameworks, and no Shakespeare
- Vinnl 8y agohttps://packages.gentoo.org/packages/dev-haskell/shakespeare-js https://packages.gentoo.org/packages/dev-haskell/shakespeare...
- starbuzz 8y ago> 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.
- sAbakumoff 8y agoTake it easy, it's just a joke that I post to every JS framework thread on HN:)
- kapv89 8y agoI'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)
- sAbakumoff 8y ago>>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.