My goal with this article is to share my perspectives on the web, as well as introduce many aspects of modern HTML/CSS you may not be familiar with. I’m not trying to make you give up JavaScript, I’m just trying to show you everything that’s possible, leaving it up to you to pick what works best for whatever you’re working on.
I think there’s a lot most web developers don’t know about CSS.
And I think JS is often used where better alternatives exist.
So, let me show you what’s out there.
↫ Lyra Rebane
As someone who famously can’t program, the one thing I like about CSS is that I find it quite readable and generally easy to figure out how I can change things like colours, fonts, and so on. Of course, anything more complex will still break my brain, but even the more complex elements are still at least nominally readable, and it’s often quite easy to determine what a piece of CSS does, even if I don’t know how to manipulate it or how to get even close to any desired result. It’s like how the fact I learned Latin and French in high school makes it possible for me to nominally understand a text in Spanish, even if I have never spent a single second studying it.
JavaScript, on the other hand, is just a black box, incomprehensible gibberish I can’t make heads or tails of, which in my mind goes against what the web is supposed to be about. The web is supposed to be an open platform in more ways than one, and the ability to make a website should not be hidden behind complex programming languages or website builder gatekeepers. The fact JavaScript is a resource hog and misused all over the place sure doesn’t help, either.
If you want to know more about the current state of CSS, the linked article by Lyra Rebane is a great place to start. I wish I had the skills to finally give OSNews a full makeover, but alas, I don’t.
CSS are definitions. JS is code gone wild running on clients.
Everyone should run something like NoScript to prevent Javascript from running by default. But yes, almost all websites have gone “lazy” and use a myriad of dependent Javascript, often times from several completely unvetted sources. And there’s zero reason for it.
A long long long time ago, it was “the way” to handle idiots like MSIE that decided to “go their own way”. And while I don’t like the “whole world has to run on Chrome” current mentality, the vast majority for gunk like Javascript has gone away. With that said, websockets everywhere and webassembly is just a “pile push” and will likely lead to a whole slew of bad things moving forward. But doing all that mess, plus Javascript??
Moving the “web server” to a custom foreign downloaded code base executing on your computer (via browser)…. wise?
chriscox,
You are close, but everything has a place in the “stack”
I would even argue JavaScript moving to the backend (Node.JS) has been a greater issue than polluting the client.
Yes, it helped novice “developers” to write backend code. However at best it is only 2x slow of native C++ (or Java) and has wasted billions of compute power in aggregate.
Anyway… The article should probably be titled:
“You no longer need JavaScript for Most Basic Animations and Transitions”
And that would be more agreeable. Back in the day we used to animate everything frame by frame using heavy frameworks like jQuery. Did it work? Yes. Did it require a decent machine for basic things? Also yes.
(I’m also guilty of this. But the alternatives were: Flash, JWS, or Silverlight)
Now CSS has progressed enough to build nice UIs without needing additional code. But that does not mean it covers everything. We still have HTML for page structure, Canvas for native rendering, SVG for scalable objects, WebGL for gaming or other complex graphical needs and of course CSS to style them. But that does not mean we no longer need JavaScript in general.
Model, View, Controller
or
Model View VIewModel
Are the modern UI paradigms, and here HTML/SVG/WebGL would be the “Model”, CSS would be the “View” and JavaScript would be the “Controller” (or the logic in ViewModel.
Yes, you can probably do much more in CSS. I would not be surprised if it had reached “Turing Complete” status. But doing control logic in CSS is akin to writing backend code in Node.JS (wrong tool for the wrong job).
sukru,
I had a node.js project that I would end up regretting for scalability reasons. It turns out node.js is a poor choice for things like multithreading and async for network daemons, even though it can technically do them. But we didn’t get a feeling for these problems until we already had a working prototype that we could benchmark. By that point the company was more interested in using the code already written than rewriting the daemon in a higher performing static language.
I’d say node.js does have some advantages though because you can write business rules in javascript that can be evaluated both client and server side without rewriting them and risking things being out of sync. I like to give users real time feedback, running business rules on the client provides a much better user experience than server side forms. But the caveat is when server and client side code are in separate languages, it limits code reuse between both. For some projects I’ll write a database driven rules engine that can be executed both client and server side. This makes it easier to do things like adding fields, but sometimes business requirements end up necessitating custom code anyway on both the server and client, which highlights the benefit of using one language.
Javascript is a natural choice for obvious reasons, but I suppose you could cobble up something in LUA or similar and link in an interpreter on both the server and client so you can reuse the same code that way. In the 2000’s I was thinking about making a new language that blurred the distinction between client and server. The full application would be written in this language and the “compiler” would emit the code needed by both the client and server. The IPC and security enforcement between these domains would be handled transparently for the developer. I still think it’s a neat idea.
Alfman,
This is how they get you.
There is also the other way around: Java To JavaScript Closure Compiler:
https://github.com/google/j2cl
Google’s framework allows you to write backend Java code, which can then be (partially) compiled into JavaScript to be run on the client.
But in either case, I would prefer to have a third language for validation, and maybe reinventing the wheel if necessary to make my own mini compiler. (Or use one of the off the shelf ones).
JSON schemas have validators for many languages, for example.
sukru,
We can probably agree that javascript’s main claim to fame is being natively supported in modern browsers rather than it’s merits. It’s class syntax is… unique (and not in a good way). However even though that’s the case, I don’t really mind javascript enough to avoid it, it serves it’s purpose. I don’t like some aspects of how javascript/DOM/events/etc get implemented in browsers. but that has more to do with the way browsers work than javascript as a language.
Alfman,
Because it does not have classes, but rather prototypes. In that manner the language is closer to Smalltalk (later Squeak, and Scratch, or even Objective C++).
The syntax is exponentially more powerful, as the prototypes can be dynamically chanced for effects not easily done in other languages.
(The class keyword that was recently introduced? It is an out of place syntactic sugar that makes some things simpler but overall design more confusing)
I wonder if WebAssembly has become a mature alternative to JS, where you don’t need JS anymore. Or at the very least significantly reduce it’s usage. A nice write up on this would be great.
I get a near religious experience reading this, very liberating. It’s spot on, how much of other people’s unvetted code do you really want running on your computer just to read text?
OlaTheGhost,
I’m sorry to inform but we are way past the discussion of having all code vetted on a system
Unless you are building specialized hardware for NASA, and maybe even then, your computer will contain codes from random places in various parts. The operating system, libraries, browser, UI are obvious ones. But the firmware in your devices, and even the CPU itself will contain 3rd party code.
(Yes, both Intel and AMD CPUs have “mini CPUs” inside that run supervisor code and closed operating systems. This is also true for many ARM designs as well).
JavaScript?
You can at least “see” the code.
sukru,
Thank you for your reply. No, I didn’t write my OS or bootloader myself. Not my browser either. You seem to have overlooked the part where I write “/…/ just to read text”. If my system is full of potential xz-doomsday packages I may not want to add more to the mix just to read news or a blog.
OlaTheGhost,
Of course you did not. But JavaScript (and overall browser) is a well known attack surface with many mitigations built in.
It is much less likely to infect your system, than say running an anti-virus like AVG that literally opened a root kit public to the Internet (they installed their own web server for some brain dead reason with terrible default configuration — Look up “Web TuneUp”)
OlaTheGhost,
Reading my reply again… the tone feels “off”. Sorry about that.
I can barely tolerate Typescript, can’t wait until people move away from Javascript