> All this to render web pages. I think we must have made a wrong turn somewhere.
We've taken plenty of wrong turns, but none, I think, accounted for more than a rounding error in time or code needed to render web pages. Writing a browser is hard.
Hell, even writing a toy browser-like mockup isn't easy. I built an extremely bad renderer for an extremely simple class-provided XML-ish grammar in school. It only supported a handful of styling keywords (all inline/attribute-based), only one of which was positioning-related ("wrap to next fixed-height global line of display after this element").
It was really hard. Like, really hard. Even looking back on the code with the benefit of experience, it still would not be a breeze.
It supported a single fixed window size and a guaranteed-correct input file. Removing either of those constraints would have exploded the code size to the point I doubt I could have done it alone then, and if I could now it would take me an incredibly long time. Adding the full HTML spec would probably bring its SLoC counts into the 100ks, if not millions. Supporting re-renders and after-the-fact DOM updates would blow it far beyond that, making them fast might require me to go back to school, but who knows; maybe it's easier than my hunch. I suppose I could shave time by moving some of those hundreds of thousands of lines into the libraries which evolved during the many years since browsers became popular, but it would still be a gargantuan undertaking.
And all of that is before the immense amount of person-hours which would be needed for:
- Supporting cascading styling of any kind, with or without embedding another language.
- Adding networking, even if interoperability/an agreed-upon communication pattern or protocol already existed.
- Displaying assets other than styled text and SVG-esque drawings (images, videos, etc).
- Securing the request/response protocol, even if leveraging existing tools like OpenSSL to the max.
- Adding another turing-complete and secure programming language for communicating with random local/networked resources and producing more requests or DOM updates.
It's hard.
TL;DR There are plenty of needlessly-complex tools and technologies out there. But I don't think web browsers are some of them. Even if you're anti-JS and anti-CSS, there is still an absolute shitload of complex, careful, hard-to-get-right interactions going on under the hood.
Is all that really needful? To draw documents? To make apps?
I don't think it is. I think Elm lang (for example) proves that it's not.
I finally got around to trying Elm. Once I got over the way it feels like a toy compared to the HTML/CSS/JS/etc world, I realized I could never ever justify NOT using it in a business context.
What I mean is, the business-value case for using the normal front-end stack vs. Elm just isn't there.
That's just an example for the domain you described.
The VPRI STEPS project demonstrated that we could reduce our codebase(s) by orders of magnitude while retaining or even improving functionality, "from the desktop to the metal".
I'm sure Elm is lovely, but how is it useful without a browser to deliver it, a browser to provide it a document to manipulate, and a browser to display its changes to that document?
It's those things that are complex; the client-side programming language (if present) is just one of many, many high-complexity parts in a browser.
Bless you! I was hoping someone would ask me that.
TL;DR: Write an Elm to native app compiler/interpreter. Servers serve Elm code.
(As an aside, The loveliness of Elm is incidental to the point. If it looked like COBOL it would still make economic sense. Lots of people have developed DSLs for apps, the important thing about Elm is that it's a very elegant and well-thought-out domain-specific system for specifying apps. Elm is much less complex than HTML+CSS+JS+Frameworks/libs/NPM etc.)
At the moment, the delivery vehicle for Elm-specified apps is the Fractal Rube Goldberg Machine, yes.
But consider e.g. an Elm-to-GTK compiler, or Elm-to-TCL/Tk interpreter, whatever... The FRBM is just a reasonable first target platform.
I don't think I'm wrong here, or even saying anything controversial. Go look at what VPRI did with STEPS. Our code volume and complexity is too high by two or three orders of magnitude.
I don't see why I wouldn't just use Haskell and a native UI library right now, to similar effect, instead of waiting for all this to appear. The language is in a much more stable state than Elm, which already makes it more ideal in a business-context.
I'm not making your point for you, I just don't agree with you on what the actual problem is.
Programmers don't disagree that we could be using better approaches. The question is not why they don't exist, because they do exist. The question is why we don't or can't use them currently.
Most of the time, the reason is purely cultural, either due to management or legacy. I'd love to use Purescript and Haskell at my job, but I cannot. I don't get to make that choice. A new Elm transpiler won't solve a cultural problem.
We've taken plenty of wrong turns, but none, I think, accounted for more than a rounding error in time or code needed to render web pages. Writing a browser is hard.
Hell, even writing a toy browser-like mockup isn't easy. I built an extremely bad renderer for an extremely simple class-provided XML-ish grammar in school. It only supported a handful of styling keywords (all inline/attribute-based), only one of which was positioning-related ("wrap to next fixed-height global line of display after this element").
It was really hard. Like, really hard. Even looking back on the code with the benefit of experience, it still would not be a breeze.
It supported a single fixed window size and a guaranteed-correct input file. Removing either of those constraints would have exploded the code size to the point I doubt I could have done it alone then, and if I could now it would take me an incredibly long time. Adding the full HTML spec would probably bring its SLoC counts into the 100ks, if not millions. Supporting re-renders and after-the-fact DOM updates would blow it far beyond that, making them fast might require me to go back to school, but who knows; maybe it's easier than my hunch. I suppose I could shave time by moving some of those hundreds of thousands of lines into the libraries which evolved during the many years since browsers became popular, but it would still be a gargantuan undertaking.
And all of that is before the immense amount of person-hours which would be needed for:
- Supporting cascading styling of any kind, with or without embedding another language.
- Adding networking, even if interoperability/an agreed-upon communication pattern or protocol already existed.
- Displaying assets other than styled text and SVG-esque drawings (images, videos, etc).
- Securing the request/response protocol, even if leveraging existing tools like OpenSSL to the max.
- Adding another turing-complete and secure programming language for communicating with random local/networked resources and producing more requests or DOM updates.
It's hard.
TL;DR There are plenty of needlessly-complex tools and technologies out there. But I don't think web browsers are some of them. Even if you're anti-JS and anti-CSS, there is still an absolute shitload of complex, careful, hard-to-get-right interactions going on under the hood.