More than anything this reminds me of the fact that HTML has failed on a basic level, to keep up with the ways that users want to experience content, and that designers want to present content. The browser has no real concept of "page navigation" or "site navigation" with any kind of state, or the "current" navigation item, or of hierarchy, breadcrumbs, menus, or other core navigational concepts involving site and page structure.
With a few built-in "site structure" features in the html standard, the browser could do a large part of what developers end up reimplementing over and over again - both with and without JS. A large part of "knowing about usability" is just knowing how to execute these basic navigation features without goofing up on the many pitfalls available to you.
For example, imagine if there was some kind of Site Structure standard, or Page Structure standard. The browser could then generate standardized navigation elements with perfect UX on every platform, and sure, you can style them, but the basic functionality just works everywhere without having to make advanced javascript/html/css menus that take into account concepts like responsiveness, touch interface, or accessibility.
No thanks. Good languages start small and stay small. HTML is already bloated with tons of elements of questionable usefulness. It's a document presentation format, and that's all it should ever be. Does Markdown need knowledge of state and navigation and breadcrumbs and menus?
At this point, the choice is not whether the web should have apps, but whether they should use multiple frameworks that invent the missing pieces on top, or whether some of that should be standardized. For me personally, knowing HTML is small will be cold comfort if we are all using react-router or whatever in the future.
I can't speak for OP, but my issue with react-router is that for just a single project I had to significantly change things as they kept doing things in completely new ways. Once I gave up and used page.js (or some other non-react-specific solution), not only was the resulting code shorter and cleaner, it needed much less upkeep.
I'm sure there are situations where using react-router makes sense, but for me it was one of the few packages 'blessed' by the react ecosystem that gave me more trouble than it was worth.
I think the parent comment isn't a criticism of react-router, but rather suggesting that its features should be standardized in the HTML specs and supported natively by the browser.
HTML was originally for relatively static documents and still works relatively well in that domain. But for almost everything ELSE it turned into a convoluted mess, requiring UI rocket science to manage, and bloating up development. I observed it takes roughly 3x the staff to produce and maintain custom small and medium CRUD applications than the IDE's of the 1990's.
Some claim the added flexibility and easier deployment[1] of web based applications is worth this 3x increase, but usually that's tech staff saying that, not business owners. They want get-it-done-on-budget, not eye candy, if given a clear choice.
We have to come clean and admit that job security is keeping us technical people from being objective on this. A convoluted standard increases demand for specialists.
I suggest the industry form 3 browser-based mini-standards: A) Art/Gaming/Charts/Entertainment, B) Document-oriented (current HTML may almost be good enough), an C) "productivity" oriented data and CRUD.
That way each can focus on doing its niche right instead of trying to be one-size-fits-all.
[1] With a good stateful GUI-markup-over-HTTP standard, we probably wouldn't need local installs to get decent GUI's.
Not it's not. That's what it was created for, but clearly it's not anymore. People are not publishing just documents anymore, it's a fact that HTML is used for all sorts of things from simple sites to complex applications.
We agree it's not great, for all of these purposes but this ship has sailed, we need to deal with it. Either we create something different and good enough to not die in the water, either we improve HTML so that it supports what people are already using it for.
It really is. Just because some people have a uncanny propensity to mix concerns that shouldn't be mixed, that doesn't mean that a data structure is something else.
Even if you want to go way back, HTML is still a document presentation format with headers and footers and sidebars.
The linked video talks about documentation, which is a great example. Do you think I should have to download an app to read documentation? Should I have to go find my phone to read documentation because they didn't have enough time to also support desktop OSes?
Yeah, you're probably right. I should've said "web standards" rather than "HTML". Ideally, a page structure standard would use a terse file format that supports hierarchy like json or yaml.
> It's a document presentation format, and that's all it should ever be.
Here's another way to think about it. The web is competing with platform-specific apps (iOS, Android, macOS, Windows, etc.) to be the primary computing platform of the world (in terms of how the general population interacts with computers). Your position seems to relegate the web to a secondary/niche platform by definition. Do you agree that the web should be a secondary/niche platform?
Not OP but damn, I'd like that. Then maybe we could go back to native programs instead of Electron-whatever and use the web for stuff that has proved to actually work well on the web.
>Then maybe we could go back to native programs instead of Electron-whatever and use the web for stuff that has proved to actually work well on the web.
The web/web app paradigm isn't the reason Electron exists. Electron exists to poach web developers into app development, because native code and frameworks are hard. There's no technical reason why we can't go back to native apps, the friction is entirely due to culture and business, and an entire generation of developers who've never written a line of anything that isn't javascript or maybe python.
Also, being able to distribute and run software over a network is a good idea, and it's a logical progression of the purpose of the web, which is to allow open access to information and media. Code is no less a form of media than video, audio, images or text. A web that would let me read whitepapers but not let me emulate an Amiga would be crippled in its potential.
And that notwithstanding the fact that most "web apps" are just documents that use javascript as a front-end framework, and most people's complaints along these lines are aesthetic and emotional, rather than technical.
> Electron exists to poach web developers into app development, because native code and frameworks are hard.
I don't agree with the "poaching" statement, but I would argue that "frameworks are hard" should be replaced with "desktop gui frameworks are appalingly poor".
Webview-based rendering frameworks trade away native look-and-feel for a myriad of tools and processes and techniques and workflows and expertise that you simply do not get with plain old widget frameworks. GUI developers know this, and in particularly GUI frameworks vendors are well aware of this. In fact, check XAML or QML.
The missing cornerstone is native databinding. That's it. If we had native reactive HTML templating, 80% of the world's JavaScript could go away. The fundamental problem of the web as an application platform is that any element-state is trapped inside a single element, so you have to use JavaScript to dig it out and do something with it.
Most people don't, because it's completely useless without some JavaScript to toggle its "open" attribute. This was by design. The requisite interactivity across elements simply can't happen without a) databinding, or b) a whole turing-complete language. Since we don't have a, we use b.
I understand the point you're making, but the bigger reason that <dialog> isn't being used is because it's still locked behind a feature flag in Firefox since they haven't fully implemented it. For a recent project I was actually looking forward to using using it and would be more than happy to add the bit of JS necessary to toggle it, but ended up having to reinvent the wheel and make my own modal component.
If all we needed was a bit of JS to wire up state between HTML elements like <dialog> and <details> I think we would still be in a great place, even if we didn't have native data-binding. The bigger issue IMO is that in many cases native elements can't be used either because they fall short of the desired UX and can't be extended/enhanced (e.g. <select multiple>), or browser support isn't widespread enough (e.g. <details>).
> The browser has no real concept of "page navigation" or "site navigation" with any kind of state, or the "current" navigation item, or of hierarchy, breadcrumbs, menus, or other core navigational concepts involving site and page structure.
Why do you believe the browser should support that with primitives? Advocating for that kind of specialization lies somewhere between forgetting important and basic historical lessons on software engineering or an unsubstantiated belief that now everything will be different.
> A large part of "knowing about usability" is just knowing how to execute these basic navigation features without goofing up on the many pitfalls available to you.
You're leaving out a part where said usability principles lie somewhere between emerging requirements that are still under development or fads that are scheduled to be replaced with the latest and greatest promising idea.
Suffice to say arguing to force them into browser as primitives is demanding that they should be set in stone as is.
> HTML has failed on a basic level, to keep up with the ways that users want to experience content, and that designers want to present content
HTML was designed to be a way to create and link documents so that someone or a machine at one end of a distributed network could access it on a different network, not become an app platform. Everything else done beyond that is a perversion of HTML.
It would be interesting if there ever was a standard app container runtime that doesn't use HTML/JS/CSS. I guess that the last serious attempt at that were Java Applets which never took off.
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.
I think people are too hung up on the minor difference between html/xml vs json. The same folks who decry html as just for "documents" will at the same time push a "document" database because it's json. And now, we have GraphQL running on a server to turn our data into a tree shape to send to the client, but it's okay because it's json and not html...
>Everything else done beyond that is a perversion of HTML.
Here's a thread from the w3 mailing list discussing possible scripting languages for HTML back in 1995[0].
And here's Tim Berners-Lee talking about running code in HTML in 1992[1].
You're simply wrong that running code in HTML is a perversion - that was envisioned as a possibility since the beginning, it just took time to manifest.
What wasn't intended was for only one scripting language to dominate. When the script tag was released in HTML 3, the hope was browsers would support multiple languages, which is why it had a type attribute, but that never happened.
Is this not the exact definition of a cowpath argument? "We didn't make it to be this way so, regardless of what people are actually using it for, we will continue to assume we're right and the users are wrong"?
If HTML is no longer being used the way it was intended, is it unreasonable to request A.) A replacement, or B.) an HTML upgrade?
I quite agree. HTML/CSS/JavaScript is really flexible for sure, but it's because humans happen to be capable of parsing, and extracting information from, what would be chaos for machines. Is this flexibility really necessary? In other words: How many people jump to the Reader View button when reading a long article? What is the success rate of that functionality? Hasn't anyone realized this functionality wouldn't have been necessary if there were limited flexibility available to web contents?
Imposing structures on webpages as suggested would incur limitations, but it's a necessitated consequence of having content with machine-readable semantics. Think of how we encode characters -- we don't encode them by vector graphics of each character or two-dimensional array of pixels. But rather, we encode characters by concise code points. Yes, we lost flexibility by that. In plain text files we cannot represent different fonts because characters are simply represented with a sequence of code points. But don't the advantages outweigh the disadvantages by a large margin? We can read them in whatever font we like, we can `diff` text files... the list goes on and on. It's unfortunate that web ended up as a huge mess which machines can never reliably comprehend.
The problem is that with web being so many thing to so many people, there is not much everyone will agree on. A browser must be able to act as text document viewer, graphic editor, game engine, chat, and with more of different usecases being pushed pushed into that pile, the more you want browser to be assembler of the web, otherwise you'll end up with a pile of incompatible "page structures", each required by some of those applications.
With a few built-in "site structure" features in the html standard, the browser could do a large part of what developers end up reimplementing over and over again - both with and without JS. A large part of "knowing about usability" is just knowing how to execute these basic navigation features without goofing up on the many pitfalls available to you.
For example, imagine if there was some kind of Site Structure standard, or Page Structure standard. The browser could then generate standardized navigation elements with perfect UX on every platform, and sure, you can style them, but the basic functionality just works everywhere without having to make advanced javascript/html/css menus that take into account concepts like responsiveness, touch interface, or accessibility.