HEX: a No Framework Approach to Building Modern Web Apps
--
React 16 is out! To celebrate, I wanted to see how close I could get to react with some raw HTML5, ES6 and CSS3 (HEC -aka #UseThePlatform). The result might surprise you.
I’ll never say it enough, React has introduced a major step forward in Front-End architecture when the view became a pure function of the model (aka Functional HTML). That being said, Facebook might need React, I get that, but the question I would like to explore in this post is: do you? Is it worth the time investing in learning a front-end framework as complex as React? is it worth the effort to bend your code to fit in a front-end framework (let’s be serious, react IS-NOT a library)?
Consider for instance that:
- React’s programming model has changed substantially over the past couple of years
- the React team can’t let go of its stateful model and commit to Redux as the default state management solution (the new http://reactjs.org has virtually no reference to redux)
- In addition to Redux, there are today a gazillion libraries that you need to choose from to actually build a react application. A React component alone will not “make it painless to create interactive UIs”, that is a lie. You don’t believe me? just take a look at the kind of stuff you need to think about when writing a React app, and that’s just the beginning. Still not convinced? just take a look at this tweetstorm, from Michel Weststrate, one of the foremost React experts.
In this post, I would like to show that HEC can be used for a good 80% of the apps we build (and possibly even more).
Why would you want to do that? how about:
- Zero learning curve beyond HEC (Skills you might already have)
- Your code won’t be trapped in a nebula of libraries, that’s growing by the day
- It will be much smaller and easier to reason about
- Your code will be 100% isomorphic by construction
- You could still use some cool JQuery components like DatePickers or DataTables
- There will be no evolution issue, you’ll be able to continue coding your projects in ES7/8, HTML6, CSS4… when the time comes
- and no licensing issues of course
So what do you need to make it easy to build interactive UI? It turns out not much: Components, Virtual-DOM, State Management, Security
Components
I would like to demonstrate that Components are easy to build and compose with HEC alone, thanks in part to ES6 template literals, which are just as convenient as JSX. I will use the code samples featured on reactjs.org.
Let’s start with a stateless component, it couldn’t be simpler:
Compare that to a stateless React component (please note that a single enclosing element such as <div> is no longer needed in React 16):
Pretty close! But what about stateful components? In my projects, I exclusively use stateless components in conjunction with a single state tree architecture. Hence, I would not recommend using a stateful component, but if you absolutely have to, here the corresponding implementation of the React Timer (again, pretty close):
Template literals compose well, of course, here is the corresponding Todo React Sample (as a stateful component):
I was attracted to JSX at first, but very quickly you realize that using a Tag notation to specify a function call doesn’t add much value, it’s quite inflexible actually. When you add on top the idiosyncrasies of JSX (down to camel case), the learning curve, and its limitations compared to the full access to HEC, there are not a lot of reasons left to use it.
Last question, how do you render these components? Less than 20 lines of Javascript will give you a react-like API
The whole code is below, a React-like library that implements Stateless and Stateful components, including composition, in less than 20 lines of Javascript (the code is available in CodePen.io in the embedded window below):
Virtual-DOM
React introduced the concept of virtual-dom which combined with functional HTML removed the need for direct DOM manipulations. Again, the question is do you really need it? I don’t believe so: I generally divide my projects in three sections (header, content, and footer) which are rendered independently. If you feel the need to render some subsections of the content independently, I wrote these 20 lines of Javascript that “hash” the different sections and render only the ones that changed.
UPDATE: Since I wrote this post, Google (Justin Fagnani) has released lit-html, a library that makes it even more compelling to adopt this approach:
lit-htmllets you write HTML templates with JavaScript template literals, and efficiently render and re-render those templates to DOM.
State Management
State Management is hard and React alone makes it a lot harder. That’s why libraries like Redux, MobX… have been used to “prop up” React. The problem is that these libraries are tightly coupled to the React programming model, which itself does not handle mutations very well. Their only purpose is to hide the mutations until you get to the point where you can let React render. But again, why would you want to create more dependencies? especially when considering the programming model behind Redux and MobX is far from optimal. You don’t have to! You can use a simple intuitive pattern: the SAM pattern. The SAM pattern is based on the most robust theory of Computer Science to date, TLA+, and embraces mutation rather than relying on yet another performance hog, immutability. Best of all, SAM’s programming model is designed to integrate API calls without any additional libraries such as Thunks, Saga, or a lot of aggravation when you calling APIs from stateful React components.
As a pattern, SAM is very easy to implement and I have created a few starter projects such as this one. I have also created a small library in case you are looking for something off-the-shelf and created several TODOMVC apps samples to show it in action: (vanillajs, lit-html, react, vue).
Security
When I wrote my original post on “Why I no longer use MVC frameworks?” two years ago, a lot of people complained that this approach was not secure. First I have news for you, React (or Angular) does not protect from CSRF, the excuse being because there is a server component to it. The problem is, to build a secure Web application you need to handle both XSS and CSRF, one without the other does not work. They are relatively easy to implement with HEC, again literally with a few lines of Javascript. There is a lot more things to do to secure a Web app, but please don’t think a Framework will protect you.
“ Our default workflow has been complicated by the needs of large web applications. These applications are important but they aren’t representative of everything we do on the web, and as we complicate these workflows we also complicate educating and on-boarding new web developers.” — Mikeal
I don’t want to make this post too long, but if I could convince you to give HTML5/ES6/CSS3/SAM Pattern a try you will quickly see that their are many advantages to not using a Framework, and I am certain you’d be delighted to feel how refreshing that approach is (and I am not even talking about Web Components yet).
Front-End Frameworks are just bloat as far as I am concerned.
If you want a cool name for that approach, how about calling it HEX! (short for H.E.C.S.)
#UseThePlatform
