Let us be real, these days in order to make the frontend application running in the browser there are a lot of things to take into consideration and juggle around. Like state management, CSS itself is so complex these days with layouts, effects and animations. Then there is just the normal logic of clicking a button does action Y. Coupled with actually consuming the APIs for the data in question and binding that to elements in the UI. This just touches on what the application should do, in addition to all this there are packing tools, linters, test frameworks and overall structure of the codebase to manage and learn as well. Suffice it to say the ecosystem for current modern frontend development work is quite something alright.

Maybe that is the reason why so many new frameworks are also trending towards the simplicity of the early days of web development.

Simpler times

There was a time when the ecosystem was simple and meant for creators and everyone. It only consisted of HTML, and slightly later you could apply styling in CSS. So the HTML (HyperText Markup Language) specifies the layout of the page. The CSS (Cascading StyleSheets) were meant that you only need to define the style once and it will cascade down into page. Before CSS you had to style each element on its own on each page. This made the creation of pages really easy. The data was static though. You did not have a way to get up to date information other than to just refresh and navigate to new pages.

Then slowly but surely new features got added, like meta tags that could do things like auto refresh, give description to the page and more meta information about the specific page.

Dynamics are added

Suddenly there was also a need to get dynamic updates without refreshing the page, add interaction to the page and now you could make pages that were more jazzy and sexy than before. Also animations were done this way in this age. It is the dawn of JavaScript. So formally later there was the ECMAScript specification that other vendors had to comply with as the standard in addition to being able to add their own features to the JavaScript implementation.

This meant for the web developer there was code that needed to be written in order to be compliant to Internet Explorer, Mozilla Firefox, Google Chrome, Opera and any other browser out at that point running their own engine.

These engines all coalesced into only Gecko (Mozilla) and Blink (Chrome) for all operating systems and Webkit (Apple). So at least that is a nice thing that you can write once.

Dialects

As with other languages the trend becomes to write shims for languages in order to transpile into them. For example there exists CoffeeScript that transpiles into JavaScript. There exists SCSS (Sassy CSS), Sass and Less (Leaner Style Sheets) that all transpile into CSS. Of them the Sass is the older legacy one, and so you could argue there is only SCSS and Less. If you want to do your DevOps engineer a favour, please go with Less. It is implemented in JavaScript instead of Ruby and having a native compiled component which makes cross platform annoying as heck. Also supporting SCSS over the long run takes more effort than just running Less.

Of course there is also Purescript and Typescript. Of which Typescript is a good alternative to JavaScript as you get types and structure whereas Purescript is a functional approach that transpiles into JavaScript.

Distilled

So then came the day someone said what if we take out the JavaScript part of the Google Chrome browser, and only have that engine as a standalone? That would mean you could write server side with it, and that was what happened. The V8 Engine was taken out and distilled into Node.js. At the same time there was another team that took this and improved it on their own called io.js . Later on these two merged into Node.js.

Asynchronous

There was a lot of confusion as to whether or not JavaScript was single threaded and/or asynchronous or not? One could use setTimeout to run a function at a later time, is that not multi threaded and asynchronous? You could also block the main thread it seems with a while(true){} and suddenly the function would not be called. So what is going on here?

In the Node.js world they actually made it multithreaded so there it was easy, although there were several things coming one after the other.

Call me baby

First thing that happened before anything else was passing along a parameter called the callback of a function that will be called at the end with a certain amount of parameters. This function could take another callback and thus was created the callback hell.

Promise me

To make peace in hell there first there came the Promise/A+ spec. This meant you could write things in a sequential order in the sense that it was a block of events getting resolved one after the other.

Async/await

Then came the full async/await syntax. This meant you could designate the function as being async and within you could await other async functions.

This coupled with the Promises could lead to some confusing situations, what happens to async functions getting called twice from Promises in different parts of the code?

Can you imagine mixing callbacks, promises and async functions? mind blown

Fast-forwarding 25 years

Today there exist so many frameworks that model the backend in the frontend, caching, state management and even SQL. CSS is so complex you have animations in there now, complex calculations and there are whole demos that make paintings with just CSS and some HTML tags. I can understand the need for getting back to this simpler time and for people to do things in what is now called VanillaJS.

#devlife #devops