I think today the web is trying to be two things. 1) classic text documents with links to other text documents. 2) a cross-platform runtime for desktop class apps.
Over time 2) has been increasigly shoe-horned into limitations of 1) and its all a giant cluster fuck now. Leave HTML to linked documents and give us an efficient runtime that we can plug into to deliver desktop class apps written in whatever language we want that works with a standardized runtime and UI language shipped built-in with every browser.
Why the hell cant we build web UIs With a standardized UI markup (not HTML), wire it with whatever lanaguage our company uses, and compile it down to WebAssembly and ship it to clients browsers? Instead we have to write these monstrosities in shitty JavaScript with virtual doms, and hacks everywhere. Madness!
HTML should never have grown into the mutated application runtime it is today. The presentational concerns for documents are different from application rendering. The javascript stack should have been something entirely separate.
I strongly feel we should create a lightweight HTML fork that is again document-centric and doesn't allow for all of this javascript nonsense. Something that doesn't allow for stupid custom UI or behavioural tracking. Just text, images, videos, and links. The painting algorithm would be dead simple, documents would load lightning fast, and we'd be confident there would be no ad malware.
If you haven't done it before, try teaching a non-programmer how to make and deploy a website. It's easy to forget where the sharp edges are because we cut ourselves on them so frequently.
I've observed that HTML/CSS/JS sets a minimum level of complexity that is a non-starter for most people.
I personally believe that most webpages could be written, arranged, and styled in formats easier than markdown (without a scripting language). But I could be wrong! Maybe nobody's done it yet because it's simply not possible haha
Insert my endless rant that most native apps are just interactive documents, that XML tree structures are a fine way to represent application state, and that native platforms like Linux would probably be a lot better if all of their apps rendered to some kind of DOM-like primitive instead of pixel buffers.
XML/DOM representations of graphical state are a lot closer to the Unix ideal that we have in the command line. A big reason why the command line is often more powerful than a graphical interface is because the command line allows users to easily wrap around, extend, pipe, scrape, script, and translate interfaces.
HTML is the evolution of that ideal -- a statement that graphical interfaces should be as flexible and as manipulable as a command line interface.
God, I am so tired of these arguments. We need to stop bike-shedding web technology. You will never, ever convince me to go back to server-side rendering for the type of work I do. Are there other domains where that would be the wrong choice? Absolutely.
The web is a platform and we should not treat these tools as one-size-fits-all. Use the tools that fit your use case; there's no use in talking about the how without the why.
Code once and run in all platforms is pretty much a myth no matter the framework you use, including the web ecosystem.
I've lost count of how many times I wished we could run in the browser a decent language like python or ruby. Or describe the data of documents in something more meaningful like JSON instead of HTML. And then there's the DOM, CCSS, and all the browser specific nonsense.
Can I just ignore this crap and code my applications already?
I can't help but think that people who want to replace HTML+CSS+JS haven't written a widely used web application before, because the idea seems so absurdly impractical and would become such an incredible time sink.
HTML kind of sucks as a GUI though. You have to work really really hard with Javascript to make it work semi-well.
HTML+HTTP works really well as a way to scale up client / server GUI over a high latency / low bandwidth network. That's its strong point; not that it makes for a good UI in terms of human factors.
There needs to come a point where we let html and javascript exist for static linked documents. And build something better for our applications. Java and Silverlight have failed spectacularly at this so that future does seem quite bleak. There is still some hope with chrome plugins I think.
What would be the language to use? JavaScript won early, so it's been the de-facto choice every since to the point where browsers probably don't even run other scripting languages with the script tag. The first major hurdle in changing all of this would be getting everyone to agree on what to use. Different languages are suited for different jobs. HTML is perfectly fine for static UI, which is what most sites need it to do. What would a better language or set of tools for the web even look like?
Stuff like this, that explores the document nature of HTML, should be standard on the web, instead of the current crazy trend of reinventing desktop applications in the browser.
Man, reading this just reinforces that DOMs and HTML are not "right" for webapps.
These frameworks, contrivances, and the resulting principles will spiral on, never solving the real issue: DOCUMENT Object Models and HYPER TEXT MARKUP Language are for representing linked documents, not stateful object based applications. It's right there, in the names.
I would like to see an alternative to the WWW altogether. WWW is no longer a collection of hyperlinked documents, which was its initial purpose but a multitude of technologies running on browsers that use HTTP in nonstandard ways because it's ubiquitous. HTML is getting obsolete, with the most popular websites being essentially javascript apps. Maybe it's time for a new system like Java to create cross platform GUI apps from the cloud, that is not constrained by the browser and HTTP's limitations.
We are all abusing the technologies originally developed for hypertext documents (HTTP, HTML, CSS, JavaScript) for building applications. If you today started working on a set of standards for handling what people currently build on the web proposing those technologies would be completely ridiculous, so ill suited are they for this job. And JavaScript is probably the worst of all, it is designed badly enough that there isn't even a standard way of defining modules or classes so you end up connecting shit structured in a 100 different ways.
Sure. That's nice about HTML, but too bad you lose almost every other quality thing because of it.
I don't understand why everyone is so hung up on HTML though. The internet is not HTML, the internet is TCP/IP and all the protocols that ride on it like HTTP.
Why can't we just leave HTML the way it is, use it primarily for making nice documents and come up with something new for apps? You know, instead of trying to shoe-horn everything into a spec that has to cover both apps and documents or anything in-between?
Why isn't there a standards committee for a kit like Silverlight or Flash? The runtime would have to be built once for each platform, but that's no different than HTML.
This all seems to assume that Javascript,css,html and the web 'stack' in general are reasonable and efficient ways to write robust applications. I fundamentally disagree.
Over time 2) has been increasigly shoe-horned into limitations of 1) and its all a giant cluster fuck now. Leave HTML to linked documents and give us an efficient runtime that we can plug into to deliver desktop class apps written in whatever language we want that works with a standardized runtime and UI language shipped built-in with every browser.
Why the hell cant we build web UIs With a standardized UI markup (not HTML), wire it with whatever lanaguage our company uses, and compile it down to WebAssembly and ship it to clients browsers? Instead we have to write these monstrosities in shitty JavaScript with virtual doms, and hacks everywhere. Madness!
reply