A shorter (and more controversial?) explanation is that modern web development is complicated because it’s a poorly designed bunch of hacks on top of HTTP and HTML to make them do things they weren’t designed to do.
Indeed, it takes a few decades to convert an SGML-based document formatting system by incremental steps into a real-time composited retain-mode GUI construction set with audio, storage, and accelerometer APIs and a VM. An astonishing experiment that I hope isn’t repeated!
(Edit: I forgot, it has a 3D rendering engine too.)
There’s economics, as well. To the first approximation, there’s no money in writing native software, so the pile of mashed potatoes that is the modern web stack gets all the dev attention, and is being pushed into places adjacent to the collection of personal infomation showing ads where it is a pretty lousy fit.
There was a ton of money in writing native software as this way underway. Tens of billions, maybe 100+, of it. Then, as web apps took off, there was still plenty money in it if the native experience was good or facilitated lock-in. I was told the two advantages web apps had early on was easy installation and updates since both were just a link. Standalone, native apps that were easily distributed and/or updated could’ve competed with that. Most companies making native apps just weren’t addressing those issues. Most companies using native apps were doing admin and compliance things that made using them a pain in the ass versus connecting to anything on port 80.
Eventually, mass perception seeing that vs web apps maybe made them think you needed web apps for that. Also, the browser vendors were just updating their wares to enable such uses in supply and demand situation. Add that many people thought portable native was much harder than it is. Add especially web apps building on the skills that many more people had. Then, you get a surge in web apps vs native or cross-platform native. They keep building more and more stuff with both the capabilities and inefficiencies going through the roof.
Even still, people are developing native apps that kick ass. There’s still potential even though web w/ SaaS is lowest-hanging fruit. Just not much execution on it or at least media coverage. Not sure which.
This is all true. I was trying to get at the point that the money is flowing to “free” services, not retail software. We are drowning in an ocean of stupid VC money chasing the 100x white whale, and this distorts all kinds of things, from the choice of business models to the choice of tools.
I hate it, myself, but I don’t know how, or even if, I can push back.
That’s true. The VC’s and unicorn folks were also telling them to build web apps. Probably no pushing back but you can make better native apps. Alternatively, a web app with a faster, native version. Tech companies already pushing that trend for mobile.
Imagine a Microsoft Word document with embedded VBA scripts implementing complex UIs and workflows. This was totally common in the 90s. (Though more commonly used in Excel)
Sounds bad? Yeah, a document format totally not intended for this, but someone needed a scripting engine in it at some point, so a semi-terrible language was bolted on top of it, with some UI capabilites for data entry as an afterthought. It is still used this way at some places, but people usually frown at this hack. Why? Because its terrible engineering (the scripted documents, not the platform itself… that is a black box).
Meanwhile its franken-clone competitor, the web platform is cheered for the very same uggly hacks.
I start to believe that the main issue is that the webapp devs aim to keep the HTML fundamentals visible instead of layering a GUI layer completely on top of them.
Objective/J (edit: more like the cappuccino web framework) was certainly a lot more pleasant than Polymer (the framework that attempts to encapsulate REST APIs in html tags through web components) due to avoiding this problem.
Same for Javascript and other building blocks: build something cohesive on top of them (that doesn’t try ultra-hard to emulate something else entirely, like GWT), hide the building blocks, and the pain might go away.
There’s a bunch of projects like Elm and PureScript that take this approach (in my view, successfully), but it’s a massive effort to replicate all of the APIs which are now part of the web platform, so it takes a long time for them to become applicable to most use cases.
(I had a brief encounter with GWT back in the day – shudder.)
IMHO, at this point there should just be a direct connection between WebAssembly and the low-level eventing/rendering engine (and the various system services APIs). The whole HTML/JavaScript layer is basically just in the way. Or perhaps just Webasm+Flexbox+DIVs+Canvas+Z-order.
What is preventing that kind of setup? Is there a lot of functionality browsers would have to implement to enable it? I don’t really know enough to understand how it would fit together.
It’s already there…browsers would need to remove functionality, or rather provide direct access to the lower layers that are already there, and agree on a standard API for them.
This goes against the eternal cycle of browser expansion, though, that Java applets, Adobe Flex, Microsoft WPF, Cappucino, and more have failed to break. I don’t know what the strange attraction of HTML/CSS/JS is, but it always seems to win by growing yet another new layer or appendage, rather than losing to something simpler. It’s really quite amazing.
Well that wasn’t very well written at all. Why get into an argument with Wikipedia about whether ECMAScript and JavaScript are the same thing. Wikipedia even provided examples of JScript and ActionScript as other implementations of ECMAScript specs.
Did they claim “Web APIs” == the DOM? The article’s description of web APIs is “document and every method on document; window and every method on window; Event, XMLHttpRequest, fetch, etc”. That sounds correct to me.
I suppose I was thinking that the author was conflating the end points where data comes from, with manipulating things on a webpage. Maybe methods on windows are part of the programming interface of the Web, but it doesn’t feel right to me. It seemed like a hand-wavy way to avoid being specific about whether they were talking about DOM manipulation (why React exists) and actually getting data from web servers (why Redux exists).
It lists all APIs which aren’t part of the ECMA specification, but which the web platform exposes, as web APIs. That includes interacting with CSS, the DOM, and things like XMLHttpRequest.
Complicated? It’s a hell of a lot easier than it was when I was still in highschool.
As the author points out, there isn’t even a need for tooling, technically and I can’t imagine a paid professional having a hard time coming to terms with how to use the existing and expected tooling.
A shorter (and more controversial?) explanation is that modern web development is complicated because it’s a poorly designed bunch of hacks on top of HTTP and HTML to make them do things they weren’t designed to do.
Indeed, it takes a few decades to convert an SGML-based document formatting system by incremental steps into a real-time composited retain-mode GUI construction set with audio, storage, and accelerometer APIs and a VM. An astonishing experiment that I hope isn’t repeated!
(Edit: I forgot, it has a 3D rendering engine too.)
There’s economics, as well. To the first approximation, there’s no money in writing native software, so the pile of mashed potatoes that is the modern web stack gets all the dev attention, and is being pushed into places adjacent to
the collection of personal infomationshowing ads where it is a pretty lousy fit.There was a ton of money in writing native software as this way underway. Tens of billions, maybe 100+, of it. Then, as web apps took off, there was still plenty money in it if the native experience was good or facilitated lock-in. I was told the two advantages web apps had early on was easy installation and updates since both were just a link. Standalone, native apps that were easily distributed and/or updated could’ve competed with that. Most companies making native apps just weren’t addressing those issues. Most companies using native apps were doing admin and compliance things that made using them a pain in the ass versus connecting to anything on port 80.
Eventually, mass perception seeing that vs web apps maybe made them think you needed web apps for that. Also, the browser vendors were just updating their wares to enable such uses in supply and demand situation. Add that many people thought portable native was much harder than it is. Add especially web apps building on the skills that many more people had. Then, you get a surge in web apps vs native or cross-platform native. They keep building more and more stuff with both the capabilities and inefficiencies going through the roof.
Even still, people are developing native apps that kick ass. There’s still potential even though web w/ SaaS is lowest-hanging fruit. Just not much execution on it or at least media coverage. Not sure which.
This is all true. I was trying to get at the point that the money is flowing to “free” services, not retail software. We are drowning in an ocean of stupid VC money chasing the 100x white whale, and this distorts all kinds of things, from the choice of business models to the choice of tools.
I hate it, myself, but I don’t know how, or even if, I can push back.
That’s true. The VC’s and unicorn folks were also telling them to build web apps. Probably no pushing back but you can make better native apps. Alternatively, a web app with a faster, native version. Tech companies already pushing that trend for mobile.
Imagine a Microsoft Word document with embedded VBA scripts implementing complex UIs and workflows. This was totally common in the 90s. (Though more commonly used in Excel)
Sounds bad? Yeah, a document format totally not intended for this, but someone needed a scripting engine in it at some point, so a semi-terrible language was bolted on top of it, with some UI capabilites for data entry as an afterthought. It is still used this way at some places, but people usually frown at this hack. Why? Because its terrible engineering (the scripted documents, not the platform itself… that is a black box).
Meanwhile its franken-clone competitor, the web platform is cheered for the very same uggly hacks.
I start to believe that the main issue is that the webapp devs aim to keep the HTML fundamentals visible instead of layering a GUI layer completely on top of them. Objective/J (edit: more like the cappuccino web framework) was certainly a lot more pleasant than Polymer (the framework that attempts to encapsulate REST APIs in html tags through web components) due to avoiding this problem.
Same for Javascript and other building blocks: build something cohesive on top of them (that doesn’t try ultra-hard to emulate something else entirely, like GWT), hide the building blocks, and the pain might go away.
There’s a bunch of projects like Elm and PureScript that take this approach (in my view, successfully), but it’s a massive effort to replicate all of the APIs which are now part of the web platform, so it takes a long time for them to become applicable to most use cases.
(I had a brief encounter with GWT back in the day – shudder.)
IMHO, at this point there should just be a direct connection between WebAssembly and the low-level eventing/rendering engine (and the various system services APIs). The whole HTML/JavaScript layer is basically just in the way. Or perhaps just Webasm+Flexbox+DIVs+Canvas+Z-order.
What about accessibility? IMO we really do need all of HTML and CSS to do that right.
Every desktop OS has accessibility, without having HTML or CSS. It’s just another system API.
(Edit: And HTML accessibility is implemented with that system API, so HTML has no inherent advantage over any other UI framework.)
What is preventing that kind of setup? Is there a lot of functionality browsers would have to implement to enable it? I don’t really know enough to understand how it would fit together.
It’s already there…browsers would need to remove functionality, or rather provide direct access to the lower layers that are already there, and agree on a standard API for them.
This goes against the eternal cycle of browser expansion, though, that Java applets, Adobe Flex, Microsoft WPF, Cappucino, and more have failed to break. I don’t know what the strange attraction of HTML/CSS/JS is, but it always seems to win by growing yet another new layer or appendage, rather than losing to something simpler. It’s really quite amazing.
Well that wasn’t very well written at all. Why get into an argument with Wikipedia about whether ECMAScript and JavaScript are the same thing. Wikipedia even provided examples of JScript and ActionScript as other implementations of ECMAScript specs.
Also “Web APIs” != the DOM, for what it’s worth.
Did they claim “Web APIs” == the DOM? The article’s description of web APIs is “document and every method on document; window and every method on window; Event, XMLHttpRequest, fetch, etc”. That sounds correct to me.
I suppose I was thinking that the author was conflating the end points where data comes from, with manipulating things on a webpage. Maybe methods on windows are part of the programming interface of the Web, but it doesn’t feel right to me. It seemed like a hand-wavy way to avoid being specific about whether they were talking about DOM manipulation (why React exists) and actually getting data from web servers (why Redux exists).
The MDN seems to agree with the article: https://developer.mozilla.org/en-US/docs/Web/API
It lists all APIs which aren’t part of the ECMA specification, but which the web platform exposes, as web APIs. That includes interacting with CSS, the DOM, and things like XMLHttpRequest.
Complicated? It’s a hell of a lot easier than it was when I was still in highschool.
As the author points out, there isn’t even a need for tooling, technically and I can’t imagine a paid professional having a hard time coming to terms with how to use the existing and expected tooling.