Client-side includes would have been useful. Could have mostly avoided the need for frames and iframes, which would have saved time and effort.
XHTML was a big distraction. I wish the whole thing had been avoided.
Dynamic HTML was really cool at the time, but the divergence between Netscape 4 and IE 4 was a real pain — I wish they had agreed on standards earlier.
Lastly, the way Microsoft screwed over developers when they 'won' the early browser wars, and then abandoned work on IE for 5 years after version 6, which left the web to stagnate. I wish someone could go back and force the fuckers back into the game.
Using HTML to describe documents and letting browsers handle the UI rendering, instead of providing UI primitives/widgets like Winforms in Visual Studio. We've spent the next two decades reinventing everything from modals to combo boxes that worked fine in Windows 95 GUI apps...
I've only seen a few stuff that warrants being a web app, and most of their primitives are already built-in, they just don't care to use it. The Document/Form model is ok for the majority of stuff on the internet. Anyone that tries to be fancier would better be served with a native app instead of contorting HTML.
Granted, I'm biased (being a frontend dev), but I think there are many apps and dashboards in popular usage that aren't a great fit for the document model, like Figma, Google Docs, Gmail, Google Maps/OSM, Discourse, Netflix, YouTube, games, Slack/Discord, Spotify, VSCode... to go on and on.
I don't think the web is necessarily the best consumer desktop platform, but it's what we ended up with after Java, .NET, etc. failed. But I guess the flipside of it is that a lot of apps that formerly would've required a native executable can now just be a JS app that contorts the DOM (or draws to Canvas). That's cool, since it eases distribution a lot, way better than Java web start or Microsoft's ClickOnce could.
> That's cool, since it eases distribution a lot, way better than Java web start or Microsoft's ClickOnce could.
One argument against Electron Apps is the existence of software like GIMP, Calibre, Blender, VLC,... which manage to be multi-platform without being built by a multi-million dollars company. And on Linux, it's very easy to get them with the package manager. Web Technologies may be a faster way to build a prototype, but it does not tend to efficient software. And I prefer not to have a hard dependency on someone's servers for my workflows [1].
[1]: I still use internet based services, but I prefer to have my data offline (music, photos, documents, books,...).
Well, if you're talking about the official web API (https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...), they seem a little clunky to me, and I've never personally seen them used by any of the orgs or clients I've worked for. Their scope is too limited and they don't really seem to be able to replace the frameworks/libs like React they were competing against.
I'm not really one of those HTML purists, and I actually think React and especially JSX is a huge improvement on the traditional DOM model. Although I grew up in the 90s, I would not willingly go back to that style of web dev... it's just not a good use of time when you're building more complex apps as opposed to documents, IMO.
But if "web components" can also mean "reusable components" in general, then I use and really love UI kits like MUI: https://mui.com. It's very well thought out, implemented, and documented, and using it was what made me fall in love with modern frontend dev.
To expand on this a little: A single reusable component on its own isn't very useful to me (unless it's for a specific use case, like a complex calendar or something). We already had those with drop-in ActiveX, Flash, or jQuery widgets back in the day, but they often created a disjointed, buggy mess of a site since you're just clobbering together different libs and widgets from different authors, each with their own idiosyncrasies, input shapes, etc.
In contrast, having a cohesive framework (like React + Next/Astro/Vite/etc), UI kit (MUI, Chakra, Ant, or similar), and internal style guide (brand assets, colors, typography, flows, etc.), coupled with a well-defined state and routing model, makes modern web development so much more consistent and pleasurable to work with. I can compose a useful dashboard in 10% of the time it used to take me, with a state tree I can easily reason about, and I can cleanly separate client and server renders (on purpose).
A Web Component on its own doesn't really do any of that except provide a reusable HTML snippet. It feels a bit like a serverside include to me (popular in the PHP days), but doesn't really holistically help me with routing, state management, schema sharing, composability, typing, etc. A good framework does all of that and saves me weeks/months of having to reinvent the wheel for every project, AND (via UI kits) still includes reusable components that work well with the rest of the system, from logic to styling.
Visual Studio and the Winforms model, along with various Windows APIs, did all of that for desktop development long before the Web was popular. If you wanted to make a Windows app, you could just drag and drop UI widgets in a cohesive way inside a responsive layout (windows were resizable long before smartphones), share properties and styling across them programmatically, etc. Modern web frameworks and UI kits bring a similar integrated dev experience (minus the WYSIWYG part, sadly).
I guess if you were a purist and wanted to eschew frameworks and had an app that doesn't have much complexity, maybe a Web Component would help you make it in a more reusable way? But honestly if a site were that simple, I'd just build it in Wix or Squarespace or Wordpress to begin with. I struggle to think of a scenario where a client or business would want to build up such a thing using HTML/DOM primitives instead of just reaching for either a low-code/no-code editor or a full-blown frontend with all the glorious framework bloat. Maybe there's room in the middle there for simple hobbyist websites, it's just not what people typically pay me for (as a frontend dev).
--------
Zooming out a bit, my personal opinion (that's all this is) is that the Web and JS official specs move way too slowly to keep up with modern needs. WHATWG is an improvement over the W3C, but the ECMAscript standard lib is still pretty barebones compared to other high-level languages, and both move reaaaaaally slow. I think that's why we end up with things like jQuery and lodash and React and Next, a billion third parties trying to improve the developer ergonomics in a trillion different ways, none compatible with each other. It's resulted in some significant improvements, yes, but also a lot of obsolescence. It's exhausting to try to keep up and I wish we just had a FAANG Web UI standards group that could choose one path and rapidly iterate it instead. Hard to imagine the React, Angular, and .NET folks getting together to hash all that out cooperatively though... =/
> A good framework does all of that and saves me weeks/months of having to reinvent the wheel for every project
Managing updates for the framework is also something to evaluate. Going from a big angular update, or the recent nextjs changes can easily take up those saved weeks.
> doesn't really holistically help me with routing, state management, schema sharing, composability, typing, etc.
Style scoping comes for free with web components. That is much better than an html template, and makes them composable. Typing you can organize as you want by using typescript, also making them composable.
In regards to state management I usually use component attributes (they are standardly defined in a web component, so they are easy to find in a codebase). That goes a long way. If tgat is not enough, an elm-like state management (one big switch with events and types for the payload) is easy to implement. I find it much easier than using redux.
For routing, I feel like a component is not really the place to do routing. It feels like a bit of a hack, but convenient. Again, I find a single centralized definition of routes usually works. This is how routing components are used anyway IMO.
For a long-running project, avoiding dependencies and updates is huge, compared to npm package problems and the constant wheel reinvention of React, for instance.
You can't change case-sensitivity in URLs, because they contain path names which are handed directly to the operating system on which the server runs. So the sensitivity follows the OS (whose design is unrelated to and usually predates web development).
When I say can't, I mean it's just a monumentally bad idea, that it amounts to shouldn't even try.
Not quite web dev but I've always thought there might be room for a browseresque class of software for mobile apart from the literal browser. Instead of every mom and pop shop having basically similar apps that everyone feels resentful of installing, just have a bunch of the shared functionalities bundled into a meta app. The app browser could handle things like identity/billing/notifications etc.
The mini-apps could be mostly a JSON object defining behaviors and then maybe some styling/assets. It could lower the cost of getting a proper mobile experience out for businesses as well as lower the friction for a user debating installing an app.
It seems a shame that the choice is between a responsive webapp and a really expensive (dev time wise) native app.
I don’t think there’s a main single technical issue with web. But if it counts, I’d go back and put less sleepy people to rule web standards. So that they could sit together and clearly see what it lacks fundamentally and add it there instead of waiting for ten years for each feature. Also they would just expose lower-level interfaces, so things like flexbox or content queries could be implemented by simply hooking up js callback into a sizing loop, etc. As if they were proper programmers and knew that a generic solution is just better than a bunch of specifics from the evolutionary pov.
Things have turned out pretty darn well without it, what’s your argument besides it being “amazing technology”? Plenty of amazing technologies don’t have a good use practical case.
The CSS box model for sure. Border box just makes so much more sense than content box (who seriously counts the width of a border and padding as separate from the container itself, in real life or otherwise?) that I'd put it as default from the start, like IE did all along.
I'd probably also scrap the attempts to migrate to XHTML, and go ahead with HTML 5's additions back in the early 00s. Things like the new semantic block elements, new input types, picture element, etc are far more useful to developers than an XML based HTML dialect were, and don't sacrifice ease of use for some abstract ideal.
Finally, I'd have Flexbox and Grid added early on, so that the hellscape of floats and table layouts didn't have to come to fruition. They just make so much more sense really.
XHTML was a big distraction. I wish the whole thing had been avoided.
Dynamic HTML was really cool at the time, but the divergence between Netscape 4 and IE 4 was a real pain — I wish they had agreed on standards earlier.
Lastly, the way Microsoft screwed over developers when they 'won' the early browser wars, and then abandoned work on IE for 5 years after version 6, which left the web to stagnate. I wish someone could go back and force the fuckers back into the game.
reply