How new web platform features and compile-time frameworks are establishing the next era of web development
Photo credit: [Stefan Bucher](https://www.flickr.com/photos/bucher/684595491)
Frameworks like Angular, React and Ember are par-for-the-course for complex web development these days. Over this decade (Angular was first released in 2010) they have grown to become defacto standards for many of us, helping countless organisations to structure their code, manage state and build complex UIs, based on reusable components.
As Alex Russell has calculated, going beyond just 130KB for all our assets can mean failing to load within 5 seconds on a baseline phone and network. Yet some of our favourite frameworks can take up more than that just by themselves.
Can we have the benefits that we’ve become used to from these frameworks, while avoiding the bloat? A great Developer Experience and a great User Experience? I believe so. And I believe that we’re entering a new era of web development that will be defined by this... An era where our frameworks disappear.
An example of this trend is Svelte, “the magical disappearing UI framework”.
[svelte.technology/](https://svelte.technology/) (not to be confused with sveltejs.com :))
An example of an app that was built using Svelte is Pinafore, a Progressive Web App client for the Mastodon decentralised social network, built by Nolan Lawson from Microsoft. Pinafore gets a very fast result from Web Page Test and a score of 98 for performance from Lighthouse.
A [toot](https://toot.cafe/@flakoot/100226502630578333) about pinafore.social, viewed at pinafore.social :)
Svelte itself is pretty minimal, but it has a related project called Sapper which builds a whole developer experience on top of it. Inspired by Next.js, it includes server-side rendering, code-splitting, scoped styling, declarative routing and live reloading with hot-module replacement. Furthermore, the Sapper starter template gives you a PWA by default, with a web app manifest and a service worker with automatic resource caching.
I asked Nolan how he found using Svelte and Sapper. He told me that he found Svelte “a dream to work with”. Sapper “is a little less mature” and he had some issues with it, but he’s happy with it too. I’ve also started using them for a new project and so far the combination of all those developer features along with the super performance really does feel ideal!
More magic! — [stencil.js](https://stenciljs.com/)
Again, the goal is to adopt “the best concepts of the most popular frameworks”, but to achieve better performance:
“With… traditional frameworks and bundling techniques, the team was struggling to meet latency and code size demands for Progressive Web Apps that ran equally well on fast and slow networks, across a diversity of platforms and devices.” — [stenciljs.com](https://stenciljs.com/)
To understand what Stencil consists of, I found this introduction from Rob Bearman useful. There’s also a video intro here by Maximilian. The output from Stencil is a standard Web Component (more on Web Components below), not specific to Stencil. This means you could use them in conjunction with another framework if you wanted (but this post is about frameworks disappearing, not multiplying! 😉).
NB. It’s not promoted much in the docs, but it’s also possible to configure Svelte to compile directly to Web Components too (here’s an example — with the ‘customElement’ flag set here — and here’s how the resulting output looks). However, Rich Harris, the developer of Svelte (and Rollup and other amazing things!) told me that he doesn’t think the benefits of enabling this are that great right now.
Stencil is also similar to Google’s more well-known Polymer, but it’s intended to fully disappear from the output! I haven’t used either enough to comment too much, but Polymer could be worth another look too. The recent version 3 moved from HTML Imports to ES Modules (more on this below) and from Bower to npm. There’s also a PWA Starter Kit that Alex Russell recommends as the best place to begin building performant web apps. It gives you the PRPL pattern (Push, Render, Pre-cache, Lazy-load) out of the box.
Thanks to Rich Harris for informing me that Angular is following this trend too! Angular Elements — new in Angular 6 — allows you to export Angular components as self-bootstrapping Web Components. Currently, it still requires “a minimal, self-contained version of the Angular framework [to] be injected”, but they are “working on custom elements that can be used by web apps built on other frameworks”.
Plus Angular’s next-gen Ivy renderer is designed to drastically reduce the output code size. (Although worth a look: in the spirit of friendly competition, Rich has created a comparison of the output from Svelte, compiling to Web Components, versus Ivy!).
(Kind of angular) ivy. Credit: [Auntie P](https://www.flickr.com/photos/auntiep/28551118/)
It’s great that popular frameworks are embracing this approach and making their output leaner too. Hopefully, as more and more web apps transition over, it will have a big impact on web performance.
Furthermore, increasingly we may not need a framework at all. Frameworks can of course make development easier and will continue to provide useful additions, but the web platform itself is providing more functionality than ever…
The web platform as a framework
“You don’t need a framework to use CSS Grid. CSS Grid is a framework.” - Rachel Andrew
Web Components are especially powerful and the key to much of this trend. They consist of four main technologies: Custom Elements, Shadow DOM, HTML templates and HTML imports. These features aren’t available everywhere yet, but as Ada says, they have pretty good support and there’s a polyfill which gives them even better support, so you can use them today!
You can feel even safer adopting newer features like Web Components if you use Server-Side Rendering (SSR) and implement your client-side with Progressive Enhancement.
"My personal preference is to build a great SSR experience and then enhance it to a Single Page App." - Ada Rose Cannon
Isomorphic ES modules
This is great, because we get to reuse our scripts across the front-end and back-end (i.e. “isomorphic rendering”) without jumping through hoops. We can structure our front-end code nicely, without having to bundle our scripts together, dump lots of script tags on the page, or introduce client-side module loaders.
I hope this post has shared how we’re starting to embark on a new era of web development. An era that is less reliant on traditional UI frameworks, CSS libraries and bundlers. An era where we ship less bytes and load our web apps quicker. An era of disappearing frameworks.
Thank you to Nolan Lawson, Rich Harris and Ada Rose Cannon and for their help and inspiration for this article.