The Modern Web
When websites stopped being simple fixed HTML layouts with hyperlinks they called it Web 2.0. What number are we at now? I must have lost count. I have learnt HTML5 and CSS3 on my own long before I had to use it professionally. And once I started being asked to provide solutions for web projects... those no longer seemed to matter much. Sure JSX vaguely resembles HTML5 and CSSinJS - well, if you squint your eyes a little you might find things that sound familiar.
The day the web changed - but did it become better?
When I got first in contact with web development in an professional setting I thought that it was very clonky, all those jQuery components were limiting and bleeding CSS an absolute nightmare. The first time that I felt love for something in the webdev field was due to my encounter with Twitter Bootstrap. Responsive web pages - I could not get enough of it. And the second time - Facebook React.
A modern website often resembles more a desktop application. Gone are the days of the destruction of the DOM between page loads. Clicking on buttons now loads the content you want to see without you having to stare at a white page transition. You type in a search query and the results appear, magically a few seconds later.
Choose you Stack
Your first step into the modern WebDev mine field can be daunting. Not only are there already thousands of libraries and hundreds of Frameworks that are in regular use in the industry. But there will be a new one every day in your inbox and some of them just look so tempting. You really want to add all of them to your web project and bedazzle your users as well as your coworkers.
But you will quickly learn that learning all of them is not an option - there are too many. And the quality and longevity of them varies widely. And then there is the job perspective - what libraries / frameworks are in demand in your area? You will not be able to pass the screening process if you lean to heavy on exotics.
A stack is a combination of - let's call them - tools then can be combined to build a full-stack web application from top to bottom. An example is the MERN Stack. The acronym describes a tool stack consisting of:
- MongoDB for your page data__,
- Express.js as a webserver for you application
- React.js to build your frontend user interface and connect to your database
- Node.js the backend that drives your application
What makes a Web Application
The uninitiated use might be surfing amazon.com and still considering it to be a website. But on the other hand, if you show him a "real" website you cooked yourself in 5 minutes based on simple HTML/CSS + a fancy jQuery accordion for your site nav, he will probably not be impressed and agree that there is an obvious difference between them.
So what makes a website a web application? To be honest I don't know if there is a list you have to comply with. It is a very soft discriminator. For me, I have an image in my mind how a smartphone app or desktop application works. When a website shows a similar behaviour then it is a web application. What are tools that can give you the application look&feel ?
- Reactive Interface: React, Angular, Vue und Co. allow you to write webpages that no longer navigate between pages. You whole application can be on a single URL (SPA; Single Page Application). Interaction that require your app to get new data now trigger a background service to take care of everything. Once the data arrives every element that relies on this new data will be re-rendered. The trick is now to break up your page into small components so that your user faces a mostly static interface - just like you would expect a desktop to behave.
- Offline Support: A smartphone app, even if it partly relies on an online API, can be launched and partly used when you are offline - only online features will result in an loading animation or error message. Websites have always been dead when you cut your internet. Not anymore! Service Worker now take over the loading and caching of data from your web browser. Such a worker can be embedded inside your web app and cache the complete content making everything available offline. A use case would be a webUI for an IoT device. The data that has to be cached is minimal and it won't disturb your smartphones cache management system. Whenever you open the URL to your web cam, the interface will be available instantly - just like a native smartphone app. Service worker also add support for background downloads of new data, that will only be displayed once the download is completed.
- API Interaction: A webapp can interact with your backend and apply some logic to it. For example you can show different content based on user permission, fetch data from different sources and combine them in one dashboard, allow the user to interact with this data and send updates back to your backend services,...
Downfalls
Should I now build Web Applications for everything?
Yes, absolutely :)
So what are the problems we might encounter with web apps? Surely there is a higher degree of complexity that needs to be created, maintained and executed. In general it is said that webapps are slow loading and this is true. When you enter a HTML webpage you only download whatever is displayed on that page. With a webapp you have to download the complete application code (think of downloading an *.exe file on Windows before you are able to start the application).
So how can we solve those issues?
- Complexity & Maintenance: This is an issue. If you don't have a full-stack team in place that uses your choice of Stack to solve everything (so having the necessary experience) I would not recommend building a web application. The KISS principle applies.If you worry about your marketing team (without webdev experience) having to maintain the page content - that is not a problem. Once you have your application in place you can e.g. use Markdown to create new content - all you need for that is some MS Word skills (see. JAM Stack).
- Slow First Page Prints: If all you need is some static web content going with a web application was hard to recommend as download speeds take a bad hit once you add application logic. Of course only for the first page load - once everything is in place the application can dramatically improve your user experience. Even if it is just loading some static content in a very elegant way. The issue is solved once you start using Server Side Rendering (SSR). Combining both worlds a SSR web application will first serve a static HTML version of itself and then start loading the application part in the background. The static version will be replaced by the interactive one as soon as the code download is completed.