Brace yourself and take it one step further.

Note:The originalAs the framework continues to evolve, some elements may no longer be applicable.

Quick start for those who can’t wait: Sapper documentation and quick starter Templates.

If you were to list the characteristics of a perfect Node.js Web application framework, you might think of these:

  1. It should support server-side rendering (SSR), be quick to initialize and load content, and be SEO friendly;

  2. Application support for more common server and client code is a reasonable trend to expect;

  3. The client application supports mixing with HTML rendered by the server, with binding events listening on existing elements rather than re-rendering them;

  4. Navigating to other pages is lightning fast;

  5. Offline and other progressive Web application features must be supported out of the box.

  6. The first page presented should load only the necessary JavaScript and CSS on demand, which means the framework supports automatic code splitting at the route level, and dynamic import(…). To achieve more fine-grained manual control;

  7. Performance is uncompromising;

  8. Excellent development experience, using hot module overload and other auxiliary matching tools;

  9. Generated code should be easy to understand and maintain;

  10. The framework should be easy to understand, customizable in every aspect, not locked into a framework by webPack configuration, and with minimal “hidden secrets”;

  11. The entire framework can be learned in an hour, from the experienced to the novice.

Next. Js comes very close to this ideal.

If you’ve never met Next, I highly recommend you check out learnnextjs.com.

Next came up with the neat idea that all the pages in your app would be files in your-project/ Pages directory, and each file would be a React component.

It was the foundation of all of Next’s groundbreaking design.

Finding the code for a page is easy; you can just look it up in the file system without having to guess what the component name does.

At the same time, the squabbling over what kind of project file structure to use is over.

The combination of SSR (server-side rendering) and code splitting was even more deliberate (though the React team ditched the Router and said, “Good luck!” to anyone who tried SSR and code splitting). ).

And yet — as good as Next is, if I may say so, there is still something wrong with it:

  • Next uses “rout masking” to create more elegant urls (such as /blog/hello-world instead of /post? Slug = hello – world).

    This breaks the guarantee of a one-to-one correspondence between the application structure and directory structure and forces you to maintain a configuration that transforms between the two forms.

  • All your routes are assumed to be “pages”.

    But often you need some server-side routing, such as 301 redirects, or an API endpoint that provides data for pages, and Next doesn’t take care of that.

    You could write the logic to handle this in server.js, but that would feel inconsistent with the way the page is declared.

  • To use client routing, links cannot be standard tags. Instead you must use the component specified by the framework, which is impossible in this markdown blog post.

The real problem, however, is that all these benefits come at a cost.

The simplest Next app (showing just a page with static text of “Hello World”) has a gzip JavaScript that is 66KB compressed, and when unzipped, it takes up 204KB, which is a huge amount of code for mobile, but it’s “minimum consumption.” At this point, performance is the key factor in determining whether your users will stay.

We can do better than this!

Compilers are the reverse of frameworks

Svelte came up with a radical idea: what if your UI framework isn’t a framework at all, but a compiler? What if it compiles your components into separate JavaScript modules?

Instead of using libraries like React or Vue, which don’t really know anything about your application, the framework has to provide a generic solution.

The memory and performance overhead of a virtual DOM-based scheme can be completely avoided if only the code needed for the application is generated.

The JavaScript world is moving in this direction.

Stencil is a lightweight Svelte-inspired framework from the Ionic team that supports compiling to Web Components.

Glimmer isn’t compiled into standalone JavaScript (without going into too much detail, the pros and cons of Glimmer could be a separate article), but the team is doing some interesting research around compiling templates into bytecode.

(React is also starting to join the fray, although their current focus is on optimizing JSX code, which is similar to the pre-optimizations that Angular, Reactive, and Vue have done in recent years.)

What would happen if we tried to use this new approach as a new starting point?

Sapper profile

Sapper may be able to answer that question (the name comes from “sappers,” which is also a byword for “Svelte application Maker”).

Sapper is a framework similar to next.js that aims to meet the 11 ideal standards mentioned above while significantly reducing the amount of code sent to the browser.

