Different ways to use Javascript
Not every beginner knows this (stop reading if you’re not a beginner), but there are different ways to use javascript. I’ll outline these different ways and to understand them fully i think it’s helpful to have a small trip down memory lane (optional).
So be warned: this will not be about actually learning javascript, just about getting the big picture. The way we’ll be building web applications, we won’t need javascript until much later on (maybe 4–6 more posts). Also, this is an article in a series for beginners, read the previous about css first, if you haven’t.
Sprinkling javascript
I described in the client server article how the html gets into the client. That sort of defined the field were playing. This way i’m teaching here is all about generating html dynamically on the server. We’ll start with the server in two more posts, btw.
So if all the html and css is created on the server, where do we need javascript in this scenario? It is to make the pages more dynamic. More dynamic in what way? Maybe you remember from the css article that css can be used to make stuff dynamic, and that is true. But css can only do what css was defined to do. Javascript is a general programming language and can be used to do much more.
Common examples for this way of sprinkling javascript on the ready html include endless scrolling or search suggestions. Endless scrolling (medium has it on comments, google on image search), is when a list of results is returned, and when you scroll to the end of the list, magically more results appear. By search suggestions i mean those kind of search boxes that once you start typing, will give you a list to choose from (airports or friends etc)
These things and many more can be achieved quite easily with server side rendered html, by adding a little javascript.
Javascript Apps
So when do we need more javascript than that? Let me start by saying that in my opinion you very very rarely do, maybe in less than 1% of cases. Those are cases when you are trying to build a real application, say a copy of an existing desktop application (like 3d sketch) or a game.
I admit that this opinion may make me old school. And i encourage you to form your own. But it is relatively certain that full javascript apps are not simple, and that they are only a small percentage of todays apps.
The way this is done, in the extreme case, is to send the client an empty html document, and a whole bunch of javascript, the application. The javascript then builds the html in place and also uses javascript to make all subsequent changes. Css is applied in much the same way as described, by defining it beforehand and applying classes to the html.
In an even more extreme case, one can then detach the app from the net and make it a desktop app. This is for example how atom is build, but i wouldn’t call that web development anymore, even it uses similar techniques.
There is a not so extreme case, where part of the html is created on the server, and javascript is used to control only part of the page. We’ll go into that more below. This case accounts for more than the 1% i mentioned, and is used for updates like the facebook right hand ticker.
Upgrade possible
I imagine it can be a bit of a dilemma to have to make a decision on this topic (learn / not learn) when you feel you don’t have enough information. Maybe it helps that it’s not all just information you need. When professionals are not of one opinion (like here, which is the best way), probably both ways are valid and you can choose depending on what you are drawn to.
The way i prefer to look at it is this: All the skills you learn to create server side apps, are useful whatever you do later. They are not only relevant, but also slightly simpler. Better for a beginner. And because it is more general you have more options to go to afterwards.
But the killer argument for me is that it is becoming increasingly simple to upgrade. By this i mean that one starts with a server side app, and when the normal sprinkling approach is not enough to achieve what is needed, then one makes part of the app, or more likely part of some pages, into a javascript client app. This is more and more supported out of the box. So one keeps it simple as long as possible, and upgrades as needed.
How did we get here
You can skip the following reminiscing without missing too much. But to understand where we’re at, it helps to remember the beginning of the millennia. At the time the net was getting popular, but there were no tools or standard ways to solve the problem. Not like for desktop apps for example, for which there were lots of good tools and experience available.
So everybody was doing their own thing: Small and big, some with “standards”, mostly just open source exchange. By 2005 the problem was well known and good solutions were starting to become available and a common terminology was being used. The work itself became much more effective through available tools.
Then the web grew, many many more sites and specifically application were created, html and css got more standardised and that separation of concerns happened and for the most part there was consent and productivity. But no javascript.
Javascript had been very difficult to use, mainly because it was implemented in slightly different ways in different browsers. This made it very hit and miss to use, and so most people stayed away. Especially since they had their hands full without such extra worry.
But then came jQuery, a javascript library by google, that smoothed those differences out. It gained traction around 2010, because it worked the same on every browser, and suddenly javascript was useable. Everybody and their friend started writing jQuery plugins and doing crazy things in the browser.
This exploratory phase continued with techniques to do more and more actual work in the browser and was followed by a similar boom of javascript application frameworks, remnants of this you can still see here. We were living the beginning of the millennium confusion again, but this time on the client.
Out of the many javascript frameworks, angular and react have now crystallised as serious contesters, especially angular. But, mainly because the actual problem is more complicated, we are not at a universally satisfying solution. There is still a way to go (imho off course) and that is why i don’t recommend beginners to bet their career on this technology quite yet.
There is another side to this too: javascript was a hack when it started life. Through all this attention it got, the language has been revised and is getting better (this is a normal process for languages, and other systems). But few people will say that it is a good language, only that it has the benefit of running in the browser. The language improvement will surely continue, as will the frameworks, and i am sure in some years many of the technology will once again converge and mature. Until then, let’s continue with server apps :-).
