I kinda feel like a traitor given my pretty long history with Vue and React, but I think I have a new go-to frontend framework. Hyperapp is everyt...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for the post!
I'm not really convinced by this framework. Sure, the syntax and all the sugar coming from the API is cool, but Elm provides some interesting things and I can't live without now.
The compiler, the error log is awesome and there are "no runtime exceptions".
Type system, a type system that really works (I like TypeScript but type system could be better, try to write a high-order function and see what happens ;-) )
Maybe, it seems that you don't like it a lot, but the possibility to have a program without
null
,void
,undefined
or things like that is really cool.Typescipt!
Read bit.ly/typescriptTax
Types only contribute to a minority of potential bugs.
Types are not just for fixing potential bugs (well, not only for that). They provide a better developer experience by providing you with a way to structure your program with a "logical flow" based on the data/resource you use.
Having that let you write maintainable code with less headache and make refactoring easy (and let you be more confident about the code you write) which lead to fewer bugs non-related to types but more to the logic behind the program.
I think that JavaScript users (like Eric Elliot) don't like strict types system because of TypeScript. It provides a really poor integration with non-TS libraries and its error messages are sometimes really cryptic.
You should give a try to Elm, at least it can be fun. :)
Thanks for the great writeup! Definitely going to look into Hyperapp for basically the exact reasons you mentioned.
You mentioned Elm a lot in this post, and for obvious reasons. Right now, Elm occupies my "favorite frontend framework" spot (which may have a lot to do with my love of Elm's typing). What about Hyperapp do you find easier to work with than Elm? Just syntax familiarity, or is there some other clutch workflow feature missing from Elm?
Thanks again. Big fan of your work!
I think the syntax for sure -- Elm is a big jump because you need to learn the syntax, architecture, and functional programming. The barrier to entry is lower here. Also, since its just JavaScript, it's easier to work with libraries natively than in Elm. I also kind of disliked working with the data structures (i.e. linked lists are more fully featured than arrays) and Maybe's in Elm -- maybe that's just me though. I think if you added TypeScript or Flow into Hyperapp, you would get a pretty similar experience to Elm!
Hi Ali, that's an excellent article, thanks.
I wonder what exactly you had in mind by "it's not as production ready as the aforementioned frameworks"? What did you feel is missing?
As far as I can tell it's excellent quality, has 100% code coverage and as it's small I could probably maintain it as if I had written it myself, though there is a community to help me. I saw the docs just got a major refresh which helps a lot.
Perhaps you meant the wider ecosystem of support and tooling is small? I discovered it is possible to use it with Create React App, a bastion of production readiness :). Also Visual studio and Browser F12 tools are excellent for debugging. Being small also I can pretty easily integrate almost any package I might want to without fighting with it.
I started using HyperApp around a year ago, when its API was still heavily changing. I even created a small project with it and it was fun! There once were 'events' that you could use for a subscription mechanism. Now I think you can use the state-bound actions returned by the app function. See github.com/hyperapp/hyperapp/blob/...
As interesting as this is, for a small application like the one you describe in this post, I don't understand the seemingly obsessive necessity to use a framework like this.
I would like to understand why you prefer this over less than half the amount of vanilla code needed to produce identical functionality. Couldn't find a post by you yet talking about this.
Would you be so kind to provide insight?
edit: not necessarily obsessive by you, but by people in general.
for an application like this, probably not much of an advantage. But once you start adding complexity, muyltiple views, etc., the benefits of predictable state management, automatic rerendering on state change, and component-based architecture become extremely valuable. I don't think the point of this page is to be a tutorial on the best way to build a quote-fetching app, it is meant to be an introduction to hyperapp using a quote-fetching app as a simple, easy-to-understand entry point
I have been following the series of learning new things, and I learned some things along the way, so thanks for sharing. Now that you are in the functional programming, do you have thought about try elixir lang? I would like to read your opinions about it. I am currently moving with javascript, but I espect to use elixir in the future. (I'm learning English too Β―_(γ)_/Β― )
I haven't done a ton of experience with functional languages! I have more experience implementing functional paradigms in non-functional languages. I looked into Elixir a bit -- Phoenix looks a ton like Rails to me which is fascinating! Maybe I'll try!
I didn't know about Hyperapp. Thanks for sharing, I like its API.
That's really interesting Ali Spittel. You have put great efforts!! Great.