Skip to content

Latest commit

 

History

History
98 lines (73 loc) · 5.19 KB

ch16.md

File metadata and controls

98 lines (73 loc) · 5.19 KB
Raw

Chapter 16: Less is more

Dissecting elevator pitch

You started this book with the elevator pitch:

For JS developers. 
Who need to build highly interactive Web interfaces  
Hyperapp is a functional view and state management framework
That allows for writing easy to understand, performant and testable code
Unlike other JS frameworks
Hyperapp fits in one 422 LOC file with zero dependencies and facilitates programming in a tiny subset of JS "the very best parts".

To summarize everything you've learned, we'd like to expand on the elevator pitch and provide more details. Hyperapp has three main benefits:

  • teachability
  • performance
  • correctness

Teacheability

  • Tiny size: with some effort, you can understand the whole Hyperapp source code without being a core contributor. On the other hand, most other frameworks have tens/hundreds of thousands of lines of code. Even their contributors don't understand them completely. You are at the mercy of their documentation and people finding time to solve your problems. With Hyperapp, you just look at the code.
  • Tiny API surface area: only five core concepts to learn. State, views, actions, effects, and subscriptions. The last 4 are just functions.
  • Small subset of JS: pure functions and object literals powered by the Elm-inspired functional architecture. No need for this, new, or class. No need to extend framework components or annotate code with @Component annotations. Those things are like dandruff on your application code. Also, no need for hooks and special linting rules. No nonstandard JS extensions. Just VanillaJS™
  • ESM native: you can use Hyperapp directly in the newest browser without any extra tooling.
  • Transferable skills: Hyperapp uses standard core DOM Events API. The onlick, oninput, or event.target.value are what you learned ten years ago. Even if you're learning it now, there will be many more resources to learn from than any trendy framework can provide.

Performance

  • Fast load time: with one file and zero dependencies Hyperapp loads fast by default (less than 2 kB). You don't need sophisticated performance tricks to load faster.
  • No compromise in runtime performance. See benchmarks like https://krausest.github.io/js-framework-benchmark/current.html. You may be surprised how fast Hyperapp VDOM is.

Correctness

  • Easy to unit test: everything is a pure function. Pass the input, verify the output.
  • Side effects at the edges: framework executes side effects. Your code is only pure functions.
  • Centralized immutable state: easy to track state transitions from the old state to the new state.

Comparison to other technologies

You may be wondering how Hyperapp compares to other frontend solutions. Below you'll find our subjective comparison.

Mateusz's choice of technology is filtered through those principles:

  • Understand things from principles.
  • Understand one layer of abstraction below my regular abstraction.
  • Compose solutions from simple tools solving narrow problems, aka Unix Philosophy.
  • Prioritize tools that give me fast feedback (fast build, rapid subsecond tests, etc.).

Kris's choice of technology:

  • Avoid magic, because it always stops working at the worst times.
  • Fast feedback loop is essential because I'm not working or learning when I'm waiting for the tool.
  • Write as many pure functions as possible, because they make life easier.
  • Practical. It should be a stable base with the community to bake it up.

If your principles are different, probably you'd make different choices.

Elm

Type-Driven Development in Elm makes for helpful and beginner-friendly development experience. Compiler taking care of runtime exceptions is very helpful. Refactoring is much easier than in the JS/TS world. The tradeoff is that Elm needs build tools in development. You can't use a browser as your REPL. Also, some APIs that haven't been ported to Elm are harder to work with than in JS. Finally, due to limited support for generics and a lack of higher-kinded types, some duplication is necessary. For some people, it's a bug. For others, it's a feature.

React

Because of the code size, you can't understand it at the source code level. It has many parts, and you either use them all (classes, lifecycle methods, hooks, context, etc.) and have a problem of your app getting complex or make your users load library code you don't even use. In practice to compare React to Hyperapp, you would need to add a state management library like Redux, which makes it even more complicated.

Preact

Smaller than React. You can read the source and understand it. But it has many parts you won't need (like React). Requires extra libraries to emulate functional architecture.

Angular

The opposite approach from Hyperapp. Way too big to understand at the source code level. Layers upon layers of abstraction. Too OO centric and too magical. Too far away from the browser to our taste.

Vue

Uses language features we tend to avoid (new, classes, this). Too big to understand at the source code level.

Svelte

It uses a great idea of code shrinking at runtime. But it's not JS, but a compiler from a JS superset. If you want dead code elimination and you're okay with a compiler, we'd go for Elm.