NextJS 10 and other neat tools

1

One thing that really excites me is the latest NextJS 10 release. The focus on their vertical integration between infrastructure, client / server framework, and tech partnerships such as with the Google Chrome team is fascinating.

Their eye for design, even though not perfect, is pretty good in comparison to their competitors. They focus on a very specific set of features, and polish them to no end. They don’t want to compete in every single domain there is in web hosting, but think about the problems a typical product engineer has to get stuff done. Just have a look at their new Analytics Landing Page .

image
image1400×1034 160 KB

Pretty clean and sleak.

Their focus lies on making sure that both, the developers and users get the most out of it by making builds fast, reliable, quantifiable, while still giving their users flexibility in their hosting options. If you look at e.g. Gatsby, they are actually doing the exact opposite: Make the tech stack so hard to understand, so convoluted that you actually have no choice than buying into their Gatsby cloud service, to have at least some acceptable build times.

Designing dev environments with tools and APIs that are easy to understand, but still powerful enough to cover all the use-cases, is a pretty hard discipline. I know Next is not perfect, but in the last few years it has really grown on me on how well they advanced their platform, especially when you think about their upgrade paths with every major upgrade.

rescript-lang.org runs on Next, and since with version 10 there are some interesting new features, such as builtin internationalization, I am really looking forward trying that out.

Besides, I found a lot of subtle flaws within my current ReScript / Next setups, and I can’t wait to update the rescript-next-template to the newest version to make e.g. fast-refreshing more reliable in the future.

Another tool that currently peaked my interest is vite by the creator of VueJS. It’s a pretty straightforward webpack-like dev-server / bundler frontend, that doesn’t really bundle during dev times, but leverages the ES6 module import mechanism and <script type="module"> to lazy load JS scripts instead. It also has postcss builtin, so it’s pretty easy to wire up other tools like Tailwind. Now, drop ReScript into the mix, and you are up for a jolly ride with almost zero complexity, and in comparison to today’s JS standards, an insanely fast development workflow.

A vite setup can (IMO) be a potential default template for a bootstrapped ReScript / React app if you ask me.

Generally I am pretty positive about the future, hopefully the new generation of JS tooling will try to keep the feature set small, instead of bloating their APIs for no apparent reason (just because it is “cute”) and f* everything up. At least for vite, afaikt, the maintainer seem to be pretty conservative about adding “preferential options”, just to make sure that the community has one way of doing things.

To sum things up, I guess building products has never been that easy.

6 Likes
2

What are you takes on react-static, after.js approaches to routing? When you say next.js, it sounds like you specifically mean prerendering + client side rendering (mostly static routes or dynamic routes as well?), and that you are not using it’s universal/isomorphic features? Do you like next.js’s approach to pages generated from data, and it’s general selection of abstractions for collecting and propagating data at build time? I am watching next.js, but I keep wavering on whether its the right fit for one project I might start soon.

3

Great assessment and I share the same sentiments. Frameworks like Next are blessings and culmination of the constant expansion and compression of ecosystems as they grow, in this case React and web dev. Specifically Vercel, I love that they go super deep on the seemingly simplest problems. Seriously, that Image api now? It’s true it’s always been a pain to remind others / automate image optimization, and now they’ve made it even easier.

I run rescript on next as well, and it’s so easy. Everything’s so easy. I was tempted to learn Elm to try that world and it’s Apple like philosophy, but…it’s so far behind the zeitgeist here.

4

The best part about Next is that for pages you don’t need to request dynamic data on, it pre-renders those pages and serves those pages. If you use their vercel platform, it’s pretty slick.

I’ve ran Next on AWS servers, and though we don’t get all the fancy stuff Vercel provides, it works fine and easy. Even if you don’t need much of this stuff, the dev experience and defaults it sets you up with is worth.

1 Like
5

The built-in i18n support in NextJS is good news indeed. :smiley:

@ryyppy Speaking of vite, did you try https://www.snowpack.dev/, too?

6

I tried snowpack in the beginning, but there was too much magic involved and couldn’t get ReScript to work properly. Since then the API (and I think even the name?) has changed. I also don’t think I fully understood Snowpack’s business model yet… not sure if it’s worth my time investment after trying vite tbh.

7

Honestly I don’t really care about the technical details here… the things Next ticks for me:

  • Does it allow static rendering in general, so my website is easy to crawl? yes
  • Does it allow me to create stateful component stuff in specific subpages? yes
  • Does it offer all the hooks i need to read / manipulate the route in general? yes

