[HN Gopher] Hyperapp - A tiny framework for building web interfaces
___________________________________________________________________
Hyperapp - A tiny framework for building web interfaces
Author : Al0neStar
Score : 344 points
Date : 2020-06-30 10:56 UTC (12 hours ago)
(HTM) web link (hyperapp.dev)
(TXT) w3m dump (hyperapp.dev)
| jczhang wrote:
| so.. a lighter react?
| ancarda wrote:
| Just shows a blank page without JavaScript. Does Hyperapp have
| any way to render out an HTML fallback if JS doesn't load?
| jorgebucaran wrote:
| That's an issue with the site that'll be fixed when Hyperapp is
| officially released.
| ehutch79 wrote:
| This page does not inspire confidence in the framework.
|
| I don't need a non-ui piece of software to have the slickest
| site... but no lorem ipsum please.
| jorgebucaran wrote:
| I put it there, so I apologize for it. We were in the middle of
| a rewrite while working towards the official V2 release and
| weren't expecting to be on HN right now haha. Thanks for
| chipping in!
| recursive wrote:
| I wish people would stop demonstrating new languages or
| frameworks using fonts with ligatures.
|
| "Surely, you couldn't use an actual arrow here... right?"
|
| I find myself having to copy and paste the text to find out for
| sure.
| mrozbarry wrote:
| Bit of a Hyperapp fanboy here, so bare with me.
|
| First, I think Hyperapp can make both small and big applications,
| opposed to u/PufPufPuf's opinion. A lot of people have this
| opinion because they are more familiar with v1's wired-in
| actions, which can become quite unruly. In the latest version,
| actions are decoupled, and can be organized/extracted however you
| see fit.
|
| I've made a handful of applications in both v1 and the current
| released Hyperapp, and they work very well. If you want to see
| the latest Hyperapp in action, you can check these out:
|
| - A timer for mob programming:
| https://github.com/mrozbarry/mobtime
|
| - A canvas game, using Hyperapp for dom/state:
| https://github.com/mrozbarry/smash
|
| - A router for Hyperapp: https://github.com/mrozbarry/hyperapp-
| router
|
| I have a handful of older youtube videos regarding v1, you can
| check them out here:
|
| - Intro to Hyperapp (v1): https://youtu.be/uWIyjI8nkz0
|
| - Hyperapp (v1) forms and localstorage:
| https://youtu.be/qpt6aaMxm1E
|
| - Unit testing hyperapps (v1): https://youtu.be/5wvPUj--HaA
|
| Note, they are outdated, but there isn't much on youtube about
| Hyperapp in general.
|
| One thing to keep in mind is the naming. A lot of people talk
| about "Hyperapp" as the first version, and "v2" as the current
| version, but this is wrong. It's more like "v1" (legacy) and
| "Hyperapp" (current). It gets confusing, because not everyone is
| on the same page with that, but this the the naming Jorge
| (primary author/creator of Hyperapp) has mentioned several times.
| carapace wrote:
| ( s/bare/bear/ )
| mrozbarry wrote:
| You are absolutely correct!
| franciscop wrote:
| > "A lot of people have this opinion because they are more
| familiar with v1's wired-in actions, which can become quite
| unruly."
|
| u/PufPufPuf only mentions the lack of ecosystem, nothing about
| the wired-in actions/etc, so it's odd that you defend v1 vs v2
| instead of the lack of ecosystem here. This should probably
| have been a reply to that thread as well because otherwise it's
| two very unrelated comments in the list.
| shroom wrote:
| Dang, I registered hyperapp domain because I thought it was a
| good name and wanted to build something cool there. Like all side
| projects it's not about the idea but the execution. I'll put this
| in my bin together with slackday (Should have registered slack:)
|
| On topic: This looks interesting and I Will be giving it a try.
| Well done!
| jorgebucaran wrote:
| Do you happen to own hyper.app?
| oweiler wrote:
| I love hyperapp! It has very few concepts to learn, and the
| source code is less than 500 lines. Sadly its ecosystem is non-
| existant.
| queuep wrote:
| Haven't been using react because of the JSX, but is this really
| where we are heading? https://hyperapp.dev/tutorial#rendering-to-
| the-dom
|
| Looks like som obfuscated JS-code..
| riquito wrote:
| htm [1], mentioned in the paragraph that you linked, is a very
| clever alternative, similar to jsx but in pure javascript
|
| [1] https://github.com/developit/htm
| runawaybottle wrote:
| JSX evaluates to code that looks like that anyway. Not sure why
| we'd want to go backward on this front.
| ollysb wrote:
| Elm defines separate functions for each element type which in
| js would look like view: () => div({id:
| "app", class: "container"}, [ div({class: "filter"},
| [ " Filter: ", span({class: "filter-word"},
| "ocean"), button({}, "\u270E") ]),
|
| I'm admittedly used to this from years using Elm but to my eye
| I'd far rather use this than JSX.
| jorgebucaran wrote:
| 100% agree, that's exactly what @hyperapp/html package
| attempts:
|
| - https://www.npmjs.com/package/@hyperapp/html
| deergomoo wrote:
| Wasn't the unwieldiness of render functions the entire reason
| JSX was created?
| michaelcampbell wrote:
| Not sure of the reason, but it's a godsend comparatively. The
| reaction against JSX I find to be largely by people who've
| never actually used it.
|
| If you keep your components small, as is best practice,
| whatever gut reaction one feels to it (which IMO is misplaced
| to begin with) is minimized, and quite readable.
| onetom wrote:
| ah, and the article also mentioned
| https://github.com/developit/htm which pretty much provides
| what JSX does, just in a lot less complex way (at the cost
| of a little run-time)
| jorgebucaran wrote:
| If you like htm, check https://github.com/zaceno/hyperlit
| too
| gnud wrote:
| My big issue with JSX is that it forces you to use a pre-
| processor and source maps.
|
| If you have to do that anyway, I think I could use JSX
| instead of "pure" JS.
| enobrev wrote:
| The _only_ reason I use webpack and friends are for JSX
| and Typescript. For me, those two tools are worth the
| compilation step. Qs soon as it's possible to stop using
| compilers while still enjoying the benefits of both, I'll
| dump them from all my codebases.
| throwanem wrote:
| Setting up Webpack and Babel isn't so bad, these days,
| and you really only have to do it one time and then you
| can reuse the setup in other projects.
|
| Plus, once you've done it, Typescript is easy to slot in,
| and that by itself makes the effort worthwhile.
| onetom wrote:
| I can highly recommend you watching this talk:
| https://github.com/matthiasn/talk-
| transcripts/blob/master/Hi...
|
| It explains very well why is something being easy
| shouldn't be the main metric, when choosing some
| technology.
|
| In this case you are advocating to pull in webpack (28MB,
| 348 packages from 210 contributors), @babel/core (12MB,
| 54 packages from 60 contributors), typescript (53MB, 11
| packages, 4 contributors), to just mention the most
| obvious and necessary dependencies, not even mentioning
| the different plugins for integrating them with each
| other, test frameworks, linters, IDEs (syntax
| highlighting and auto-formatting) and of course the
| mountains of type definition boiler-plate.
|
| 100MB+ of dependencies which are all a responsibility to
| learn, teach, configure and upgrade.
|
| Versus this ~12000 bytes: https://unpkg.com/hyperapp
|
| It's like 6 pages of code on a 2K iMac monitor and none
| of the above...
|
| I'm not saying that there are circumstances when you
| might want to put up with all that cost, but have you
| consciously considered, whether it really worth the
| overhead? What's missing from hyperapp, which is only
| present in the 100MB+ deps? Maybe `htm` (1MB, 11
| packages, 4 contributors) is a better compromise between
| bloat and ease of development?
|
| And if you are willing to take on the extra dependencies,
| wouldn't ClojureScript provide a lot lot lot more
| benefits? It's also based on the super mature Google
| Closure Compiler, which supports extremely sophisticated
| optimization techniques and DCE... Just to mention some
| recent optimization surprise:
| https://twitter.com/roman01la/status/1277148232276234240
| throwanem wrote:
| > [...] have you consciously considered, whether [it's]
| really worth the overhead?
|
| Yes, I have. The overhead of a React/TS stack is
| considerably less than the overhead of having to hand-
| build all the stuff that Hyperapp's 12 kilobytes aren't
| enough to provide, or that using ClojureScript means very
| few other engineers will want to work with me to build
| because I'm doing everything in a language and stack
| they've never heard of.
|
| > What's missing from hyperapp, which is only present in
| the 100MB+ deps?
|
| Eleven years! Hyperapp is written in pure ES5, which was
| finalized in 2009, around the same time PHP 5.3 came out.
| The world has moved on a great deal since then. (But hey,
| I haven't had to think about hoisting for like six years
| now, so that was a fun blast from the past!)
|
| That said, those 12 kilobytes of ES5 code are very
| concise, for sure. They also implement a virtual DOM and
| a sugar syntax over element creation and _nothing else_.
| To compare it based purely on codebase size, with a stack
| that provides orders of magnitude more functionality,
| seems at best very incompletely thought through, and at
| worst deliberately tendentious - although I 'm sure that
| can't be the case.
|
| There's a lot of misinformation floating around about the
| modern Javascript world. A lot of that dates from years
| back, like the left-pad problem, or that builds aren't
| reproducible - both of which were true at one time, but
| have long since ceased to be. Or that using these tools
| makes it impossible to deliver compact, performant code
| to the frontend - which, again, hasn't been true in quite
| a while. It's not false to say that webpage bloat is
| worse than it ever has been, but it _is_ false to blame
| the tools for that problem.
|
| Of course, I freely grant that it's hard to see these
| kinds of nuances if you don't have much or any context on
| what modern Javascript is actually like. What I _don 't_
| grant is that that ignorance is any kind of worthwhile
| place from which to pass sweeping comments on the whole
| field of endeavor.
| com2kid wrote:
| If you are doing back compat for old browsers, Babel is
| necessary anyway.
|
| Typescript is a choice independent from anything else.
|
| There are alternatives to Webpack, none of which have
| gained traction, possibly because developers appreciate
| other features that webpack provides out of the box.
|
| But, you are complaining about the developer tools, why?
| The source code size of emacs/vscode/vi is just as
| relevant, or the size of the linter, or the complexity of
| whatever build environment is used to deploy code to
| production.
|
| All of those require upgrading and maintenance, and
| occasionally have bugs!
| onetom wrote:
| If you keep your components small, then using this `h`
| function instead of JSX doesn't make a lot of difference
| from readability perspective.
|
| Also, don't forget that `h` is just a function, so nothing
| prevents you from creating your convenience functions,
| which allow more concise/readable code, eg:
|
| const div = (...args) => h("div", ...args) const span =
| (...args) => h("span", ...args)
|
| (or something along those lines)
|
| I've experimented with this approach before (in
| ClojureScript) and you can get pretty far with it:
|
| https://github.com/enumatech/cljs-abi-viewer/blob/state-
| chan...
|
| In fact the Hoplon (https://hoplon.io/) framework as
| already doing this many years ago, even just using the DOM
| directly.
| throwanem wrote:
| The same is true of JSX. You can abstract and generalize
| its components with equal ease.
|
| I agree with another commenter that a lot of the common
| objections to JSX and React more generally, especially on
| HN, sound like things that people who've never used it
| but only seen a few examples would say.
|
| It's a shame, because with a little more experience those
| people could complain about stuff like how the complex
| form logic story in React just isn't really there yet, or
| how you can't really provide a lot of the subtle touches
| that go into making a really polished form UX without
| having to wrap an uncontrolled component inside a
| controlled one and handle all the state interactions
| manually.
|
| Forms are boring, I know, and everybody hates it when
| they have to be complicated. But they exist and are used
| for a reason, and I wish someone with fewer deadlines
| than I have right now would take the time to really nail
| down some of this stuff.
| keb_ wrote:
| I personally never found much inherent value to JSX
| outside of making it easier to onboard other developers
| who are already familiar with HTML, or have seen React
| before. Otherwise, I found Hyperscript easy to read after
| about a day of using it, and there's no extra toolchain
| or compile-step required to use it. Plus it's "just
| JavaScript."
| throwanem wrote:
| I do rather like JSX, but I agree Hyperscript isn't
| difficult to read. As I noted in another comment, though,
| it also isn't difficult to set up a build step, and being
| able to use JSX is far from the only benefit of doing so.
|
| The point about onboarding deserves more consideration
| than it receives, too. I'd have an easier time finding
| good devs to work on a React/JSX project than one in
| Hyperapp, just because of the latter being unusual.
|
| The syntax isn't so much at issue here; Hyperscript could
| as well be sugar over React.createElement calls, just as
| JSX is. Anyone familiar with the DOM can look at it and
| see what it's doing quickly enough.
|
| What would concern me more would be the underpinnings;
| Hyperapp brings its own VDOM and ancillaries, parallel to
| React's, that anyone wishing to work on a Hyperapp
| project needs to learn to reason about - and that will
| have their own bugs, infelicities, and performance
| issues, just as React's does. But React's are generally
| very well known and not too hard to design around, even
| if actually designing around them can be a pain on
| occasion.
|
| No shade on the team, and I'm not trying to turn anyone
| off the project - I used to be much more of an early
| adopter until I got badly burned that way a few times,
| and these are the sorts of considerations that result
| from that kind of experience. I'll definitely be
| interested to see how Hyperapp holds up, and what kind of
| profile it achieves, over the next year or so.
| [deleted]
| tobr wrote:
| > obfuscated
|
| I've heard this reaction before when people see hyperscript-
| like APIs. I don't understand it. Isn't it abundantly clear
| what is going on if you know DOM and JS? What is your
| suggestion if you don't like hyperscript and don't like JSX?
| Parsing string templates at run-time?
| jorgebucaran wrote:
| Thank you! This is exactly the kind of feedback that we need to
| improve our presentation. I might just update the tutorial to
| use @hyperapp/html [1] instead.
|
| [1]: https://www.npmjs.com/package/@hyperapp/html
| hellcow wrote:
| Please don't. Not everyone uses these additional libraries or
| preprocessors, and it was a big hurdle to figure out what was
| actually being generated behind the scenes in the v1 docs.
|
| A good approach is to show us what we need to do with no
| other dependencies (i.e. just as you're doing now with this
| h() function), and link to alternative syntaxes/libraries
| that may be optionally used instead.
| jorgebucaran wrote:
| Thank you for the feedback. I'll keep this in mind too. I'm
| definitely not advocating JSX usage. I favor hyperscript
| myself, but I understand it's an acquired taste.
|
| Idiomatic JavaScript alternatives that don't involve
| compilation include:
|
| - https://github.com/zaceno/hyperlit, and the
| aforementioned -
| https://www.npmjs.com/package/@hyperapp/html
| tobr wrote:
| A nice flourish would be to have every example with both, and
| have a global switch to pick which one you prefer.
| scrump3y wrote:
| that is pretty much how React looks like after JSX is compiled
| to "pure" Javascript.
| lf-non wrote:
| Haha, I have spent my fair share of time procrastinating over
| what a type-safe JSX alternative would look like for React.
|
| The most ergonomic solution (well, atleast for me) has been
| their old factory API upon which I layered a set of convenience
| utilities [1]. I have been trying it out in a hobby project and
| I find the reduction of className boilerplate, elimination of
| closing tags etc. quite productive. And unlike alternatives
| like react-pug etc. I don't have to compromise with type
| checking of attributes.
|
| I'll probably release it as a library after doing some
| performance evaluation and if needed, wrapping it in a babel-
| macro [2] that eliminates the runtime overhead.
|
| --
|
| [1] Example in CodeSandbox: https://codesandbox.io/s/pedantic-
| shape-lq9q9?file=/src/reac...
|
| Code in github gist:
| https://gist.github.com/lorefnon/53377e4d6a6b13adbcfa155f486...
|
| [2] https://github.com/kentcdodds/babel-plugin-macros
| raziel2p wrote:
| Mithril was doing this exact thing before React became big -
| it's what we're moving away from (with JSX), not where we're
| heading.
| keb_ wrote:
| Many projects still predominantly use Hyperscript with the
| option to use JSX (including Mithril and Hyperapp, and others
| like RE:DOM, snabbdom to name a few). Even React has an
| option to use it if you want to skip the JSX compile-step. So
| I wouldn't say we're necessarily moving away from it.
|
| Personally, I prefer Hyperscript. It took maybe a day for me
| to get over its perceived ugliness and actually appreciate
| that it's plain, valid JavaScript.
| lhorie wrote:
| I wouldn't necessarily say we're moving one way or another.
| React technically released before Mithril. It just so happens
| React became more popular and JSX is idiomatic in React. But
| hyperscript is usually compatible w/ JSX (in fact, in Mithril
| you can choose whether you want to use JSX or hyperscript)
|
| Personally, I think indentation w/ hyperscript tends to look
| more natural for large sets of props, e.g.
| h('div', { id: 'hello', title: 'hello'
| onclick: () => { console.log('hello')
| }, }, [ // hi 'hello' ])
| // vs <div id="hello"
| title="hello" onclick={() => {
| console.log('hello') }} >
| {/*hi*/} hello </div>
|
| With Mithril's variety of hyperscript in particular there are
| also some other neat features, such as the ability to pass
| css selectors as the first argument, e.g.
| `h('input[type=password].password')` or `const
| TailwindComponent = '.rounded-lg.md:w-56'; const element =
| <TailwindComponent />`.
| pjmlp wrote:
| Going back to PHP and ASP you mean.
| marcosdumay wrote:
| Text templates are the technology for web development. They
| are so much better than anything else that there's no
| comparison.
|
| There are some bad templates implementation, and some good
| ones. The original PHP and ASP are bad. But that doesn't
| mean templates are bad.
| pjmlp wrote:
| Text templates are a good idea, placing them into the
| middle of JavaScript code, not really.
| enobrev wrote:
| I absolutely disagree, but I also feel it's unfortunate
| that HTML, CSS, and SQL aren't first-class citizens in
| most languages. It's strange to treat things backed by
| entire standards bodies and with fully developed ASTs as
| plain-text.
|
| It seems unnecessarily limiting, and I'm not sure why;
| For the sake of history? "Division of Concerns"? How is
| it that using libraries meant for string manipulation
| upon a standardized format not a concern in and of
| itself?
|
| The reason JSX, Mithril, PHP's template tags, ASP,
| Mustache, Twig, etc, exist is because we want to generate
| HTML - a language that has been standardized for decades
| - so why are we still playing around with string
| manipulation tools?
| marcosdumay wrote:
| It's an evolutionary constraint. Text templates are
| initially much more useful than HTML and CSS ones, so
| people adopt the first, despite a bigger potential
| usefulness of the later.
|
| The tendency for SQL is even weirder, it's for replacing
| it with languages that are much less useful for querying
| data.
| pjmlp wrote:
| We aren't, only those that keep fighting against MVC,
| HTML Templates and Web Components are.
| marcosdumay wrote:
| I do agree with that. But on the case of JSX, it is
| _located_ inside JS code, but is completely self-
| contained, thus, it 's not as bad.
|
| The original PHP and ASP are really singular beasts,
| people aren't creating things like those anymore.
| cy_hauser wrote:
| What do you consider some of the good ones?
| lyjackal wrote:
| *improving on PHP and ASP
| jrwr wrote:
| Hay! There is some power in being able to bang out a page
| with <h1>Hello <?php echo "World"; ?></h1>
| pjmlp wrote:
| Agreed, the problem is when that page gets to a book
| size.
| cercatrova wrote:
| That's why there are components that you put together, so
| that no one component is very large.
| mhd wrote:
| With thing like GraphQL, I get a definite ColdFusion vibe,
| too.
| runawaybottle wrote:
| We are definitely in ColdFusion territory:
|
| https://github.com/seancoyne/awesome-
| coldfusion#application-...
| bdcravens wrote:
| Worth noting that ColdFusion actually did components
| before it was cool :-) (I don't mean ColdFusion
| components which are really just classes in .cfc files,
| but custom tags which let you write custom markup)
| <cf_menu position="left"> <cf_menu_item
| current="true" label="Home" url="/"/>
| <cf_menu_item label="Accounts" url="/accounts" />
| </cf_menu>
| [deleted]
| pjmlp wrote:
| If I ever need to render HTML from JavaScript, this is my
| solution, https://lit-html.polymer-project.org/ or tagged
| templates directly, although I rather prefer straight MVC
| separation, SSR/Angular/Vue style.
| historyremade wrote:
| Democracy in action. Nothing can beat Svelte!
| beders wrote:
| Someone got inspired by re-frame, I see :) I like the approach.
| Wondering if there's a way to get ever closer to hiccup (without
| having to resort to JSX)
|
| Also, letting the framework decide if a function inside the
| markup should be called or not gives opportunity for more
| optimizations that go beyond VDOM diffing. That would require an
| even more declarative approach.
|
| i.e. [h1, {}, [MyComponent, {}]]
|
| vs.
|
| h("h1", {}, MyComponent({}))
|
| If the framework figures out that MyComponent wasn't changed, it
| can re-use the VDOM nodes.
| jorgebucaran wrote:
| Yep, there's a feature called Lazy (will be renamed to memo for
| the official release) that allows you to do just that! :)
| nailer wrote:
| React was made in 2013 and is pretty old at this point. How does
| Hyperapp compare to current tech like Svelte?
| jorgebucaran wrote:
| This deserves a much better answer, but I'll just say this for
| now. Svelte is declarative/imperative (but mostly imperative)
| and also not based on functional principles. React is
| definitely more on the declarative side. And Hyperapp is
| essentially Elm in JavaScript, so it's as
| declarative/functional/immutable as the definition allows for.
|
| Maybe the person that said Svelte was more declarative was only
| familiar with an older incarnation of Hyperapp that wasn't
| completely based on functional principles, or maybe they're
| using a more loose but inaccurate definition of declarative
| (kind of like how people often say "theory" when they actually
| mean "hypothesis").
| RivieraKid wrote:
| What do you think the advantages and disadvantages are? I
| remember briefly looking into Hyperapp and mostly liking it,
| but still wasn't sure which JS framework is the best choice
| (the other one I liked was Vue).
|
| Some time after that I learned about Svelte and very quickly
| concluded that this would be my choice, everything just feels
| right about it. For the record, I've only done a small
| project in Svelte.
| jorgebucaran wrote:
| That's fine. If you're already happy with Svelte, I
| encourage you to explore more with it. Try building a
| couple of non-trivial projects and keep learning about your
| craft. If you're also into computer science, I recommend
| you look into functional programming if you haven't done so
| yet. Then look at Svelte again. Try React too. Check out
| Elm.
|
| I can tell you that Hyperapp is not for everyone. If you
| want to write pure, immutable, functional JavaScript and
| think hard about client side app architecture
| (unidirectional state management, controlled side effects,
| toggleable subscriptions), then you'll love it.
|
| If you are looking for a more accommodating, meet-in-the-
| middle kind of approach where you can mix programming
| styles, and don't want to think much about those things I
| mentioned above, then React, Vue, Svelte are all great
| choices.
|
| V2 will be released in a few months, so do circle back to
| Hyperapp then to see how you like it again.
| onetom wrote:
| Svelte is more declarative. Svelte is also a compiler, which
| generates very efficient code for keeping the dependent parts
| of the DOM up-to-date when the app state changes, effectively
| moving the vDOM diffing cost from runtime to compile-time.
| manx wrote:
| How is it 2x faster than react? Where does this claim come from?
| Lapz wrote:
| Haven't seen the numbers but in most benchmarks React.js isn't
| the quickest.
| keb_ wrote:
| Probably from here: https://krausest.github.io/js-framework-
| benchmark/current.ht...
|
| Hyperapp _does_ outperform React in most benchmarks (along with
| many other frameworks). Not sure how the "2x" was measured,
| though.
| DigitalSea wrote:
| A lot of other frameworks/libraries are faster than React. I
| know React used to be touted as the fastest option, but the
| reality is that it isn't.
| giancarlostoro wrote:
| At 1.7K I'm not surprised by this, and I'm not sure why you
| would be. React is plenty bloated, not saying it's badly coded,
| but it's a larger codebase than many other SPA frameworks. This
| one in particular seems to be using as much of native JS code
| as possible.
| RyanGoosling wrote:
| How much faster is vanilla DOM API calls compared to all other
| transient DOM API abstraction libraries?
| bshimmin wrote:
| In the tutorial it says: "In this tutorial we'll stick with `h`
| to keep it simple and close to the metal." I'm pretty sure they
| put that in there just to aggravate the HN crowd.
| stepstop wrote:
| Or it's a joke? Assume good intentions
| jorgebucaran wrote:
| There's a a JSX-like ttl for Hyperapp too, check it out:
|
| https://github.com/zaceno/hyperlit
| mrozbarry wrote:
| The `h` function isn't too bad to read if you keep
| small/manageable components. Obviously, any component, whether
| JSX or something else, with enough content in it, becomes quite
| hard to read.
|
| Personally, I like using `h` over JSX - JSX can be nice to
| read, but for people that don't know how it works behind the
| scenes, it makes things look like magic.
|
| Once you know how Hyperapp works behind the scenes, it's much
| easier to make the decision to JSX if that's something you care
| about when developing. I have the same opinion about React, and
| other libraries that have a strong preference to JSX over their
| native/function implementations.
| d0m wrote:
| I think they use "Close to the metal" as a way to say "Less
| abstractions"
| reaktivo wrote:
| You might find using htm with hyperapp useful:
| https://www.npmjs.com/package/htm
| wackget wrote:
| Does modern web development just completely abandon the idea of
| "separation of concerns"? Looks like content is freely mixed with
| markup and logic and results in a horrible, difficult-to-read
| mess of code.
| SPascareli13 wrote:
| The idea now is not to separate thing by file type (all .js go
| here, html goes there) but to separate by logical components,
| thing that work together, go together.
|
| I guess it's like working in vertical slices of related logic
| rather than layers with logic and layers with markup and such.
|
| That has its problems tho, that for sure.
| mrozbarry wrote:
| What code are you referring to? Hyperapp has clear separation
| of presentation, logic, and side-effects. Of course, developers
| can choose to keep that a clean and distinct separation, or let
| a bunch of code inter-mingle.
| Kiro wrote:
| There has never been any separation of concern in web
| development. Just because you put your scripts, HTML and CSS in
| different files doesn't mean they are separated.
| wackget wrote:
| Isn't that the definition of separated? If you want to edit
| content or markup, you open the HTML file. If you want to
| edit business logic, open PHP or JS. And so on.
| wes-k wrote:
| They are still tightly coupled.
| ng12 wrote:
| Yeah but then your JavaScript spews out unholy tendrils
| that mutate the DOM and dynamically add/remove CSS classes
| and style attributes. Separating HTML/CSS/JS made a lot of
| sense for web sites but separating by component makes more
| sense for web applications.
| disqard wrote:
| IMHO, yes. This is why some folks (like myself) find it hard to
| wholeheartedly embrace JS for building entire apps.
| wooolfgang wrote:
| Love the website aesthetic!
| Nijikokun wrote:
| Looks like mithril
| RyanGoosling wrote:
| Just another transient DOM API abstraction library
| PufPufPuf wrote:
| I have tried Hyperapp some time ago. It's usable for small apps,
| but the lack of ecosystem makes it unfit for anything larger --
| as is usual for all niche JS frameworks.
|
| Funnily, the "ecosystem" page contains just Lorem Ipsum
| (https://hyperapp.dev/ecosystem) and the Awesome Hyperapp section
| for V2 is almost empty (https://github.com/jorgebucaran/awesome-
| hyperapp)
| foobarbecue wrote:
| Is niche a portmanteau of niche and cliche?
| Uehreka wrote:
| It's pronounced "NEE-chuh".
| bigblind wrote:
| No, it's niche with a French accent
| sqrt17 wrote:
| Fun fact: niche is a French word that doesn't have an
| accent. So niche is the heavy metal umlaut version.
| slim wrote:
| niche with a french accent sounds like the "nish" in
| "varnish".
| pkghost wrote:
| Good content.
| HumblyTossed wrote:
| > but the lack of ecosystem makes it unfit for anything larger
|
| What does this mean?
| apozem wrote:
| Some problems are hard, common and already solved. Sometimes
| solving these problems yourself adds no unique value to your
| product. In that case, you should just use a well-reviewed
| external ecosystem package.
|
| A large project will run into many of these problems. It is a
| waste to re-invent the wheel because a cool new framework has
| too few pre-made wheels.
| sb8244 wrote:
| I interpret this as you need to do everything yourself rather
| than using off-the-shelf libraries.
| RobertKerans wrote:
| Lack of libraries, as sibling says. Any libraries that exist
| are not generally well supported relative to similar libs for
| popular frameworks. Much smaller community, much less ease at
| finding others who may have had similar issues. Fewer eyes
| on, fewer bugs picked up. Fewer contributors, slower
| fixes/updates. Docs there are tend to atrophy faster.
|
| Developed with Hyperapp on big prod apps about three years;
| was used to inject small amounts of interactive functionality
| into existing apps (.Net with jQuery powered frontends).
| Sorta worked, nice, simple idea, but docs almost nonexistent
| at the time (to be fair there's very little to it), was in
| process of being dumped for React just as I was leaving (to
| work on apps with Elm frontends, which Hyperapp takes a lot
| from, and suffers from similar issues, heh)
| HHalvi wrote:
| Their guide (https://hyperapp.dev/guides) page is also filled
| with Lorem Ipsum.
| jorgebucaran wrote:
| Ouch, yes, that's also a WIP, thank you for checking in,
| though.
| bigblind wrote:
| The quickstart is quite clear, but I'd love to see some
| slightly larger examples like, how is state passed between
| components? How do event handlers work? The API page seems
| sparse as well.
|
| But it looks like a great start
| jorgebucaran wrote:
| And you'll get it! Just check again soon as we should
| have the official release out there in just a few months,
| maybe less.
| ricardobeat wrote:
| It's been like that for months - seems like the project is not
| seeing the activity they expected for v2.
|
| Also server-side routing is broken and that link will not work.
| jorgebucaran wrote:
| We are very close to the official V2 release, but right now
| that page is still a WIP.
|
| The link works fine, though.
| vages wrote:
| The link does not work.
| jorgebucaran wrote:
| Any idea why? Any info you can share would help us debug
| whatever the issue is.
| european321 wrote:
| Missing a wildcard route? No idea how your routing is
| setup
| jorgebucaran wrote:
| It's all client-side. When I click that link, it opens
| the site as usual.
| shripadk wrote:
| Click the link directly: https://hyperapp.dev/ecosystem
|
| As the parent said, you don't have a catch-all route.
| That is why!
| jorgebucaran wrote:
| That's what it is, thank you for clarifying.
| [deleted]
| satyrnein wrote:
| Also, if you click "join us" and then "tutorial" your
| scroll position is in an unexpected place.
| dsissitka wrote:
| It's broken here too.
| jorgebucaran wrote:
| Do you know why?
| dsissitka wrote:
| Oooh, I see. It (https://hyperapp.dev/ecosystem) is
| broken if you've never been to https://hyperapp.dev
| before.
| jorgebucaran wrote:
| Ah, gotcha gotcha. Thank you for reporting it! :)
| cortesoft wrote:
| Yeah, I got a 404 page when visiting it, too.
| doctoboggan wrote:
| I am on macOS / Safari 13.2.1 and I can not visit
| hyperapp.dev/ecosystem after visiting hyperapp.dev
| jorgebucaran wrote:
| We're so close to the official V2 release, but there are still
| issues. I'll make sure to fix most by then. You totally have a
| point about the lack of an ecosystem, but building one is where
| the fun is. I am sure we'll get there! Thank you for your
| feedback.
| davydog187 wrote:
| Just use https://preactjs.com/ and call it a day
| k__ wrote:
| This.
|
| I like how HyperApp takes this to another level, but the
| ecosystem of Preact is simply better.
| schwartzworld wrote:
| there's a valuable comment if I ever saw one
| ggregoire wrote:
| What are the caveats? Why doesn't everybody use preact instead
| of react?
| afshinmeh wrote:
| I have built https://gridjs.io on top of Preact. It's pretty
| stable and the API is very nice. Supports most events/callbacks
| that React has (nothing against Hyperapp though)
| apolymath wrote:
| HTML should be created by WRITING HTML! WTF is your malfunction?
| Javascript should ALWAYS be as minimal as possible on your web
| page. We aren't building a native app! THIS IS THE WEB!!!!!
| pgt wrote:
| To me every JavaScript framework feels to me like it wants to
| reason about components as data, ala Hiccup: https://reagent-
| project.github.io/
| jorgebucaran wrote:
| Reagent is amazing, thank you for sharing it.
| [deleted]
| [deleted]
| dang wrote:
| If curious see also
|
| 2018 https://news.ycombinator.com/item?id=17126670
|
| 2017 https://news.ycombinator.com/item?id=15467819
|
| 2017 https://news.ycombinator.com/item?id=15264053
|
| 2017 https://news.ycombinator.com/item?id=15178535
|
| 2017 https://news.ycombinator.com/item?id=14629414
| [deleted]
| czechdeveloper wrote:
| I love it, but I actually stuck with version 1, which was way
| more intuitive for me.
|
| Just a side note, I'm not fulltime front-end, so keeping up with
| modern frameworks is out of my capacity.
|
| It's great for smart components to my standard multi-paged
| systems, but I used it even for small PWA applications.
| hellcow wrote:
| I resisted the change to v2 for a long time. In the end I found
| that v2's state management is much better, so it might be worth
| a look for that alone.
| czechdeveloper wrote:
| I read about it but it just did not click as V1 did. Also I
| will not rewrite old code just for sake of change and I want
| all system to be on same framework if possible. I may
| actually do my own fork where only difference will be passing
| root state and root actions in addition to partial ones,
| which will fix great amount of issues I have.
| hellcow wrote:
| Agreed.
|
| The lack of lifecycle events in v2 complicates things a
| great deal for seemingly no reason. Subscriptions and
| Events are similar enough that they could have become a
| single thing, instead of having two highly similar but not-
| quite-the-same things to grok. The tuple syntax it uses is
| very strange coming from v1.
|
| I wish I could call it a strict upgrade instead of saying
| "some things are worse, but other things are better."
| jorgebucaran wrote:
| It's my fault for not fully understanding the functional
| universe I was getting into when I first started working
| on Hyperapp. The latest Hyperapp is more strict, but it's
| all in good measure. Lifecycle events are impure, that's
| why they're no-good.
|
| I can tell you that Hyperapp is not for everyone. If you
| want to write pure, immutable, functional JavaScript and
| think hard about client side app architecture
| (unidirectional state management, controlled side
| effects, toggleable subscriptions), then you'll love it.
| I also suggest looking at Elm while you're at it.
|
| If you are looking for a more accommodating, meet-in-the-
| middle kind of approach where you can mix programming
| styles, you might be better served by, say, P/React.
| jorgebucaran wrote:
| I haven't done a great job at explaining why the current
| Hyperapp is superior than its previous incarnation, but V2
| isn't officially out yet, so I encourage you circle back to it
| when it is.
| Glaeqen wrote:
| It seems that scrolling is somewhat broken. Scroll position under
| one route affects position in others.
| drcongo wrote:
| That was enough to make me not consider using Hyperapp.
| jorgebucaran wrote:
| Yeah, the site is a WIP, but that should be fixed soon when
| V2 is officially out.
| loustak wrote:
| What are the difference with Mithril.js? Both seems to embrace
| the same philosophy in almost the same way. Or am I missing
| something?
| jorgebucaran wrote:
| They're similar, but Hyperapp is purely functional and more
| comparable to Elm.
| mr0010110fixit wrote:
| So I have extensively used hyperapp (1 and 2) for hybrid mobile
| applications that run the cab of big rigs. We actually won best
| in show this year at Freight Waves for our two apps.
|
| These are medium/larger apps, with lots of functionality, need to
| hook into native device features (done with ionic capacitor, and
| custom plugins), and need to be fast, robust, and flexible.
| Hyperapp has allowed all of those things.
|
| Hyperapp can and will work, with larger applications, but
| hyperapp does not have super strict "guide rails" like other more
| popular frameworks do, so its up to you to design, and implement
| a clean code base. It ships with minimum overhead, and you can
| either roll features you need, or see if someone in the community
| has created them.
|
| I have worked with angular (1,2,4,6) and react for quite a few
| projects, and I actually work faster, and end up with a better
| end product using hyperapp. Its an amazing little framework.
| Sure, not having stricter guide rails you can write very poor
| apps in hyperapp, it will let you do stuff poorly, but if you
| play to its strengths, and get comfortable with it, it really
| shines.
| keb_ wrote:
| Hey there, really happy to hear of the success you've had with
| Hyperapp. I've played with Hyperapp v1 in the past for small
| toy projects, and it was relatively easy to become productive
| with. I'm wondering if you have any open toy projects or
| boilerplate you could share for v2, as I'm looking to jump back
| on it when I get the chance, and would love to see what a
| scalable project skeleton looks like.
| mr0010110fixit wrote:
| I do not have anything that is open as of now (but about to
| start a new project soon)
|
| I would check out https://medium.com/hyperapp/a-walk-through-
| hyperapp-2-b1f642...
|
| to get your toes wet though, good resource, also feel fee to
| join the hyperapp slack https://hyperappjs.herokuapp.com/
| nice community and super helpful.
| draw_down wrote:
| "The frontend world is constantly churning, it's impossible to
| keep up! Anyway, here's a framework"
| bharani_m wrote:
| I've used this for building the browser extensions for my app
| [1].
|
| It is simple, easy to understand and easy to reason with.
| However, I would recommend this only for small apps. As soon as
| your app's features/complexity increases, you end up writing a
| lot of biolerplate code that libraries like Vue or Preact already
| handle you for.
|
| [1] https://www.emailthis.me
| shash7 wrote:
| Your open source browser extension framework was really helpful
| to me a few years ago!
| bharani_m wrote:
| Glad you found it useful.
|
| I had sort of neglected it for a while, but during the course
| of the lockdown, I have started working on a major rewrite -
| replacing Gulp with Webpack, adding support for Edge, etc.
| Will release it soon :)
| richeyryan wrote:
| I haven't used Hyper but I'm looking for something to use for a
| browser extension I'm making.
|
| I'd love to hear what kind of boilerplate you had to write that
| Vue or Preact handle. It can be hard to see these gaps ahead of
| time so I'd appreciate the benefit of your experience.
| jorgebucaran wrote:
| Curious to hear what boilerplate you think Vue or Preact
| already handles for you.
| joelbluminator wrote:
| How does this compare to Stimulus?
| jorgebucaran wrote:
| Stimulus is not so much concerned with rendering HTML. Hyperapp
| is almost exclusively focused on rendering HTML and client side
| application architecture (state management, controlled side
| effects, subscriptions).
|
| It's more comparable to Elm than React, Vue, Angular, Svelte,
| etc., since it's based on functional principles and you can
| only write pure, immutable code.
| ptu wrote:
| I'm a big re-frame fan from the Clojurescript world so this all
| looks rather familiar. For me it's a great framework and worth
| learning Clojurescript for.
|
| Seeing the h() function makes me realise how much I miss Hiccup
| syntax for HTML and your component tree, especially with editor
| support for parens it's a joy. But it looks nicer than JSX.
|
| I'm going to give Hyperapp a try, I like the small size aspect
| especially, and familiarity of the overall architecture, my fear
| is that if you're going off-piste enough to avoid the
| React/Angular well trodden track on an app, you might as well go
| the whole way and use Re-frame which is very pragmatic, with JS
| interop it's possible to do pretty much anything you want. And
| whilst the type system and compiler of Elm is nice, the slightly
| more 'infamous' parts of restrictions to JS extensions make it
| more limited in the real world.
| aabbcc1241 wrote:
| Now it looks like Elm
| jorgebucaran wrote:
| Exactly! And the latest version (which is not officially out
| yet) is even closer to Elm that the first version ever was.
| jhardy54 wrote:
| Blank page when JS is disabled. :/
| schwartzworld wrote:
| When last I checked, Hyperapp was basically the elm architecture
| implemented in JS, a gateway drug.
| k__ wrote:
| I had the impression it was the other way around.
|
| People starting with Elm, love the idea, but not the ecosystem,
| and come back to JS in the end.
|
| That's how Redux was created.
| Shish2k wrote:
| Been using this for a while and loving it - it feels like
| functional programming for GUIs ("describe what you want the end
| result to look like, and the framework makes it happen" as
| opposed to "describe what steps to execute").
|
| I'm pretty sure a lot of frameworks have similar mindsets, but
| Hyperapp is the one that I found works with the fewest headaches
| :P (as opposed to eg React, where I spent hours simply trying to
| untangle the knot of thousands of dependencies before I could get
| step 1 of the quickstart tutorial to compile...)
|
| As an example of how trivial problems require trivial code:
|
| https://github.com/shish/divetools2/blob/master/src/screens/...
|
| https://scuba.shish.io/#screen=MaxOperatingDepth
___________________________________________________________________
(page generated 2020-06-30 23:00 UTC)