The way we currently design websites is through HTML5 and CSS3. This method, while mundane and tedious, is unfortunately the best solution. Why "unfortunately"? Almost hardly anyone I know in the programming communities that I am a part of, the Handmade community, ODIN and Haxe, actually enjoys working with HTML5/CSS3.
What is the problem with it?
There are huge numbers of solutions to the growing problem of adding more onto websites without solving the core issue. NodeJS has an ecosystem that endorses huge third-party dependencies, which is flawed for a number of reasons.
The fundamental problem is that there are:
- Too many solutions, making both developers' and designers lives more difficult. This may be good for competition but not so much for actually solving the core issue.
- Any lack of reasonable performance gains from using third-party libraries, which most often slows websites down.
- And finally, too many abstraction layers which complicates website codebases and makes it more difficult to debug. Server debugging is difficult enough, and it is not helped by the over-exaggerated OOP paradigm which is enforced by web developers, despite its blatant flaws – especially on the Web.
Websites are designed with the idea of communicating messages to potential visitors, primarily for marketing reasons, profit or otherwise. They are the bread-and-butter of communication over the Internet, but with the strong conservative naivety of web developers refusing to acknowledge the Web is anything but perfect, we have a difficult time presenting anything of value that may help ease the pain of web development, even if we are stuck with HTML5/CSS3 and the countless server-side languages that exist.
Perhaps one of the biggest problems with websites, and certainly more complicated ones, is the need for a content management system. Unless you are using something like WordPress, building a custom one seems far-fetched and unnecessary. Unfortunately, WordPress and most other CMS solutions tend to create a lot of overhead and bloat server resources quite significantly. Even with the performance crackdown in recent years by WordPress and the likes, they continue to prove that websites built on these solutions are just fundamentally slow.
Performance on websites is difficult to achieve unless you take advantage of WebGL, normally in conjunction with the <canvas> element. The reason it is difficult is because there are multiple ways to produce the same result from the use of JavaScript, often combined with jQuery in order to make dynamic features more useful. But, unless you are building very simple layouts and very little dynamic interaction, you will find more complex web applications will take up a lot of your memory.
A web browser can easily take up 1GB of RAM, the equivalent of a full-fledged 3D video game. How did this happen? How did the Web, so simple in its design, end up taking up half our computer's resources, when my 3D game runs significantly faster, in real time, without causing artefacts when some HTML element runs past its animation timer?
Let's face reality, people. The Web is a shithole, comprising of lowbie, wannabe called a "programmer", whose sole purpose is to ignite user's computers into flames. Web design to me as compared to real programming like in C++ or C#, is like comparing go-kart racing with aeroplane flying.
Perhaps I am being too harsh, but while HTML5/CSS3 is not exactly difficult to understand, it's tedious, boring and mundane, and destroys the programmer's soul.
How exactly do we solve this? Do we continue to use HTML5/CSS3 or do we scrap it entirely? Can we leverage the power of WebGL to make something unique or will that upset too many people who need the accessibility features of their web browser, assuming they can use one?
Accessibility features are important and should be taken advantage of where necessary, so unless you are building a fancy website with particle effects and shaders, trying to build a website from scratch using this method is a little redundant if you care about accessibility, which you should.
So, naturally that implies going back to option 1, HTML5/CSS3. But what if we can still remove it and have something generate it for us?
Problem solved! In theory, at least. What we need is some kind of a language that is macro-powered, that can generate this HTML5/CSS3 using an imgui-style API.
So, in theory, we could type something like this:
if (BeginLink("/")) {
Image("logo.png");
End();
}Which would translate to something like this:
<a href="/"><image src="logo.png"></a>This would make our lives so much easier, right? We no longer have to use the mundane language we don't really want to use, and instead use a language that can generate the HTML for us.
But, what would that language have to be and why would it have to be macro-powered?
By macro-powered, I'm talking about compile-time code.
In this instance, I'm referring to a nice language I have been using for a few years now, called Haxe. Although it has some issues (no language is perfect), it generates code for both the client and the server, making it a perfect tool for cross-target web development and allowing us to leverage its compile-time tools to generate our web pages as necessary.
But what about styles, though? In a language like Haxe, we can't simply generate CSS because that would be difficult to understand, right?
No problem, I say. Why? Because in Haxe, you can generate files at compile-time too. That means writing any multitude of files to disk. How this can be managed is somewhat of a separate problem but it is plausible in Haxe.
So, what does this all mean? It means we have a potential solution in Haxe, which hardly anyone leverages to its full capacity, to make a full-fledged website with all the design and server-based functions created in a single language.
Sound too good to be true? Well, perhaps we should go on this journey together.
In the coming week, I intend to start producing videos again, and this should be the start of a new project which I hope will garner enough attention for it to be taken seriously.
I will begin my videos sometime later this week once I receive my replacement microphone and will start sharing links.