It doesn’t matter what requirement I had, Next had me covered in one way or another. There were a few bits i didn’t like (e.g. Link as attribute), but those got fixed over time.

If you don’t have any concrete vision on hosting, and just want to get things out of the door (not sure if it’s a commercial project, or just a hobby thing), Next is pretty much a nobrainer when combined with Vercel. You don’t have to worry about lack of docs or resources, it’s stable, it’s easy to upgrade existing projects, and most importantly: We (or at least I am) using NextJS with ReScript on a daily basis, which means it’s easier to build common workflows and help each other.

Disclaimer: I haven’t hosted / managed a NextJS app on my own infrastructure, and also never used it on other hosting services such as Travis or Netlify, so I can’t tell how hard maintenance is on a devops level.

1 Like
8

For people fluent in ocaml, a combination of ocaml scripts performing the logic in getStaticProps as an initial build step and using a vanilla ReasonReact + vite/webpack application with improved lazy loading might be more powerful than nextjs by mid 2021?

Also, I am a little hesitant about nextjs focusing on server side internationalization in version 10, as most people use it for static site gen rather than universal/isomorphic javascript. Does nextjs team not recognize that static site gen is where they should focus?

9

After two months of using nextjs, I am going back to my original instincts that react (next/gatsby) is overkill for most static sites and adds too many dependencies/forces you into bundlers with obscured bundler settings and I will use eleventy whenever I am given the choice.

10

If your goal was to create a purely static site without any interactivity, and without any intention of using React as a component system, then Next et al is definitely overkill.

Where Next really shines is when you want to mix different static / interactive / dynamically generated pages per request (that are also cached and served via cdn).

E.g. the original Reason docs are built with docusaurus (yet another static site generator). To provide the playground, they had to create a sub webapplication folder within the docs that bundled up the playground stuff into a webapp, that was later on served alongside the generated content of docusaurus. So now you actually had two workflows to maintain, each with its own bundler related madness. In rescript-lang, I could seamlessly take my Playground component, and just place it in any of my markdown files and it will just work, because Next will figure out the boundaries between static / dynamiccontent, and create the right bundles and script tags for me. This is extremely convenient, and way easier to understand for other contributors (also the fact that we are using React components, that are really well understood in our community). We also use Next’s builtin functionality for generating the ReScript Package Index on the fly, and cache it for the next 6 hours, without the need of any extra CI.

The bottom line is, if you want to build webapps / small interactive components with (complex) interaction embedded in your static content, you’ll need some bundling setup. Problem is, you will never escape the JS bundler dependency hell unless the JS ecosystem will eventually get rid of webpack and the concept of app bundling completely. ES6 module loading in plain JS will hopefully eliminate the need for bundlers, and hopefully the whole ecosystem will migrate to the ES6 module soon enough, but until then, JS infrastructure devops will continue being a full time job.

Many (myself included) have tried building something similar themselves. After a year of trial and error, I gave up because it was more economical for me to learn the webpack details, than maintaining my own complex logic for solving the aspect of interactivity.

I also used eleventy for the OCaml Software Foundation Website. It’s a cool tool, and for this use-case it was totally fine, but I am not sure if I would use it for more ambitious projects such as rescript-lang.org. I had too many plans for some cool interactions that will make the content way more accessible, so I wanted to be sure that i don’t get distracted with things like wiring up scripts, or figuring out how to make certain JS bundles efficient to load, or solving problems on the CI level.

3 Likes
11

Yes, this is exactly what I have been thinking and I am eagerly awaiting vite adoption over time, after reading your link to it.

I will see if I can create an 11ty + ReScript starter some time, based on someone’s github link in Discord (https://github.com/johnridesabike/johnridesabike.github.io/blob/eleventy/.eleventy.js#L80). I am not that motivated to do it.

For me, I think the moment someone should reach for next/gatsby is when they have more than one page using a react component, or one complex react component. There should be something like “eject” from 11ty to nextjs, that automates the upgrade.

13

Between the choice of gatsby and nextjs, I still lean towards nextjs. For anybody reading this thread, they should note that gatsby supports a pure static site with internationalization - https://www.gatsbyjs.com/plugins/gatsby-plugin-intl/ , but you will have to roll your own combination of libraries for nextjs if you want to make sure your site is strictly a static site with no backend.

1 Like
14

I am curious to hear your thoughts on mdn’s roll their own “yari” project which uses react rendering internally. Would you go down that route if ReScript hits 500 markdown files?