Ask HN: What decision in web development would you go back in time to change?
Case sensitive URLs? The Netscape rewrite? JavaScript? The <img> tag?
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.
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... =/
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.
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.
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,...).
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.
> In early 1995, Brendan Eich was recruited to Netscape with the bait of "come and do Scheme in the browser."
https://dl.acm.org/doi/10.1145/3386327 - open access
When I say can't, I mean it's just a monumentally bad idea, that it amounts to shouldn't even try.
I’m thinking they should have made flash open source and iPhone should have run it. It was a pretty amazing technology.
https://web.archive.org/web/20170615060422/https://www.apple...
Obviously one of the big complaints was it being closed. Do you really think that opening it up overcomes battery life and other issues?
I wish web standards had embraced high-touch interactivity earlier using vector graphics and scripting, maybe JavaScript/SVG versus Flash/ActionScript.
That would've unleashed richer interaction design (and yes, games) earlier and would've forced Apple to adopt this open standard. Flash's closed/proprietary solution gave Apple the excuse to make mobile apps a walled-garden.
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.