The internet, as we know it today, is a very diverse place. Thanks to JavaScript and web frameworks such as React, Vue, or Angular, and many more, it has led to more application-oriented versus static websites. Some well-known applications, including Google Drive, Gmail, Salesforce, and Testim.io, are web-based reincarnations of software that used to be desktop applications.
But, what was it like in the beginning? Before the applications era, most sites were content-based: blogs, news sites, and a couple of e-commerce sites. If you think that building content-based sites is less complicated than building a Web application, you’re going to enjoy this blog post.
Chapter 0 – How it all began
When the internet started, it was nothing like as we know it today. It was only HTML, created to make it simpler to share data. As the internet evolved, sites needed to look more attractive, and developers required tools to turn designers’ ideas into reality, giving us JavaScript (JS) and Cascading Style Sheets (CSS).
Most of the sites were static sites—the HTML, CSS, and JS were created by hand, and an HTTP server served them to the browser. Creating by hand was tedious, and developers knew there could be better solutions. Programming languages, such as PHP, ASP, JSP, and Perl, enabled better orientation for website development. When combining easy-to-use databases (like MySQL), the maintenance for this new creature, websites, started to become less complex.
At this point, sites were no longer static and could adjust quickly to new demands by the marketing team. Need a new script to see how many views the article got? Want to display the company affiliates on all the pages? No problem, a couple of lines, and we’re good to go. But what about the content itself? Content creators such as news reporters shouldn’t need a developer to code articles or recurring website changes.
Chapter 1 – the birth of the CMS
Though in the late ’90s, commercial Content Management Systems (CMS) existed. Though the game-changer for CMS was in the early ’00s, as open-source CMS arrived: Drupal, WordPress, Joomla, PHP-nuke, e107, and more turned CMS into something notable, and development teams started to use it.
CMSs helped organizations manage their content better. Authors could write their content while the news editor could make changes and determine publishing timelines. CMSs used a friendly web interface instead of code. Creating various types of content was accessible. A restaurant’s brochures or menus could be updated easily by just about anyone, even with no coding skills.
As time went by, CMSs gained cool features: the ability to model your content, create pages via the UI, and drag and drop elements across the page helped developers, and non-developers, turn their dream about a cool site into something real.
Chapter 2 – the drawbacks of the complexity
As we discussed, CMS started to play a more critical role, and development teams began to use it differently from its initial purpose. It seemed, nearly anything could be solved using a CMS. Yet, small projects, which might not need all the CMS features, struggle to work with CMS and adapt it to their needs.
Expand Your Test Coverage
Model-View-Controller (MVC) architecture started to become more popular because they were light and provided many tools. Django, Ruby on Rails, Symfony, and other frameworks allowed developers to invest more time in the solution. To maintain it easily, ORM came built into those frameworks, along with easy templating systems that helped morph the data from the DB to HTML, CSS, and JS.
Still, it was not good enough for a good UX/UI experience. A lot of the heavy logic took place in the backend, which led to clunky sites because the backend generated the html, which served it to the user.
Many JavaScript tools started to appear and become better—jQuery, jQuery UI, backbone, and other frameworks helped modify the html on the site with easy to use API. jQuery is still popular because the WordPress ecosystem has tons of plugins that rely on jQuery.
Chapter 3 – The catalyst
You probably didn’t notice it, but the last chapter ended around 2009-2011. Javascript started to be more critical in the developer stack thanks to two events: the killing of flash (or the decision to end support for Flash on iPhones) and the birth of NodeJS. CSS3 and HTML5 provided cool features such as video and animations.
But the most significant event was the birth of Angular. Angular gave developers the ability to write HTML applications in new ways:
- Split the code into small pieces, such as directives
- Added some kind of application state
- A better way to communicate with the server (the content repository)
Now that we saw how a JS desktop application could look, the race had begun. New JS frameworks popped up to support the paradigm shift where browsers do all of the processing work. The backend would only store the data. In the beginning, that was good, but for a traditional content-based site, it wasn’t.
A content-based site could not rely on React or Vue since not all the search engines were optimized for rendering content in the browser, harming its SEO ranking.
While the arrival of React or Vue might not impact content-based sites, it helped product-based companies. New features frequently arrived in JS, and browsers started to do more, assisting startups in creating products that previously only desktop applications could provide.
Keep in mind that the paradigm where the browser will handle almost everything is well-matched for application sites and not for content-based sites. It was also more appealing for developers, making the web a place with better UX/UI.
Chapter 4 – The pendulum swing
By 2018 developers realized that moving all the logic to the browser is not a good idea for everything, and SSR (Server Side Rendering) got reincarnated. The idea is that we would still use React or Vue in the backend as a template system and then serve it to the browser, which then can be cashed over a CDN to improve site performance.
But wait a damn minute – we started the web with static sites, understood the operation is not scaling, created tools, and got back to the same point where the server needs to render the content.
That is what I called the pendulum swing: we would start from one point, progress with all the momentum, understand something was not suited for us, and then go back without even noticing we arrived at the same point, with a slight change—we choose another tool for doing the server-side rendering.
Chapter 5 – balance is the key
Let’s rewind to 2008. Something called a ״static site generator״ came to the world. We would store our data on files, markdown, CSV, and software will go over them and build a full HTML from the files. SSGs were a massive game-changer because now:
- There’s no need for DB and a webserver to be alive all the time.
- No need to maintain the site for security updates.
- Because it’s a static site, there’s no admin panel or dashboard that hackers can access and start messing up the website.
- Most of the static sites are simple for small projects, which benefit more than a traditional site.
Since then, more and more SSGs have been created and provide a way to create a static website in various development languages. There was one problem they all faced – they couldn’t scale well for a massive amount of data because building the HTML upfront for a lot of content is a resource-demanding task.
Over the years, benchmarks popped up, trying to see where SSGs fail performance-wise, but they all got to the same point – rebuilding sites due to a small change is something we want to avoid.
SSGs like Hugo are fast, and GatsbyJS kind of solved the performance problem with incremental builds. However, they still won’t scale well when applying a new change to all the existing pages.
Now, in 2021, we have NextJS and GatsbyJS, which stay in the sweet spot. You can start with either SSR or SSG and switch pretty quickly down the road. For example, the front page can be a static page since the links to internal pages won’t change, but an SSR can better serve a blog post. GatsbyJS and NextJS have a built-in web server, thus providing you all you need.
What makes developers’ lives easy is that we can use React or Vue pretty easily on the server-side, and we don’t need to learn the new templating system; it’s just React or Vue.
Summary
I hope you’ve enjoyed this abbreviated history lesson. The purpose was to provide a context for static site generators and show that what is old may someday become new again. Now there appear to be use cases that support both static and dynamic sites.
Next week I’ll release a blog on the top four static site generators and give you some tips on testing static websites.
