If it was a result of a single very well thought through vision and developers were expected to be committed to conforming to the latest API (think Apple’s iOS runtime or the like), we could maybe expect the <thread> and <comment> tags, we could demand there to be The One Correct Way of doing anything, that the “fat” is trimmed quickly and features go from deprecated to gone in a year. However, it is a product designed by committee (in fact, by multitudes of various committees) that has largely maintained backwards compatibility for decades, it is a free runtime that grew organically from what was supposed to be a basic hyperlinked document layout engine but now powers fully dynamic applications rivaling their native equivalents yet still has a pretty low barrier to entry for new developers, and as such it’s remarkably robust.
Yes, some applications tend to have a large amount of markup for what seems like simple features (the Slack’s input box example). However, the alternative is that browser vendors bake it all in, and then every app is stuck with the opinionated way they think is right. Perhaps some amount of chaos is healthy.
We have <!doctype html> but why not add other doc types as time goes on? Instead of shoehorning features you could have a <!doctype new-html> which would opt a web page into the ability to use newer features like newer elements or cleaner APIs
There is also the “use strict” directive in JS (which any script tag with type=“module” runs in now, slowly eliminating this need) that would opt your script into a stricter form of JS. You could even do it on a per function basis. We could have something like that for other features or stricter qualifiers etc.
We have done this before successfully and broadly, I think it’s time we revisit the usefulness of doing this again
We already have similar sofware development patterns, but I wonder what a Web API surface would look like when fully embracing a similar modular mindset.
Pretty easy, we should have had 2 standards, one being "Web for applications", built on a VM, stdlib, bytecode, RPC, UI framework and standard library of controls, ... And "Web for web pages" which was a solved problem pre-HTML5 days.
Java and Flash (although very problematic from a security point of view) were probably better bases on which to build "Web for applications" than HTML5+/CSS3+/JS/WASM will ever be, but it was intolerable for Google/Microsoft/Mozilla to hand the keys to Oracle/Adobe for that. It's all politics, and it's all worse and more complicated and more inefficient as a result.
The browser is really just a cross-platform platform for building applications.
Was Java any worse from a security point of view than what we have now?
The DOM cannot assume that it's just for building declarative applications, it needs to support imperative functionality too... IMO, the custom Web Components API solves the declarative problem very neatly, much more neatly than React or any other declarative framework I've come across.
I think it's wonderful how the DOM API has evolved slowly over time to meet user needs and it would be foolish to think we can just redesign it better from the bottom up without sacrificing some gems.
I think the people complaining about it are stuck in some utopian mindset. They have a specific frame of mind and they look at the DOM through the lens of a limited number of use cases which are relevant to them. They hold rigid, blanket beliefs around concepts like "Functional programming, side effects, reactivity" but these beliefs are siloed around each concept; they neglect the fact that the intersection of multiple approaches can transform the problem and radically alter the equation... For example, the modularization of Web Components and associated lifecycle methods, greatly reduce the dangers of imperative programming within component boundaries.
It's good to be aware that both strong acids and strong alkaline solutions are dangerous on their own, but one should recognize that mixing them together could completely change this fact.
The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS. That alone would wipe out an incredible amount of complexity and if done right would make web dev as an experience vastly more pleasant.
Well, I'd prefer if it provided widgets that can't be skinned. :-) The theming should be the user's choice, not the app designer's.
> That alone would wipe out an incredible amount of complexity and if done right would make web dev as an experience vastly more pleasant.
I don't really care so much about the web dev experience as the web user experience. My experience as a user is greatly degraded by a bunch of web devs full of bright ideas about how to make their apps look, rather than using predefined widgets whose look is determined by me.
> Much of this complexity comes down to primitives being too primitive for the use case of web apps.
I totally agree with this, although I disagree about what the better alternative is. In my view it is partly this issue that's led to the disappointing profusion of "skinning". In desktop app toolkits you use a tree view, or a button, or a dropdown, or whatever. That widget's "identity" is based around functionality and its look and feel are not controllable by you as the app author. Instead, they're determined by the user's platform (color/font settings, window manager, etc.). That's a better model for users.
Still, it's quite sad how long we had to wait for stylable checkboxes.
I cry at the ways we are doing and defining column tables.
It already does literally that. Have you heard about <form>? These common widget libraries seldom last, and that's because people want to differentiate on style in ways that go beyond a CSS skin.
I believe that some sort of a constraints language would've been a lot better at describing page layout. And stuff like Web applications simply shouldn't exist. These should be applications that use native UI toolkits while relying on Internet for moving data, not presentation.
Users are usually unhappy with Web applications because of the way browsers restrict useful functionality and programmers struggle with workarounds and bloat of browsers to accomplish simple things.
I AM SOLD
HTML5 input and form validation are still a broken nightmare that can barely be patched by adding copious amounts of JavaScript.
Sometimes I prefer the raw simplicity of writing your own layout code. You then basically just need X/Y coordinates, anchor points and dimensions of the screen and the elements on them. The rest can be done using simple arithmetic. The good thing about this is that you can do 95% of what people use CSS for, while using a handful of consistent methods. Wbile this to the uninitiated requires some introduction into how to think in a coordinate system, the simplicity can be refreshing.
Meanwhile in CSS you have a organically grown complexity of features where sometimes things that should be simple are hard, often because the elements that should be styled have default attributes with subtle differences which people aren't aware of. Only the minority could tell you the differences between display: inline, block, inline-block, contents, flex, grid, table, rable-column-group, etc. But elements may have them set per default.
I get that it is hard to simplify CSS for reasons of backwards compatibility, but sometimes I wish that instead of adding on top someone had had a long hard think about how to solve the problems elegantly and with consistency instead.
Or, you know, provide a set of usable controls that provide useful functionality out of the box and provide a set of useful APIs so that people can either extend those controls or create their own.
Web Platform provides neither. Compare that to literally every other UI toolkit under the sun. Turbo Vision from 1990s was a better toolkit than anything the web has to offer.
...hell, native apps are still more likely to be crap than not. Good UIs are hard and programmers are lazy; the big advantage of web apps remains the difficulty of an app completely crashing the browser due to sheer developer apathy.
Not really. The Web is owned and operated by Google. They can literally do whatever the fuck they want with it. (Any "standardization" process is less then a formality at this point.)
That said, if you want a non-DOM framework, surprisingly Google already provides it. It's called Flutter and it has the option to use a canvas, no DOM. You can see a large complex example at
Go there and type in NYC. You'll see text and images popup over the earth, etc. You'll see a toolbar and menus and a status bar etc... Click settings. The stuff that appears is all canvas. Click the Data Layers icon. The stuff that appears as all canvas. I think they finally made the search input box an input element for the reasons above but the rest is canvas.
Also note that canvas based input is also why Google Docs has so much trouble with emoji and non-English input.
It's probably safe to say that the majority of the dev workforce in the last 2 decades started their career with learning HTML/JS/CSS stack, and it's understandable why they like it. It doesn't make this stack any better for creating apps, no matter how many abstractions on top we place.
It's true, what people think of as native on the web are merely incidental from its history, not some ironclad law of how to make interfaces.
It's far from the only thing it has issues with; I've found obviously broken UI patterns within a couple clicks of opening Earth's map view:
- right click doesn't appear to work anywhere (except input boxes), even on elements that have direct equivalents in other Google sites (like the account switcher),
- when you click the account switcher, as long as its open, the rest of the site ignores the mouse events; attempting to drag the map screen doesn't close the switcher, hovering over buttons doesn't change the cursor etc.
> right click doesn't appear to work anywhere
I hate this and it's the default for a canvas app since the app would have to implement doing something on right click where as in the browser it's the default. Unfortunately, an HTML app can disable right click too :(
In fact, I hate that issue on all native apps. Things I want to select/copy/lookup are not selectable/copyable/lookup-able. As an example, Sublime Merge, a native app, quite often I want to copy a path but there is no option to do so. Every place that displays a path would need custom code (or a shared control) to make the path copyable. HTML doesn't generally have this issue as it's opt-out not opt-in for being copyable.
I'm not a fan of Flutter or other canvas bases sites. Emoji didn't work for like 3 years in google docs after their canvas change. It works now but not always.
It's worse too in that it doesn't matter if flutter eventually fixes these issues. Every app needs to be update. That's not true with HTML where the browser updates to support "insert password into input type=password" and it just works. Even better, an extension (1 password) can insert the password but it can't on a canvas based app.
Surely the "loose" standards encouraged neat hacks that at some point were encoded as best practices and then standardized. Maybe that would tempt us to want to "cut the cruft" but a) people probably thought that many times previously and b) backwards compatibility is probably more valuable than one would think.
I think that scale of "silent" users compared to proactive devs would be the most surprising number. Like for anyone who is "Rethinking DOM from first principles" there is probably like 10000s of randos editing ecommerce html templates, exporting results into tables and dataviz or making small uis for some internal system.
It also makes the conversation about WASM even more bizarre. Most college educated developers are scared of the DOM. Yes, it’s fear the emotion and it’s completely irrational. Trust me on this as I have watched it as a prior full time JS dev for over 15 years. Developers are continuously trying to hide from the thing with layers of unnecessary abstractions and often don’t know why because they have invested so much energy in masking their irrational nonsense.
Other developers that have not embraced this nightmare of emotions just simply wish WASM would replace JS so they don’t have touch any of this. This is problematic because you don’t need anything to do with JS or the DOM to deploy WASM, but it’s a sandbox that ignores the containing web page, which is absolutely not a replacement. For WASM to become a replacement it would have to gain full DOM access to the containing page. Browser makers have refused to do that for clear security reasons.
So you get people investing their entire careers trying to hide from the DOM with unnecessary abstractions and then other developers that want bypass the nonsense by embracing that thing they don’t know they are yet afraid of it.
That is super fucking weird, but it makes for fun stories to nondevelopers that wonder why software is the way it is.
Very few people are "scared" of tree models.
The problem of working with the DOM is that it's:
- 90s JAVA-like verbose unwieldy API that requires tons of boilerplate to do the simplest things
- Extremely anemic API that is neither low-level enough to let you do your own stuff easily, nor high-level enough to just create what you need out of existing building blocks
- An API that is completely non-composable
- A rendering system that is actively getting in the way of doing things, and where you have to be acutely aware of all the hundreds of pitfalls and corner cases when you so much as change an element border (which may trigger a full re-layout of the entire page)
- A rendering system which is extremely non-performant for anything more complex than a static web page (and it barely manages to do even that). Any "amazing feats of performance" that people may demonstrate are either very carefully coded, use the exact same techniques as other toolkits (e.g. canvas or webgl), or are absolute table stakes for anything else under the sun. I mean, an frontpage article last week was how it needed 60% CPU and 25% GPU to animate three rectangles: https://www.granola.ai/blog/dont-animate-height
> So you get people investing their entire careers trying to hide from the DOM with unnecessary abstractions
The abstractions of the past 15 or so years have been trying to hide from the DOM only because the DOM is both extremely non-performant and has an API even a mother wouldn't love.
DOM access is not quite as fast now as it was 10 years ago. In Firefox I was getting just under a billion operations per second when perf testing on hardware with slow DDR3 memory. People with more modern hardware were getting closer to 5 billion ops/second. That isn’t slow.
Chrome has always been much slower. Back then I was getting closer to a max of 50 million ops/second perf testing the DOM. Now Chrome is about half that fast, but their string interpolation of query strings is about 10x faster.
The only real performance problem is the JS developer doing stupid shit.
This is easily avoided: use 'outline' instead of 'border', or just keep the border width fixed and change the border color to/from transparent.
Another issue is people basing their fears of things in the past. Yes, the web was more difficult to do fancy things but often they're trying to push the web to do things it just couldn't do back then. Now you can using basic, built-in functionality and it's often easier that way.
My favorite part of web dev is working directly with the DOM, vanilla JS, and using minimal dependencies (if any).
I feel like the web equivalent of an assembly programmer these days, but apparently nobody is interested in hiring for this sort of thing anymore.
To become a total replacement, as in no-JavaScript-at-all-needed, sure, WASM would need to be able to access the DOM. But to to replace JavaScript as the language you’re writing, you can easily generate DOM bindings so you trampoline via JavaScript, and people have been doing this for as long as WASM has been around.
Giving WASM direct DOM access does not enable anything new: it merely lets you slim down your JS bindings and potentially improve time or memory performance.
> Browser makers have refused to do that for clear security reasons.
Actually, they’re a long way down the path of doing it. They’ve just been taking their time to make sure it’s done right—they’ve headed in at least three different directions so far. But it’s been clear from just about the start that it was an eventual goal.
What is the point of WASM if it introduces substantially increased overhead instead of reduced? If you cannot talk to the DOM without full round tripping then you should just cross compile to JavaScript.
The entire point of frameworks like React is to avoid the problem, by automatically creating and applying the patch for you.
It's not irrational; quite the contrary.
Because only javascript should be allowed to screw up that badly.
If finally WASM gets a cheap and easy way to manipulate DOM, I think even more stuff will move towards web tech like Electron and hopefully Tauri in the future.
While the web can be great for RAD, the native side gives you raw control when you want it. And actual desktop UI widgets, like table, list, and windows.
Their API is probably the problem. Not modular so makes the mess.
Options to modularize them:
DOM, concept of interfaces/behaviors rather than inheritance leading to huge maps. Let say for <textarea> we may have separate "textarea" interface:
element.tagName
... and the rest of DOM-as-a-tree methods ...
element.textarea // <textarea> specific interface of its behavior
element.textarea.select(startEnd) // interface method
element.textarea.selectionStart // interface prop
element.textarea.selectionEnd // interface prop
element.textarea.rows // interface prop
element.textarea.columns // interface prop
...
section {
color: red;
// ... and other basic CSS 2.1 props
display: grid(
rows: ...;
columns: ...;
align-items: center;
justify-items: start
);
}
As sooner we will do that - the better. API is on the brink of collapsing / combinatorial explosion, indeed.
I also think that if we could roll back time and had the knowledge of today, instead of fixed elements with user-agent styling and hard-coded restrictions, I would've crafted a system of arbitrary nodes that can have modifiers stacked on them.
So instead of
<ul> you could use <Features list>. This would minimize the very different but basically same CSS properties as well and trim out A LOT of HTML tags. Think <Comment collapsible link> instead of wrapping a <details> in an <a>.
That's basically how React and Vue started out with the component system, but I'm thinking more of a GameObject & Component system like with Unity.
Features {
display: block;
padding-left: 1.5em;
list-style-type: disc;
}
Feature {
display: list-item;
}
This comes in very handy with XML.
Web devs have moved the state out of the document into JS variables and have been piling bloated, short-lived crap on top of those variables ever since.
If you actually keep state in the document things become rather simple. Scripts themselves become stateless and do not require direct dependencies on one another. Data can be queried across the page with CSS selectors. Many visual transformations on data can be handled in CSS as well. There is a well-developed system of events to handle interactions, which removes the need to handle user changes, AJAX and WebSockets separately. You gain the ability to dynamically examine and modify the state of your "application" simply by pressing F12 and changing things in the elements tab.
While it's definitely possible to imagine better ways of dealing with documents, layouts and so on, seeing how JS frameworks handle state makes me fear any "improvements" on this front.
<button i-was-clicked="false">
<button i-count-clicks>
In the real world though, backwards compatibility reigns supreme. Even if you do go and make a better thing, nobody will use it until it can do the vast majority of what the old thing did. Even then, switching is costly, so a huge chunk of people just won't. Now you have two systems to maintain and arguably an even bigger mess. See Win32 vs. WinRT vs. Windows App SDK or however many else there are now.
So if you're serious about improving big mature platforms, you need a very good plan for how you will handle the transition. Perhaps a new API with a compatibility layer on top is a good approach, but the compatibility layer has to have exactly 100% fidelity, and you can never get rid of it. At the scale of these platforms, that is extremely hard. Even at the end of the day, with a huge compatibility layer like that, have you really made a better and less bloated system? This is why we tend to just muddle along - as much as we all like to dream, it's probably actually the best approach.
The opposite would make more sense. Have a transpiler or something to the 'old' API (very natural, given it can grow with the new API and you don't have to implement the entire 'old' API), while new apps can slowly transition the 'new' API.
This might in fact be a valuable insight, I never thought of it.
Alan Kay on web browsers, document viewers, Smalltalk, NeWS and HyperCard (2021) (donhopkins.medium.com)
234 points by gjvc on Jan 8, 2023 | hide | past | favorite | 272 comments
https://donhopkins.medium.com/alan-kay-on-should-web-browser...
Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook
Alan Kay Wrote: Actually quite the opposite, if “document” means an imitation of old static text media (and later including pictures, and audio and video recordings).
It was being willing to settle for an overly simple text format and formatting scheme — “for convenience” — that started the web media architecture off in entirely the wrong direction (including the too simple reference scheme c.f. Doug Engelbart and Ted Nelson). Circa early 90s, it had the look and feel of an atavistic hack. I expected that Netscape would fix this rather than just try to dominate what was there (I expected a better architecture both for “thinking about media in the age of computing” and also something not like “an app” but more like an operating system to deal with the actual systems requirements, demands, and scalings of the world-wide Internet-in-progress).
[...]
But you can’t fix that by adding new APIs with plenty of new concepts. You’re just making things larger and more complex. A few things may be able to live entirely inside the new, clean, modern API, but everything else (including practically everything that came before), will either need to ignore the new thing, or incorporate it (and pay the costs of bridging/composing things that weren’t necessarily designed to work together.
I say figure out how to actually remove old, bad stuff before adding a bunch of new stuff.
I like html/dom/svg/css. There are a couple rough edges. Half of them are from the last time someone tried to rewrite the whole thing (all the namespace aware dom methods)
It's like writing an entire diatribe about how it sucks that people can insult you online, and how that should change ... and not even mentioning the benefits of freedom of speech.
They'll make you a minister in the UK for that.
I don't think what the author is talking about is necessarily against either. HTML5 can continue its evolutions while "HTML6" (or something completely separate) exists alongside the traditional DOM, like the <canvas> example they reference or like WASM exists alongside JS. From this perspective, the article is about why it's a worthwhile time to make the new thing rather than why the new thing won't also have baggage in 20 years or why we should just throw everything current out the window as part of supporting the new thing.
That is to say, you aren't necessarily simplifying things. You are throwing away some of the things that somebody needs for what they do.
It may, in fact, be time to do this. I can't say. Odds are very high that you should, instead of throwing out some stakeholders as you try to shift something, you should invite the stakeholders you think you can more effectively serve to a new thing.
I hate to say it, but perhaps the browser needs a completely new standard designed for shipping applications? Something akin to what's discussed in the article - a simple but robust layout system built with a flexbox-like API and let us bind shaders to elements. We don't need css if we have shaders. And I don't think adding more and more features to current api's is gonna solve problems long term.
Flexbox also isn't great at all for many, many use cases - its performance absolutely tanks outside of the use case it was designed for, specifically a 1D flow of blocks along an axis. If you want a grid layout, choose the grid layout algorithm.
Any system here must accommodate extremely heterogeneous requirements, so it will inevitably become "bloat". One alternative future you could envision is based on WASM and WebGPU, where each site is essentially an app that pulls in whatever libraries and frameworks it needs to do its work, but that's also pretty far off, since there is not sufficient standardization of the protocols used by WASM UI frameworks.
Not only that, a new system will get completely coopted by the likes of Google for their own purposes. The result of what is built is in large parts a function of the culture that builds it. And I for one have zero interest in the current tech culture building a DOM 2.
Yes, I am generally weary of rewrites.
We can. Just every now and then some new way of working becomes popular, and at some point combining them with older ones will become undefined or unsupported.
In all seriousness, isnt this what Java is for? Why would you need to treat a web browser like a virtual machine?
There are many reasons. Performance, ability to bring concepts from other domains, ability to do things browser has no api for, ability to provide controlled experience and behaviour that goes beyond common browser usage.
The author critiques a ~50-year-old set of tech that has been developed piecemeal over those ~50 years to cope with a vast array of different goals and priorities. And proposes their own toy tech as a replacement, with apparently no sense of irony.
HTML was never designed for web apps, but it powers billions of them. CSS was never designed for complex dynamic UIs, but it does the job. If you seriously think "hmm, well this is shit, I can do better" then I invite you to take a seat and actually look at what this shit tech is doing, and maybe step down the arrogance a bit.
The problem is, as always with tech that survives a few years, backwards compatibility combined with mission creep. The author ponders HTML6 removing some redundant stuff. The problem is that you can't remove or change anything because doing that would break 348574793 websites and the people who rely on that stuff working exactly as it does now will complain. Meanwhile people are demanding that they can build 3D models using the same stuff that was originally designed to serve static written documents.
And, just while we're there, the answer to replacing the DOM is not to implement it in shiny new browsers. The browsers aren't the problem, or a route to change. You'd need to get every single website to change. Even the ones written by the company owner's nephew, who then moved country and doesn't talk to his uncle any more, so the website is a bit outdated but no-one knows how to fix it any more. There are approximately 3498573495645 of those.
HTML, CSS, JS, SVG, the DOM, WASM, all of that is miracle tech. Learn from it, study it as an exercise in longevity. Instead of complaining about CSS, learn why it was designed that way, why that particular set of ugly compromises came about. I promise that every single part [0] of all of this tech was debated for weeks by a large room full of very, very, smart people who came up with this solution because it was the only way forward at the time.
And mate, have some humility.
[0] OK, the original first version of HTML was probably not this, and was hammered together by Tim Berners-Lee, who probably never imagined that this would happen to it.
I bet that room never smelled of sunk cost fallacy
This is why "referer" is still mis-spelled in HTTP. To correct it without causing problems, you'd need to alter the code on every router on the planet, simultaneously. It would literally be easier to change the dictionary and every document with the word "referrer" in it.
So, yeah, there's no sunk cost here. It's more like sunk foundations - you're building on top of what has gone before, and you can only build up.
To this I say: go away and leave HTML alone if you want to build some application from first principles. The web's first principle is that HTML should have text. Hyper TEXT MARK-UP language.
Yes it can. clip-path does just that.
He probably means will-change.
Also, didn’t they effectively invent rendering in canvas (for sheets) about 10 years ago? If they did that, but they still didn’t abandon the DOM, they might have their reasons.
And we need to stop relying on JS so much.
Given that even newspaper websites are now built as applications, we should accept that the web is an application platform (with one of those applications being displaying articles) and rework HTML as an application display language. And we need to start relying on JS more.
(Specifically, we should reimplement most traditional HTML elements and CSS as web components on top of a basic core web runtime. Then we could have a small standard for the core web that was practical to implement - just a very minimal layout engine and a JS interpreter - and everything else could be in the "component library" rather than something browser makers had to implement by hand. And then pages that want to use their own components or some other third-party components - which is most pages these days - could skip all that cruft)
This could be what we want, but I can't help but think about what we've lost.
The users want to get a document, not an app. That's what the web was made for, documents.
So because some websites do shitty things, we should all throw out the standard way of displaying information on the web? Guide me through that line of reasoning. Why are newspaper websites, out of all the websites, the ones which should determine how we do things?
The web is getting smaller and smaller, being dominated by the bigger players (Google, Microsoft, Apple, et. al) for whom pushing opaque web standards and "applications" benefit only them as gatekeepers.
While it's still entirely possible for people to still build websites, search engines like Google don't prioritize them - leading them to never being discovered. 90% of the web is still the 'small' web and we can't ever discover them because they're not being indexed by Google (why should they? Most of them don't include Google's tracking js scripts ['analytics']).
The web was never supposed to be like this. It's turned into a massive surveillance engine for the big corporations.
I'll leave this here: https://wiby.me
It's a completely valid view, and none of it is backwards.
What's backwards is trying to bend a system barely capable of displaying static content to create apps.
I remember the older days (2005-8) when we would dump a load of HTML from the server-side and kept javascript (for the most part) managing the layout and, not to mention, coding the painful differences between browsers.. even IE6 to IE7.
As Javascript (likely thanks to jQuery for starters) got better with AJAX and supporting different browsers with less code, it seems Javascript transitioned to be a owner of data with events and triggers. As for the serverside, transitioned away from returning HTML but XML or the common Json data.
Away from jQuery (or alongside it) we ended up with Javascript frameworks leading to bindings or automated refresh of data with template views, etc. Things like mustache.js to knockoutjs to angularjs.
Now - its React, with node package managers, even grunt... to name a few... appear to be needed tools for web development these days. Its like we are just HIDING web development to an application. Underneath it all still remains the basics of HTML, CSS, Javascript -- and its relationship with the serverside language.
I will admit. In the early days of HTML development.. I hated it! Its not the HTML side of things, but the tools I had to use like Classic ASP or supporting different browsers. If we do web development today like its 2005... with modern programming languages and web browsers, "old school" web development is a joy.
In the last few years, I jumped back to the serverside generating the HTML again. I can still do "simple page" applications with AJAX returning a portion of HTML, etc.
When I explain this reasoning with other developers, I get a confused look on their face. I try to explain to them that the backend code has not changed. Its just an extra layer of returning the data back as HTML, rather than Json. It sounds like more but all it does it organise your HTML templates on the serverside, rather than just having it all done on the clientside.
Since then I have added htmx to the mix, which IMO compliments this original approach. I have made successful projects with it though I dont think I have won the co-workers. I dont think its because its the old school way or htmx -- its just they are so accustomed to the modern approach of web development.
This is what I always bring up to web devs who think theyve captured the "write once, run anywhere" dragon
> We spent a decade rebuilding the browser by hijacking routing, manually syncing state, rebuilding forms and transitions in JavaScript to match native app expectations. Now the browser has caught up. It's time to stop the hacks and build on the web again, but properly.
We've been "holding the browser wrong" for the past 10 years.
Unless you're arguing that we should stop cramming app-like behaviour into a system that doesn't support it. Then I'm with you.
We can complain how much we want, but the stream of shit, web-shit included, cannot be stopped or reversed. Brace yourself for more.
This is the way I lean too. So much of what web apps do is just reinventing the wheel of desktop GUI toolkits, only worse, because each one does it in its own way, rather than all having a consistent look and feel.
I was on the mobile app side, as possible way to turn the balance around, but then everyone started shipping Cordova and Ionic apps.
And now leave a comment for when I inevitably forget again.
So maybe we can have <!DOCTYPE app>, which lets you use a new set of APIs focussed on applications, but is otherwise in the same "shape". JSX type syntax.
This way it's easy for say newspapers to offer both an app format as well as a "lite" document format. Instead of their current offering which is a app shoehorned into a document and then a messy lite version.
Users who use noscript can, instead of blocking scripts wholesale and then whitelisting the good ones, request by default the lite document format. i.e <!DOCTYPE html>.
We don't have to force a round peg into the square hole <!DOCTYPE html>. Let's make a new round hole <!DOCTYPE app> but keep using the amazing deployment platform.