A compelling case for Next.js

Posted on Leave a comment
Nextjs logo

If GitHub stats are anything to go by, Next.js has received incredible attention of late.

Freelancers and enterprises alike are creating their next applications in or migrating their existing ones to Next.js. When I was recently on-boarded to my first account at Sapient, the departing senior XT architect highly recommended that we migrate to it.

But what is Next.js? Let’s first start with that.

The uninitiated probably know that Next.js has something to do with React. What exactly? Is it the next generation of React? Or something lighter and more performant (like Preact)?

I’ll attempt the simplest explanation possible. Next.js is a way to create server-side web pages all the while allowing you to compose your app using React components. It internally uses React’s server-side rendering principles (and perhaps ReactDOMServer?) to create SSR pages.

It’s okay if you don’t get it the first time. So I’ll quote from its official docs.

In the words of Zeit (people behind Next.js) themselves:

You may want to server-side render certain pages and statically prerender others (balancing SEO and speed).

Think about how webapps are created with PHP. You create some files, write PHP code, then simply deploy it. We don’t have to worry about routing much, and the app is rendered on the server by default.

That’s exactly what we do with Next.js. Instead of PHP, we build the app with JavaScript and React.

Wait. What?!

Are we going back to the server-side days? Weren’t we meant to move away from server-side on to client-side for performance reasons? Is creating single page client applications not the latest ritual? Besides, PHP, JSP, Ruby or Rails, ASP.NET… all can apparently do what Next.js promises.

To fully understand this, we must recap the pros and cons of server- and client-heavy apps.

Server-sideClient-side
Time to first byte (TTFB)Bad
(html is served after full processing on the server, taking its size up)
Good
(a bare-bones, ultra-lightweight html is served immediately)
Time to first meaningful paint (TTFMP)Good
(user can see the “primary” contents sooner)
Bad
(user has to wait for browser’s JS engine to execute all scripts to perceive a page’s “primary” contents)
SecurityLess surface area for vulnerabilities
(what happens on the server stays on the server)
More surface area for vulnerabilities
(increased scope for bad implementations of security due to exposed auth data)
SEO PerformanceGood
(crawlers can easily parse the entire html rendered then and there)
Bad
(crawlers that cannot execute JS code are just left out)
General PerformanceGoodDepends
(see the second article in links below)

I highly recommended reading the following articles once:

An Introduction to React Server-Side Rendering
Next.js vs. Create React App: Whose apps are more performant?
The Benefits of Server Side Rendering Over Client Side Rendering

The second article is especially unmissable, and makes a great point in favor of server-side rendering (SSR) in general. It explains with the help of key practical metrics why SSR wins over CSR in all important areas.

Personally, I have always been a BIG advocate of taking server-side along with client-side development. I don’t believe there’s any such thing as a front-end developer or a back-end developer. A front-end person who doesn’t not know their way around back-end code should not be called a developer in the first place! SSR or not, any app can be performant and secure only if its developers understand the full stack well.

Rails: Two different layouts with two different CSS frameworks

Posted on Leave a comment

I have said it before. Rails is awesome. I find myself creating a new web application in Rails rather than, say, ASP.NET or even PHP much more often. It is intuitive and uncomplicated. Command-line tools and pre-handpicked components allow me to focus more on writing code and implementing business logic.

While working on a Rails application, I was faced with a (reasonably) common situation — having one layout for the end-users and another for administrators. I had my admin pages all written and finished. My CSS framework of choice at the time I started was Ink, mostly because of its fresh UX and Bootstrap‘s aging grid system. When I was about to start with end-user pages, I found out about the release of Bootstrap v4.0.0 (something I had been waiting for since long). The examples made using this version were very much in line with what I wanted for my own purpose. I had made a decision: use Bootstrap for end-user pages and stick to Ink for the admin interface. Realizing this decision in Rails was not as easy as I had thought.

As good as the Rails documentation is, I frequently find myself wanting for more code snippets and examples for things that are apparently presumed to be too basic to explain. After stackoverflowing into the problem and applying some common sense, I came up with the following solution.

Continue reading Rails: Two different layouts with two different CSS frameworks