This is a guest post by Debbie O'Brien (@Debs_obrien), the Head of Learning and Developer Advocate at NuxtJS.
Static Sites in the '90s
When we first built websites many years ago they were very static. It was all we knew. Html with some CSS and a tiny bit of JavaScript. A typical website from 1996, SpaceJam which really shows how static sites are.
When we first built websites many years ago they were very static. It was all we knew. Html with some CSS and a tiny bit of JavaScript. A typical website from 1996, SpaceJam which really shows how static sites are.
Although this was very cool in its day it is now rather ugly and there is no way we would create something like this nowadays. But if you run a performance test on this page it is scoring 100 for performance as it is just a static site with very little if any javascript and CSS.
Server-Side Languages
But as the web evolved many companies moved away from plain and simple HTML to use server-side languages. This was a great way of sharing your code between pages, getting data from a database and populating the page on the server, and then sending the rendered HTML to the client. This is great for Search Engine Optimization as pages are easily indexed by search engines. But it also meant front and backend code was mixed together. Changing the page means making another call to the server and minor page flickers can be seen as the page has to fully reload each time.
Single Page Applications
Then along came single page applications where we can share components across pages and where our frontend code is not mixed with backend code. With Single Page Applications we get Client-side rendering. What does that mean? It means that when the browser makes a request for the page a very simple HTML page is sent back to the browser and then when the javascript loads it renders the page on the client-side. This means we have faster navigation, no flickers of page changes when navigating because there really is only one page and when we change the page we are just using JavaScript to repaint that page with the changed content.
Single-page applications are fantastic but try selling them to the marketing department of a big company. The first thing they will tell you is single-page applications can not be crawled by search engines. And in a way they are right. Most search engines can't and even though some can rely on reading JavaScript and even just a small error in your js and the crawler might not read your page. Single Page Applications can also be slow on the first initial render as all the JavaScript needs to be downloaded before the page can render. Then it is incredibly fast but the initial page load can be a bit slow.
Static Sites are back
So really we need something that is as performant as our static sites from the '90s but as dynamic and powerful as our single page application and with indexable code for better search engine optimization. And that's why static sites are back. But we are not going back to the '90s. I mean we can if we want to. We can just create plain HTML and add some more CSS and javascript and we have a very dynamic looking static site. but really what we want to do is have a very performant static site with the look and feel of a dynamic single page application. And that is what we mean when we talk about static sites of today.
Static doesn't mean Static
You see the problem we have is that the word static is just a terrible word because it means lack of movement and really static sites are not lacking in the movement at all. But it really isn't the case at all. Static sites can be as dynamic as you like. To give you an example using Nuxt.js static sites basically, once the user requests the page this is sent to them from a static hosting provider, a serverless hosting as we call it. This page is already rendered and the client sees the page almost instantly. Then Vue hydration takes over and your applications start acting as if it were a single page application, routing is done client-side for example which is why we don't see page flickers when changing pages. All the calls to your API's are cached so that when the client-side routing happens there is no need to call the API to get that data as it is already there. This really improves performance. But of course, not everything is cached and we can still call APIs on user events to submit forms for example, or even make payments. The APIs give static sites enormous power and it is them that play a big part in making the static sites of today extremely powerful.
Hydration refers to the client-side process during which Vue takes over the static HTML sent by the server and turns it into dynamic DOM that can react to client-side data changes. Since the server has already rendered the markup, we obviously do not want to throw that away and re-create all the DOM elements. Instead, we want to "hydrate" the static markup and make it interactive. It's just like magic.
Rebuilding your Static sites
yes so trying to convince backend developers or managers that the best thing you can create for them is a static site is just hard especially because with static sites they have to be rebuilt when the data changes and that sounds like such a big task but really it isn't. To give you an example using Nuxt.js when working with static sites we can now cache your build and if only the content changes we don't need to rebuild the whole site we just need to rebuild the content and this makes it super interesting as build times are heavily reduced and not to mention live preview where you can live preview your changes from your API or cms and then when you are ready you can rebuild your site.
Benefits of Static Sites
Now there are times when server-side rendering is necessary and not everything can and should be built as a static site but for sure the majority of websites out there could easily be a static site. With static sites, you can host for free on a static hosting provider. There is no need for a server. This not only reduces costs but also without a serve the attack vector is hugely reduced and having no server reduces the carbon footprint too making your site greener and more environment friendly. Static sites are faster as they already rendered which hugely improves performance. And static sites thanks to javascript and frameworks such as Nuxt.js can be as dynamic as you want them to be. From looking at a site you should not be able to tell if it is static, or spa. The difference is in the time to the first byte and in the behind the scenes. The user is who benefits the most from this and putting our users first is really something we should all be doing.
Conclusion
example of a company using static sites is GitHub stars whose site is nothing but static and you can log in and send a nomination for a star. All that in a static site. yes. so yeah what are you waiting for. Get out there and start building static sites.
Resources
- This is how static sites used to be in th 90': www.spacejam.com
- A static site built with Nuxt: stars.github.com
- Nuxt release notes
- Nuxt static improvements
- Getting started with Nuxt
- Going full-stack with Nuxt
- Deploy your static site on Azure
- Deploy your Nuxt app on Azure
- Try Azure for FREE (12 months)
Want to do more with static web apps?
Join us at CREATE:Frontend on Jul 29 (8:30am PDT / 11:30am EDT) for a 4-hr free virtual event with 8 talks and a 90-minute hands-on workshop to jumpstart your static web apps journey
Bookmark our anchor post and do check back for updates
#Create: Frontend
Static sites are back again!
Contrary to what most would think about a static site having no dynamic capabilities, a static site means one that consists of a set of "pre-built" files (namely HTML, js, and CSS files) that are directly served on request. In our session at CREATE:Frontend, we explore the pros and cons of static and servers and why static sites are back again.
Bookmark and revisit this page during and after the event.
- Live Q&A Engage in discussions with speakers and the community. Speakers will be online for about 15 minutes after their session.
About This Session:
July 29, 2020: 09:05 PDT - 09:20AM PDT
We explore the pros and cons of static and servers and why static sites are back again.
About the Speakers:
Debbie O'Brien is the Head of Learning and Developer Advocate @ NuxtJS. Wassim Chegham is a Senior Cloud Developer Advocate @ Microsoft. Follow @Debs_obrien and @manekinekko on Twitter.
About MSCreate:Frontend
If you want to learn more about the MSCreate:Frontend event then check out this post with links to all the talks and speakers. And bookmark it to be notified of links to recordings and resources after the end!
Want to learn more about Azure Static Web Apps?
Top comments (13)
Nice 😄, Any use cases when we should not use static sites ?
I wouldn’t necessarily build an app as a static site app, or a static web app, if your app is rendered on the server (like a Java web app), or if you’re building a monolith app. Also, if you heavily depend on a web server, like Apache or nginx to serve your app. CMS apps are also not suited for static web apps.
CREATE:Frontend , session as good :)
So what is the best use cases to build static sites ?
Any websites where the content doesn’t change every hour for example. I have built hotel sites, travel agent, the NuxtJS docs, personal websites, websites for companies. Small e-commerce sites. The list goes on.
Thanks, I understand, So now we have
Azure Static Web Apps and Azure Functions API, with these 2 technologies we can even create dynamic sites like hotel sites, travel agent, personal websites, websites for companies, Small e-commerce sites etc.So do we now really need sever side technologies like
PHP, Java, C#, Go, instead We can do all things usingAPIisn't ?Exactly
Do we need server side technologies- well we can still write serverless functions in java and go and c# for example but what I think we don't need anymore is frontend and backend code mixed together to create an application. So let the backend create amazing API's which the frontend can use to create amazing apps/sites.
Thanks, Appreciate, 😄,
CREATE:Frontend, session as good :)Apart from SEO, why we should invest in server side rendering if we can utilize client (visitor) machine for computation for client side rendering?
Frankly, to me it looks like the trend has been started to monetize hosting business.
yes, great question. If only we could just get rid of the servers but sometimes it is good to have server side rendering for large e commerce sites for example as you need constant data changes per minute and don't want to or can't regenerate the site for every single change. There are ways around this sometimes. For example with Nuxt.js you can have a static site that has part of your site as a spa with a spa fallback so for a travel agent you could have a static site with all the hotel details as static but the booking engine page could be a spa inside the static site and that will be rendered client side and as the results of your search don't need seo a spa fallback works perfect here. hope that helps
Thanks for more details, but you can get the same result with something like socket.io (or any bidirectional communication) and that also without regenerating site on client or server side.
It's cool to build static webapp or app with server side rendering, but the usecase (need) is very narrow.
I got tired of JavaScript and built mkws.sh/.
A website template for the modern web. ⭐️ Star to support our work!
Refo
A website template for the modern web
Powerful developer experience meets lightweight output
Effortless Static Site Generation with Flexibility
Feeling overwhelmed by the static site generator landscape? Refo offers a refreshingly simple and customizable approach built entirely on Node.js.
Unlike Jekyll, Gatsby, Astro and others, we let you leverage the power of Node.js modules directly. This means you can generate any kind of website you can imagine, all with the flexibility of your favorite Node.js libraries and servers.
Key benefits:
SVGs, utilizerawimports, andstyleyour components with ease.Go beyond the limitations…