Beyond JAMstack: Next.js creator on hybrid rendering, TypeScript and Visual Studio Code

Interview Guillermo Rauch, creator of the Next.js framework for building React applications, spoke to The Register about the just-released Next.js 9.3 and its hybrid approach to web application development.

Rauch has been an advocate for the JAMstack for client applications, where JAM stands for "JavaScript, APIs and Markup". In its purest form, the idea of JAMstack is that a web application is pre-built into static pages, using content and code to generate the output.

This process could occur many times a day. It is efficient, because nothing beats static web pages for optimal performance and it is not necessary to regenerate the page for every request. Content that is specific to the individual user, such as account details or a shopping cart, is fetched from an API (published by your custom microservice or other application) by JavaScript running on the client.

The JAMstack concept therefore includes the idea of a static site generator – of which there is a list here. Examples include Gatsby, Hugo and Jekyll. Next.js is another. It is a JavaScript framework that generates React applications. Add in Git integration so that pushing a content change to a repository automatically tests and deploys the update, and you have a powerful mechanism for maintaining websites and applications.

Relying purely on static site generation (SSG) and APIs may not be best for every use case, though. The solution is to use a blend of SSG and server-side rendering (SSR). Server-side rendering is used by old-style web application technologies like PHP or ASP.NET. This led to discussion in the Next.js community to "allow Next.js to become fully hybrid by providing methods to do both static generation and server-side generation on a per-page basis."

This change is at the heart of the newly released Next.js 9.3. "Next.js is able to do a full spectrum of static site generation, client side rendering and server rendering," says Rauch. "It's almost like a new beginning. This idea of combining SSG in a hybrid way and giving people the options, it's a really big thing."

The new release also reduces the size of the JavaScript runtime library that is downloaded to the client, by removing the compatibility functions, called polyfills, necessary for older web browsers such as Internet Explorer 11. If a legacy browser is used, the polyfills will be downloaded on demand. This removes about 32kB from the page size, which improves performance. "Google is becoming really serious about ranking the listing of websites based on performance. They're even thinking about adding warnings for websites that are performing slowly that they will render on Android devices."

Minimalistic

What about the issue of developers using old JavaScript libraries that have security vulnerabilities? "Next.js has a frequent build cadence with a strict focus on backwards compatibility," says Rauch. "Code that you wrote for Next.js 0.1 still works in 9.3. So we've made it stress-free to upgrade your dependencies. Next.js is a lightweight framework.

"In the JavaScript world it has been hard to find the right modules to depend on; there's so many millions to choose from. We've already made that decision for you, so we bundle Webpack, we bundle Babel. We keep things secure by keeping things minimalistic."

Rauch says many Next.js developers use TypeScript, a superset of JavaScript with optional static typing. "We're one of the earliest adopters of TypeScript," he says. "We worked with the TypeScript team to create a very ergonomic way of using Next.js in conjunction with TypeScript.

"What Next.js does, is if you start writing a TypeScript page, it will auto-generate all the necessary configuration for TypeScript to be optimal. I think TypeScript will be the technology that takes JavaScript to the next level, especially in enterprise adoption.

What accounts for the popularity of TypeScript? "Companies that have traditionally been on things like .NET and Java, even the Ruby on Rails community, the GO community, they've always tried to avoid JavaScript. Because it was a scary language with a lot of interesting gotchas, it's very loose and dynamic. But they need JavaScript to create modern and compelling experiences. TypeScript gives them the same feeling and assurances of their back-end languages.

"Even if you have a competent JavaScript team, if they're writing a very large codebase, they need to adopt TypeScript in order to reason about it at scale, document and comment it at scale, do refactoring at scale," Rauch advises.

Someone creates a super well-optimized Next.js project, and then someone comes in from the business side of things and says, 'Just drop in this script' to run their ads

"Finally, there is the rise of Visual Studio Code. VS Code has become the front-end developer's code editor. It works incredibly well with TypeScript, and at the same time, TypeScript makes it an incredible code editor, you can do all these amazing suggestions, auto-completions, etc. So the success of VS Code and TypeScript have gone together. When I talk to TypeScript users of Next.js, I would say 95 per cent of them are using it with VS Code."

How might WebAssembly impact front-end development? Rauch says that it will help people who want to work in just one language. "Teams that use one language tend to move faster.

"Instead of a barrier to collaboration on a codebase: Go for the back end, then learn TypeScript for the front end. The hope has been that with WebAssembly we are going to be able to cross-compile to this universal delivery format and remain in one language. That hasn't worked in practice yet.

"There is a promising potential where you have an opportunity to speed up a discrete process that is well isolated, anything to do with image manipulation, video, numerical computation. We're seeing traction there. And we're building the bindings inside Next.js so you can incorporate WebAssembly modules, we've only seen them in specialized things so far, but I remain excited about it because it gives a lot of predictability to the performance. It's going to be interesting, but it's too early to tell."

Great work! Now let's wreck it with some ad scripts

The framework developers are doing great work on performance and design, but much of the web is unpleasant for users because of advertising and monetization. "One of the biggest performance issues that we see today is to do with advertising. Someone creates a super well-optimized Next.js project, and then someone comes in from the business side of things and says, 'Just drop in this script' to run their ads. We see lots of issues with rendering performance when pages start jumping around as a result of unpredictable ads-loading.

"Ads are also to blame for sub-par customer experiences, like gigantic pages floating around, and banners and pop-ups and blockers, and their privacy invaded. The web will have to evolve to find a way to retain great customer experience and preserve privacy.

"Native ecosystems like Apple's are making a lot of progress with this, with reasonable subscription systems and privacy protections built into the operating system. The web will evolve to gain these primitives, otherwise it's going to lose to competitors," says Rauch.

It is unfortunate that these wider issues are things that framework developers alone cannot fix. ®