Both software support and hardware quality are very good. Bonus points for having a Tux key instead of a Windows key ;-) . Maybe they’ve got something in your range?
Agreed, developing print stylesheets is a PITA. But the principle proof, that HTML + CSS is capable of being the authoring format for whole books, is brought by PrinceXML, https://www.princexml.com/, for years now.
It’s just that browsers suck with handling print styles.
The splitting is something, that the CSS authors already did with CSS 3 and its single modules (specification-wise). But authors don’t really see anything of that in their day-to-day work.
Sorry in advance for the rather harsh feedback, that follows. It’s basically my unfiltered impression when I visited your site before reading your introduction comment here.
This is one of the occasions, when I love the German “every website needs a ‘Who’s responsible for this?’ page” law (a.k.a. “Impressumspflicht”). Why should I trust your specific selection of quotes and their interpretation? You even don’t trust your visitors with a “Who are we?” section. For all I know, this could be a Chinese or Russian troll factory outlet sale.
For this to work (for me, at least) you need to work _way_ more on the site’s transparency than a more or less default privacy disclaimer and an e-mail input form: Who am I, what criteria and sources are used for the quotes, how are they categorized, what do I do to prevent bias... The technology may as well be sound and state-of-the-art, but if I don’t trust the website, I won’t sign up to anything.
Of course, if the language of a program is stripped down, the interpreter can be made much safer. But then, we gain nothing from trying to shove down the users’ throats other platforms compared to, say, WebAssembly, which _will_ be shipped in almost all browsers in a year or so.
Just look at the long history of people trying to bring Python in the browser, or the fight to get Java applets _out of the browser_ again.
Basically I read the article as “scrap that web thing, and just begin from scratch”. And this is not a worthwhile path to go for many reasons.
In 5 years, that’s my rough prediction. So long it will take for the browsers (with significant market share) to catch up with existing native features to combine them with the web. Then we have enough instances out there to use reliably:
- canvas + 3D support
- asm.js / WebAssembly: a way to run performant byte code
- WebRTC: Video chat, file transfer P2P
- APIs closer to the hardware like vibration, ambience, speech, ...
- stuff, that’s being developed but I don’t know yet, because the field has become so huge now. Small glimpse: http://caniuse.com/
And for developers it’s a single platform, together with distribution channel.
Apart from that: Truly innovative stuff happens on the web regularly. For example, look no further than Facebook (or Reddit, Imgur, Twitter, whatever you like). A software (in the broader sense), that allows billions of people to connect with each other and share thoughts. Imagine that in the age of SMS, phone books or snail-mail! You will see, that it’s fundamental to make something like social networks, the browsers had first to evolve from the bunch of hacks, that they were in the 90’s.
Another example of the power of browsers: FirefoxOS. A complete smartphone OS powered by web technologies on a thin Linux layer.
So my point is: the “truly new stuff” is partly already out there, you just have to look. And partly it will hit your devices, when the browsers are evolved enough. It’s a continuous process, and not a single “wait, there’s more...” (which doesn’t surprise the least, when you think of the _huge_ numbers of devices out there).
Well, we have a scenario rather close to the one described in the article on mobile: Browsers for text content and apps for specialized stuff, that can incorporate web views, if needed, and access the net. (Yes, I’ve read the second-to-last sentence.) In a nutshell, it sucks.
To start with, I don’t buy the premise “Okay, so web browsers are awful for applications.” The statements before are way to generic to prove anything.
“[...]resource hungry beasts with millions of lines of code” falsely connects those two properties.
“[...]use several gigabytes of RAM, even when just displaying document-like content” might also be rooted in advertisers packing megabytes of rubbish in an iframe or web devs loading tons of unneeded web fonts. So, that’s bad engineering on the server side, not the browser’s.
“[...]that reimplements much of the features of an operating system on top of a real operating system” Chromebook anyone? Yes, that’s actual, ready-to-be-bought devices out there right now, that do exactly this. And lo, the problems are somewhat contained.
The conclusion also does not show any solution to the non-problem discussed above. “Imagine something like xdg-open.” I don’t need to imagine that, I have it right before me available in the terminal. And packing another service discovery on top of the stack is, to come back to my opening words, not so different from the closed-world app stores. Even Ubuntu has such a thing. And guess what? For people without technical knowledge keeping everything in the browser is way more efficient (work-wise, not performance-wise) than explaining arbitrary switches in context from browser to some app to some other app and back to the browser.
Security: “I’m no expert [...but...] doesn’t seem to be completely unrealistic.” The devil’s in the detail, as virtually everyone who works on browsers’s JS engines can tell you. A runtime, that downloads arbitrary binaries from the web to be executed, sounds in every regard like a bad idea, even if you put it in a full virtual machine. The two-word argument against this is basically “Flash exploit”.
Platform independence: The author might be too young to remember Java’s “write once, run everywhere” claim, that turned out to be not so fully true. And turning the current state of almost full platform independence in the browser for some proposed, from-scratch infrastructure will become exactly that disaster, that Joel Spolsky warned about 15 years ago in the context of the Netscape rewrite (http://www.joelonsoftware.com/articles/fog0000000069.html).
“But one thing is certain: the web platform we have today is already bloated, does not suit our needs and severely limits innovation.” No. It is not certain. Browsers today run on low-profile smartphones. Bloated web platform? Most of these things are opt-in, and many clever people build fallback strategies in new specifications to enable _everyone_ to become part of the web. Limiting innovation? Quake runs smoothly in the browser. Who would have figured that 10 years ago?
All in all, to me it seems the post is written by someone, who hasn’t yet fully groked the web.
The situation must be differentiated by language/environment. The suggestions for Haskell are certainly not bad. They hold, too, for many systems programming.
For scientific coding, comments should align with the underlying theory for the code: “This implements matrix transposition with regard to ... as defined by ...”, so that next generations can align code with papers better.
And when you’re in a wacky environment like the PHP runtime or coding for a moving target like the browser, comments might be indispensable to explain one or the other really strange way of doing things, where you simply have no other choice. Look at the [jQuery source code](https://github.com/jquery/jquery/tree/master/src), where they comment excessively, which browser quirk they address with which work-around.
Not only hasn’t there any advance since 2010, no! It even worsened: With Opera switching to Blink, Chrome dragged it with it into the dark “We need no MathML” hole. Huge step backwards.
https://www.tuxedocomputers.com/en#
Both software support and hardware quality are very good. Bonus points for having a Tux key instead of a Windows key ;-) . Maybe they’ve got something in your range?