Why haven't we replaced HTML/CSS/JS?
I know the obvious answer is the backbone of the entire internet runs on it, but it being obfuscated to 3 languages and 1 of them being built in 10 days feels like a 30 year disaster, growing until it explodes. Thoughts?
15 comments
That language would need to exist, then it would need to gain adoption from all the major browsers. Then those updates need to be ubiquitous enough for devs to actually use for more than tech demos, without the need to fall back to HTML/CSS/JS anyway incase someone has an old browser. This happening in a decade would be fast. Look at WebAssembly, it's 9 years old and barely being used.
Fair enough. It's a problem that probably doesn't need solving either, it was more so just a question of could it, but to your point, it's that barrier of entry that's stopping it, I would assume.
2026 JavaScript feels nothing like 1995 JavaScript. Likewise, both HTML and CSS have been gradually improved.
Maybe all three are, in their respective current form, good enough. Replacing them would almost certainly be a net loss.
Maybe all three are, in their respective current form, good enough. Replacing them would almost certainly be a net loss.
That's fair. Maybe it's a nostalgia for Web 1.0, websites being ugly, but personable, that I would even offer the idea.
Are you thinking of things like Time Cube? Seriously, anything written 30 years ago could still be written today and would still run.
Standards are made by first-movers even if what they move is howling junk. Every technology has been immature when first brought to market. What we need to be looking at are the obstacles to maturation, which seem to be increasing.
Standards are made by first-movers even if what they move is howling junk. Every technology has been immature when first brought to market. What we need to be looking at are the obstacles to maturation, which seem to be increasing.
More vaguely GeoCities, Netscape, etc., and an ability to customize all corners of the internet that were yours to your liking. Just got me thinking if it could ever come back.
What are the alternatives? What is the one language that can do what each of HTML, CSS, and JS do now when used together?
There isn't one, but even if there was, I'm not sure it could replace the amalgamation of today. It would have to be in parallel, I think.
> There isn't one
That kind of answers your title question. Without a contender, there's nothing to replace them with. I do agree with the rest of your comment, though, it'd need to be something that could be implemented and used in parallel with the existing standards. Ideally something near isomorphic to them so that browsers can mostly just do a translation to get a good enough initial implementation, and then refine it over some iterations if the underlying HTML/CSS/JS models don't cover all the things in the new system.
Also, are you meaning a contender would replace all three with one new language, or would it be three new languages that are (somehow) better than the three existing languages?
That kind of answers your title question. Without a contender, there's nothing to replace them with. I do agree with the rest of your comment, though, it'd need to be something that could be implemented and used in parallel with the existing standards. Ideally something near isomorphic to them so that browsers can mostly just do a translation to get a good enough initial implementation, and then refine it over some iterations if the underlying HTML/CSS/JS models don't cover all the things in the new system.
Also, are you meaning a contender would replace all three with one new language, or would it be three new languages that are (somehow) better than the three existing languages?
Ideally, a contender would replace all three with one new language. My question is more so why hasn't someone built a contender, but the answer to that is also quite clear.
I've spent more time thinking about this than I meant to, but I can't think of a good way to combine those three languages into one without creating "three languages in a trench coat".
Each language fits a different niche. Assuming we're not going the Gemini "baby with the bathwater" approach and are retaining the capabilities of all three (more or less), you'll need three sub-languages that fill the three roles.
HTML is a content markup language and has, over the years, drifted increasingly towards being a semantic markup language (not full-on semantic web markup, but not the rather anemic semantic model it could describe 30 years ago). We've separated the formatting/layout to CSS for a reason, though you don't actually need CSS files or even <style> tags unless you want them. You can embed all that in the HTML elements as attributes. However, we separated that out (as an industry) for a good reason, if you embed it into the elements you have to update every page when you want a uniform change. That's a PITA, so you'll end up with separate markup and formatting anyways, at least if you want people to use your language for anything more than one off pages. And if you want adoption (and not the extremely low adoption of gemtext) then you'll end up doing this.
So you have two languages, content markup and formatting/layout. You can mash them together to be "one" language, but it'll be two sub-languages that aren't really the same at all, and we're just splitting hairs.
Then you get to JS. Its role is to be the procedural language giving you dynamic changes to the content and layout/formatting. You could make a declarative language for this, but those are (apparently, based on adoption) harder for people to reason about and use than conventional procedural languages. This gives us a sharp divide in our one language between the declarative portions and the procedural portion. And, again, you'll want to separate out this dynamic portions from the more static portions for better reuse.
In the end, you will likely have three separate file types even if they ostensibly contain the same language. You'll have content files, formatting/layout files, and dynamic content files, and some mechanism of including them into a page for rendering. And each will be described using a different sub-language of your one language.
This puts us right back where we started, but now we have 6 standards (ignoring the fact there are multiple versions of HTML, CSS, and JS already) instead of three.
So that brings us to the only way to move away from HTML, CSS, and JS that has a chance at actually replacing them: Three new languages that each fill the same roles as the current languages, but do it better. Potentially with greater uniformity of design between the three languages, but the sharp divide between the declarative HTML/CSS replacements and the procedural JS replacement will make this a very challenging language design problem.
----------
All that written, if you don't care about replacing them, you absolutely could do a weird mashup language and ignore all the reasons for separating the three out. You just won't get adoption outside of a niche community like Gemini has developed around their restricted formats.
Each language fits a different niche. Assuming we're not going the Gemini "baby with the bathwater" approach and are retaining the capabilities of all three (more or less), you'll need three sub-languages that fill the three roles.
HTML is a content markup language and has, over the years, drifted increasingly towards being a semantic markup language (not full-on semantic web markup, but not the rather anemic semantic model it could describe 30 years ago). We've separated the formatting/layout to CSS for a reason, though you don't actually need CSS files or even <style> tags unless you want them. You can embed all that in the HTML elements as attributes. However, we separated that out (as an industry) for a good reason, if you embed it into the elements you have to update every page when you want a uniform change. That's a PITA, so you'll end up with separate markup and formatting anyways, at least if you want people to use your language for anything more than one off pages. And if you want adoption (and not the extremely low adoption of gemtext) then you'll end up doing this.
So you have two languages, content markup and formatting/layout. You can mash them together to be "one" language, but it'll be two sub-languages that aren't really the same at all, and we're just splitting hairs.
Then you get to JS. Its role is to be the procedural language giving you dynamic changes to the content and layout/formatting. You could make a declarative language for this, but those are (apparently, based on adoption) harder for people to reason about and use than conventional procedural languages. This gives us a sharp divide in our one language between the declarative portions and the procedural portion. And, again, you'll want to separate out this dynamic portions from the more static portions for better reuse.
In the end, you will likely have three separate file types even if they ostensibly contain the same language. You'll have content files, formatting/layout files, and dynamic content files, and some mechanism of including them into a page for rendering. And each will be described using a different sub-language of your one language.
This puts us right back where we started, but now we have 6 standards (ignoring the fact there are multiple versions of HTML, CSS, and JS already) instead of three.
So that brings us to the only way to move away from HTML, CSS, and JS that has a chance at actually replacing them: Three new languages that each fill the same roles as the current languages, but do it better. Potentially with greater uniformity of design between the three languages, but the sharp divide between the declarative HTML/CSS replacements and the procedural JS replacement will make this a very challenging language design problem.
----------
All that written, if you don't care about replacing them, you absolutely could do a weird mashup language and ignore all the reasons for separating the three out. You just won't get adoption outside of a niche community like Gemini has developed around their restricted formats.
I don't think that there is quite an objective answer that can actually tell the true and full picture of why exactly we didn't changed the paradigm of the web development. I think that we can imagine it and, most of all, speculate on why certain technologies were never adapted or why people would never actually try to implement something that is actually better.
The first answer that I have is that it's an accessibility reason. All the technologies that you have mentioned are accessible. Everybody can learn, integrate, and implement and most importantly, they are fast to deploy. I think that it's also a universal language that everybody can speak. If all of a sudden everybody changes the tech stack, everybody will have just to learn a new paradigm to create websites.
Another thing that I might even consider (but this is something that is very much vague even to talk about), but I want to throw it out. I think there is a certain pride in creating so much code that it's still used even to this day, so replacing it is like saying that all my lifetime work just vanishes away. As I said before, this can actually not be the case. In the end, we are talking about things that are mostly static.
The first answer that I have is that it's an accessibility reason. All the technologies that you have mentioned are accessible. Everybody can learn, integrate, and implement and most importantly, they are fast to deploy. I think that it's also a universal language that everybody can speak. If all of a sudden everybody changes the tech stack, everybody will have just to learn a new paradigm to create websites.
Another thing that I might even consider (but this is something that is very much vague even to talk about), but I want to throw it out. I think there is a certain pride in creating so much code that it's still used even to this day, so replacing it is like saying that all my lifetime work just vanishes away. As I said before, this can actually not be the case. In the end, we are talking about things that are mostly static.
why haven't we replaced C?