Skip to content

This.JavaScript: State of Frameworks- Preact Update

Hosted by This.JavaScript, an online event where developers learn about the latest news in JavaScript, State of Frameworks and Libraries covered all the breaking news in the world of frameworks.

On Feb. 19, State of Frameworks speakers, including many of the best and brightest from the development world, gave us updates on all things frameworks.

Here’s some of what Jason Miller, a member of the Preact Core team, had to say about what’s coming up in Preact.

Jason Miller — Preact Core Team, Google — @_developit

Preact X

Preact X refers to an initiative that’s been underway for a year to re-architect how Preact works. This rewrite isn’t pulling over any code from the existing codebase, but is gleaning from everything Preact developers have learned so far and maintaining the same set of tradeoffs that Preact is dedicated to.

Preact favors size first, followed by performance. For Preact X, developers are focused on making other features and characteristics of the library workable, but always subject to those constraints.

Preact X was triggered by the existence of a Preact concept called “Fragments,” which developers tried to implement in Preact but didn’t work. Fragments would likely have broken the library. Developers responded by beginning a complete rewrite — Preact X.

Preact X Goals

The goals of Preact X include better features, better compatibility with the React ecosystem, a smaller size for the library at the same time, better performance, and fewer edge cases.

The rewrite for Preact X started off with experimentation in a private repo. Since then, over 20 developers have been working tirelessly on the Preact rewrite. Many key collaborators from the Preact Core team have contributed to the rewrite. The private repo became the way for Preact to move forward. Now, there’s a steady march towards every feature being free.

Changes in Preact X

Preact now has hooks, including multiple implementations of them — upwards of five, though just one is being shipped.

Users can now import hooks from preact/hooks. This will allow you to avoid injection costs and wiring costs if you don’t use hooks. They are all fully independently implemented, so you only have to pay for the ones you implement.

Fragments were the primary reason for the rewrite. Fragments are essentially virtual DOM nodes that are not represented in the real DOM when it gets rendered — similar to Document Fragments, but they persist. In Preact’s new diff, this is possible.

This is significant because Preact used to diff all of the virtual DOM nodes against real DOM nodes. In the Preact X repository, developers now diff the virtual DOM tree against the new copy of the virtual DOM tree as generated by the render functions, and then apply it to the real DOM.

Another issue that the rewrite is tackling is compatibility with React. Originally, the reimplementation started out under the same specifications as Preact Core. But because the size was reduced sufficiently, some of these issues could be walked back.

The virtual DOM nodes in Preact have always been significantly different from those in React — with different names, shapes, and functions. That’s smoothed over somewhat in preact-compat. Now, virtual DOM nodes in Preact X (Ceviche) look the same way they do in React.

Other compatibility efforts added include createRef(), createContext(), hydrate(), forwardRef(), and other functions.

The end result is that preact-compat will still exist, but it will be greatly reduced. It used to be a 3KB library on top of a 3KB library, but now it’s significantly smaller.

Ecosystem Work and Next Generation

Recent changes to Preact CLI include shipping Webpack 4, differential JS serving, critical CSS inlining for any routes you have in your prerender config, a new, simpler config format, a faster install and startup, and switching to Workbox for Service Worker.

In the future, Preact developers are also looking at Compiler optimizations, supporting htm as a first-class option, and official solutions for server-side rendering.