It is compatible with Express’s middleware, which means it is easy to understand and customize.

The same “Hello World” with React and Next requires 204KB, compared to just 7KB with Sapper.

This number will drop further in the future as we explore the possibility of spatial optimization, such that no JavaScript is sent at all for non-interactive pages, except for the tiny Sapper runtime that handles client-side routing.

Is there a more realistic example?

RealWorld provides an example of developing a medium-sized project.

Showing the interactive front page of this RealWorld example, Sapper is implemented in 39.6 KB (11.8 KB compressed).

The entire app is 132.7KB (compressed to 39.9KB), much smaller than the 327KB (85.7KB) implementation used as a reference. Even though 132.7KB is still quite large, the point is that it feels very fast thanks to code splitting.

Code splitting is pretty much the norm these days, but if your application uses traditional frameworks like React or Vue, code splitting has a “minimum cost” — the framework itself, which can take up a significant portion of the overall size of your application.

Code splitting isn’t free either — frameworks like React use code splitting, which is much bigger.

However, if you use Svelte, the situation is very different.

Of course, size is only one of the concerns of development.

Applications written by Svelte are both extremely high in performance and memory utilization, and it contains powerful features that you might sacrifice if you chose some other framework with a “small” or “easy” UI library.

Weigh the

What’s the biggest downside of Sapper for many developers?

“I still like React, and I’m used to it.” — In fact, it is not wrong to think so.

If you fall into the above camp, I suggest you at least try out other frameworks, and you’ll probably be pleasantly surprised!

Sapper’s RealWorld implementation is only 1,201 lines of code, compared to 2,377 lines for the other frameworks, because you can use a very concise, easy-to-express template syntax (it only takes 5 minutes to get started).

You can also enjoy scope-limited local CSS with built-in automatic deletion and minimization of unused styles, or you can use preprocessors like Less.

So you don’t have to rely on Babel anymore.

SSR is also very fast because it’s just string concatenation.

We also recently added Svelte/Store, a small global state management library that synchronizes state across component hierarchies with zero introduction.

Even under the worst of circumstances, you will feel that you have made a wise choice!

Still, there are trade-offs.

For example, are you one of those people who hate “template language”?

JSX supporters will say things like “it’s really JavaScript” to whet you, but the great thing about React is that it’s written with unlimited flexibility.

React has its own tradeoff logic for this flexibility, but it’s a long story and we won’t discuss it here.

Let’s talk about ecology.

Specifically, the React ecosystem — development tools, editor integration, helper libraries, tutorial guides, StackOverflow q&A numbers, the framework’s own sinkholes, jobs, and more… These React’s are the best in the world.

Indeed, if you consider the “ecosystem” as an important criterion for selection, you are already stuck at the ceiling of your personal skills, which is bound to be a limit to your ability to rise.

But it’s still one of the most important initiatives for inclusive developers right now.

The roadmap

We won’t release V1.0.0 yet, as there are still many variables involved. But that’s just around the corner, and there will be a lot of exciting possibilities. (Note: the fact that V1.0 may never be released gives the authors a second thought about the technology)

I think the next big thing in Web performance will be “application wide optimization.”

The current compiler for Svelte works at the component level, and the compiler can generate more efficient code by understanding the boundaries between components.

The React team’s Prepack research is based on similar ideas, and Glimmer is doing some interesting research in this area as well.

Svelte and Sapper can put these ideas to good use.

Speaking of Glimmer, we’ll probably try to borrow their idea of “compiling components to bytecode” in 2018.

Think of a framework like Sapper, which can determine which compilation mode to use based on the characteristics of the application, and it can even provide the fastest startup time for initial JavaScript routes and then a delayed bytecode interpreter for subsequent routes to achieve the best combination of startup size and overall application size.

But for the most part, we want the direction Sapper takes to be up to the users.

If you’re interested in helping us and helping us shape the future of Web apps, join Github and Discord.

———–

< The End >