121–130 of 198 posts
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 niché 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 )
Is niché a portmanteau of niche and cliché?
What are the difference with Mithril.js? Both seems to embrace the same philosophy in almost the same way. Or am I missing something?
Earlier quoted context omitted.
Going back to PHP and ASP you mean.
With thing like GraphQL, I get a definite ColdFusion vibe, too.
How does this compare to Stimulus?
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.
To me every JavaScript framework feels to me like it wants to reason about components as data, ala Hiccup: https://reagent-project.github.io/
Earlier quoted context omitted.
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.
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), t…
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.
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. Hypera…
React was made in 2013 and is pretty old at this point. How does Hyperapp compare to current tech like Svelte?
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 a…
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.
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.
Earlier quoted context omitted.
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.
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…
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.