181–190 of 198 posts
Just another transient DOM API abstraction library
Earlier quoted context omitted.
So...don't use CRA? You don't have to, although it does make a lot of things easier, and it's kind of a surprise to see the claim that Webpack encourages its use. I've never run across anything like that in the docs, and I have found those docs to do a good job of covering how to set up and use Webpack, with CRA nowhere involved. Or - a much easier tradeoff - just don't use Sass. I mean, Sass isn't without its merits…
> So...don't use CRA? Sure, I can get by fine without that, but then I've got to educate 2 other members of my team, both who can program in numerous languages but are quite inexperienced with web development, how to correctly set up each project using the React/Redux/Sass/Typescript/Jest. I can do it myself and hand them a project template, but then no-one else will learn how to do it. The reason for CRAs existence…
I would say that CRA's cognitive overhead, in a situation like that, isn't all that different from that of Rails, for example. They're both trying to do a very similar thing, albeit with very different approaches, and they're both very much of the convention-over-configuration school, which attempts to trade off not having to think very much at first about decisions you may not have enough information to make well, with making those decisions costlier later on once you do have enough knowledge to approach them. I have reservations about that entire school of thought, but despite them, my experiences with Rails and with CRA lead me to think that CRA does a generally much better job with those tradeoffs than Rails ever managed.
so.. a lighter react?
Just another transient DOM API abstraction library
Almost like the DOM Web API isn't useful for its intended purpose anymore and should be replaced or built upon to avoid all this abstraction churn. Why is simplicity the enemy of the Web APIs? Why is everything useful left to user-defined dependencies? Are the spec creators even checking to see what their code looks like when people have to cobble it together to create something useful? I suspect they are NOT.
Just another transient DOM API abstraction library
Earlier quoted context omitted.
We built it into the framework, if you happen to be familiar with Elm, this should make sense right away, but here's how you'd write something like that using Hyperapp: import { h, app } from "hyperapp" import { delay } from "@hyperapp/time" const Decrement = (state) => state - 1 app({ init: 0, view: (state) => h("div", {}, [ h("h1", {}, state), h("button", { onclick: (state/*, event*/) => [state, delay(100, Decremen…
I'm familiar with Elm but i think the model of Hyperapp is better than the [state command] pattern. This is how i see Hyperapp, the event part of Hyperapp is not about commands, it's about transition functions, functions that takes a before state and returns an after state. Hyperapp doesn't let the user to control the state by itself. But there is worst, the problem with the pattern [state command] is that it doesn't…
---
So, in Hyperapp there are no async/await functions. Or Promises. Can't use functions that create side effects. Can't use setTimeout, setInterval, new Promise, fetch, add/removeEventListener, etc.
delay(100, Action) looks familiar to setTimeout, but it's just a function that returns an object that tells Hyperapp what to do. It doesn't do anything by itself. You can write your own delay function too if you want as long as you give Hyperapp what it wants.
The state becoming stale is never an issue in Hyperapp, because you get a fresh copy of it inside actions, which is the only place where you can "update" the state.
[1]: https://codesandbox.io/s/hyperapp-minimal-counter-with-effec...
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..
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
but please keep the current didactic of piecemeal introduction of concepts, providing clear reasons for their existence!
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 )
To be fair, they did make a pretty deliberate effort to warn visitors that the website is incomplete, with some animated text: > this site is a wip, stay in touch!
Earlier quoted context omitted.
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.
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…
Earlier quoted context omitted.
Almost like the DOM Web API isn't useful for its intended purpose anymore and should be replaced or built upon to avoid all this abstraction churn. Why is simplicity the enemy of the Web APIs? Why is everything useful left to user-defined dependencies? Are the spec creators even checking to see what their code looks like when people have to cobble it together to create something useful? I suspect they are NOT.
Hyperapp only makes sense if you want to write immutable, purely functional SPAs in JavaScript. There's no Web API or native abstraction for that. And if your site was only content, then I'd say why even bother with JavaScript.
Maybe the Web should be reinvented, slightly at least. Maybe it would be a good thing if Web Assembly in conjunction with HTTP3 or something akin to it ate the whole beast, ecmascript and all.