Why CHTML will make the lives of Front-end developers better
It’s no news that web-native might be the next big thing in web development. I decided to compare CHTML — one of the technologies in web-native’s tool kits with react.
The underlining problem
You see, within the last few years, we’ve seen a spike of new technology frameworks especially in the front-end space. These tools offer to make lives easier but in their effort to do this, they provide various unique abstractions to solve these problems. While they’re doing the job pretty well, for the most part, the abstractions have created unnecessary complexities over native languages and APIs and have derailed from the predefine web standards.
More specifically, we’ve begun to hear things like HTML-in-JS(JSX), CSS-in-JS and the likes. This has raised concerns in the community, most especially among experienced engineers within the community. The question that keeps on popping up is:
Why do we need to add a language over another language to solve a problem?
Why do we need to derail from the concepts of separation of concerns?
This type of question and many similar to it has started raising concerns in the eco-system. That’s why Web-Native was created to solve this problem. You see the goal of web-native is to bring web development back to its native languages; hence the name.
Web-Native is a modern technology stack that brings modern development techniques to the web platform itself instead of creating new abstractions over standard web languages. This helps you get things done in plain JS, HTML, and CSS and overall helps you get the most of the web platform itself. It is opening a new era of platform-driven apps.
This tool kit comes with a couple of libraries right out of the box. They are CHTML, Reflex, JSEN, MQL and it’s a utility library called Commons. As a front-end engineer, my favorite is CHTML and Reflex.
CHTML over React
React came to solve a couple of problems such as having to interact with the DOM tree directly which of course, is an expensive operation and causes performance issues. React also facilitates building apps like leggo blocks i.e piece by piece. In the effort to solve these, JSX was introduced to help bring HTML into JS but under the hood, JSX is simply a syntactic sugar that has to be compiled into the regular Javascript the browsers can understand. So every time a react element is rendered to the browser, JSX has to be compiled to JS before rendering and the cycle continues. This introduces heavy tooling and dependencies and is an added layer of complexity.
CHTML solves this through another approach. Rather than implementing UI components in Javascript, CHTML brings UI development to its native languages. In other words, you get to define components directly in HTML. HTML at its core already provides everything we need to implement UI components at markup level so it would be an overkill to create markup in JavaScript. CHTML unlocks all the possibilities within native HTML. For a deeper dive into the nitty-gritty of web-native and what it libraries has in store, watch out for my next article in this series.
Conclusion
In summary, CHTML has a lot of untapped potentials. It reduces that added layer of complexity presented by react and some other popular front-end frameworks, it facilitates scalability, it increases development times within teams and most importantly, I think it brings out the superpower in you while using the language you love. Why not give it a shot today and who knows, this may be the needle that makes an impact in your development flow.
