The Story of Next.js

in the history of this planet's civilization some discoveries or inventions have led to breathtaking changes in our lifestyle there's a revolution in software an incredible breakthrough the software's going to change everything let's go i'm actually kind of pumped right now every decade or so a technology comes along that changes how we write software is next.js that technology or is it just another framework that'll be obsolete by next year to better answer that we need to go back way back to the beginning of the web in the early days of the web there were just documents with links between them when a browser made a request to a server for a particular page the server would find the html file stored on its hard disk and send it back to the browser it was a simple relatively fast process primarily because everything was static every user no matter what received the exact same static experience not long after instead of serving up static files servers started pre-processing the html before it was sent to the client every time a browser would request a page based on the user's cookies or authentication headers the server would generate the html on the fly for that specific user this allowed you to create sites that were more than just for reading static documents now you could create unique experiences for each individual user but there was still something missing yes pages were being dynamically created on the server but the end result the user got was still a static experience for the web to take a step towards being a real application platform it needed a way to make static pages more interactive then in 10 days in the summer of 1995 with braveheart while you were sleeping in a goofy movie topping the box office charts one man on a lot of caffeine did just that i did a prototype under mark's code named mocha uh it was done in 10 days notoriously where i didn't sleep much and then after i did it i started embedding it into the netscape browser and immediately early users said can you change this can you change that and i made some changes which i regret but it was so uh soon on a rocket toward shipping that i couldn't change much after a time and so early mistakes and design decisions were frozen and i was busy trying to make the rest of the browser appear as a set of objects in the language you could play with uh and then it shipped and it went through a name change from mocha which was just the code name to livescript because somebody in netscape marketing liked the live prefix livewire live script and then the real goal all along with at least mark and bill was to make it the sidekick language to java so in december of 1995 it was renamed javascript with a trademark license that son gave to netscape javascript was a step in the right direction but its initial release was rushed underfunded and it was treated as sort of a toy sidekick to java not only that but the way it was initially used was not ideal javascript had enough good at the beginning to survive now if you think back though to the mid 90s javascript was cursed because it was mainly used for annoyances like little scrolling messages in the status bar at the bottom of your browser or flashing images or things that popped up windows massively the good news was even though it was rushed javascript was malleable enough to encourage user innovation it just needed something to push it over the edge then in 1999 that something came in the form of an ugly but powerful api ajax changed the game because it allowed browsers to send and receive data from the server without needing to reload the page this one change ushered in the next era of rich dynamically generated web apps in fact believe it or not ajax was so powerful that apple's original developer strategy for the iphone was centered on it we've got an innovative new way to create applications for mobile devices really innovative and it's all based on the fact that iphone has the full safari inside it you can write amazing web 2.0 and ajax apps that look exactly and behave exactly like apps on the iphone so at this point with the addition of ajax and additional improvements to the javascript language the web started to look like a viable application platform this ushered in the angsty teenage years of the web the era where you could build real applications before any of us knew what we were actually doing so now we're in 2011 and what has changed what has changed is the javascript engines are amazingly fast they can work with a lot more memory the garbage collections have improved the browsers have improved and so on but the way you write a web application is fundamentally the same nothing has changed since since 2005 when original ajax applications have been introduced mishka goes on to describe that there are three ways to build web apps treating the browser as a dumb terminal with a round trip to the server abstracting away html and javascript and doll manipulators each coming with their own set of opinions and trade-offs none of which were ideal so where did we go from here well when you're a hammer everything tends to look like a nail the dom scripting era of vanilla javascript and jquery eventually led to the lawless period of angularjs which eventually led to the creation of a library called react.js one of the core innovations of react was that they made the view a function of your application state all you had to do is worry about how the state in your application changed and react would handle the rest but this was only really half the picture the real innovation happened when you encapsulated this idea into a proper component-based api by doing so the same intuition you have about creating and composing together functions can directly apply to creating and composing components to truly embrace a component-based api react needed a way to allow you to describe what the ui effort component would look like from inside the component itself to do this they created jsx though some people hated it jsx combined the power and expressiveness of javascript with the readability and accessibility of html if you were already comfortable with both javascript and html which you probably were if you were building web apps then you could get up to speed with jsx in a matter of minutes not only that but by embracing both jsx and react's component-based api all of a sudden what used to require imperative operational like code could be extracted behind a declarative api this not only enabled a better developer experience but also a vibrant ecosystem of third-party components so sounds pretty nice what's the problem well react by design is very good at what it cares about and it's unopinionated about everything else since most applications need more than just a view layer this led to the dark ages of react where you needed a phd in computer science to figure out how to actually build something we're talking gulp config type levels of despair here or if you're really kinky you could choose the webpack docs for your punishment of choice regardless the simple elegant nature of react was often overshadowed by the massive pain in the heart it was to get even the most basic app up and running react's unopinion nature was great because it allowed you to choose your own adventure but the adventure most normal devs wanted was to build nice performant web applications and then leave work as soon as they could ideally without tinkering with webpack or gold configs then after years of wandering in the wilderness crete react app was created by a team of facebook to make getting up and running with a react app as easy as possible with one command you'd get a production ready react app no longer did you have to worry about tinkering with webpack eslint or babel this allowed you to focus on building your app rather than configuring it rate react app was a huge blessing to the react ecosystem at the time and today it's perfectly suited for a world that no longer exists the problem that angularjs ushered in and create react app embraced was that both were optimized for creating single page applications with spas instead of making a request to the server every time a user visited a new page your application would load all the necessary html css and javascript for your app on the initial request this meant that subsequent route transitions would happen entirely on the client giving the app a more native like feel done well spots create a brilliant user experience that feels snappy and app-like done anything less than well and spas leave a lot to be desired by their nature spas tend to encourage large bundle sizes if you're not careful this is especially problematic for users on slow internet connections or mobile devices second with spas your data is typically loaded on an as needed basis again if you're not careful this leads to an experience where every route transition is met with a barrage of loading spinners finally if you care about seo creating a spa is less than ideal because you're relying on google's ability to execute your javascript before it's able to figure out the content of your page now it's not so much the spas are bad because they're not it's more that the pit of success with spas is small and creating one well takes a lot of experience for thought and attention to detail they should exist but they probably shouldn't be the default way we create applications so with all that what's the solution today i'm talking about next js which i hope many of you are already familiar with it but if not it's a simple framework for server rendered universal applications with react the main idea is very similar to what tom was talking about with create react app there is an opportunity to make starting with react develop development much easier but at the same time there's an opportunity to make it really really simple by taking advantage of the fact that react is a very universal paradigm as it is for any kind of ui related work a lot of what it's trying to do is merging the world of how the web used to work with all the new exciting possibilities that heavy and fat clients come with this cuts to the heart of what next.js is the culmination of everything we've learned from the last 20 years of building for the web with next.js you get the simplicity of the document era the power of the server rendered era the composition of the react era and the ux of the spa era all while minimizing a lot of the tradeoffs that each era brought in so how does it do this well first next.js is a framework built on top of react this lets next embrace react for what it is a ui framework and ignore it for what it isn't anything else like create react app you can get up and running with the next.js app with a single command to create a new page in your app with nextgs you just add a file in the pages directory that exports a react component describing the ui for that page by default next.js will statically generate the page of build time and like websites of old serve up the html for every request allowing it to be cached by cdns unlike websites of old if that page needs external data that can be fetched at build time you just export a get static props function which fetches and returns the data which will then be passed as props to the component static generation is nice because you still get all the benefits of a static document but with the flexibility of external data but if that page needs data and it can't be fetched at build time you have two choices you can either server render the page which allows you to both fetch the data on the server and create a unique experience for each user by analyzing the request cookies or you can fetch the data on the client like a traditional single page application regardless next.js gives you the flexibility to choose when you want to get data into your application at build time on the server or as users use your app there's even a feature called incremental static regeneration which allows you to statically generate your site at build time then on a per page basis regenerate a page on demand with new data and since next.js is a framework it comes with a bunch of other features that aren't just related to getting data into your app for example next.js comes with code splitting out of the box which means that each file inside of your page's directory will be split into their own bundles during build time so users only download the assets they need another example is image optimization next.js comes with an image component that's like if the html image element had been built for the modern web out of the box you get improved performance by always serving correctly sized images for each device using modern image formats you get visual stability by preventing cumulative layout shift automatically you get faster page loads because images are only loaded when they enter the viewport and you get on-demand image resizing even for images stored on remote servers and since nextgs is more than just a front-end framework you can create api routes without having to spin up your own server meaning you can literally build out an entire api with an xjs by simply creating a file nextgs isn't the only framework of its kind however it was the first that combined decades of innovation into a single package which is why as of today i believe next.js is the best way to create web applications mosaic put a face to the web and mosaic plus the web then finally gave us a way to express to the non-technical person what all of us in computing knew was the tremendous value of having networks interconnected

Channel: uidotdev

Views: 490,261

Keywords:

Id: BILxV_vrZO0

Length: 12min 13sec (733 seconds)

Published: Mon Mar 28 2022

Reddit Comments

[u/Cassius-cl]

Cool video, but it's missing the main reasons of nextjs success which are are related to the headless/jamstack ecosystem.