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.
I don't know if it's a transparency issue rather than an editorial perspective. I don't really know or care who gave me my CNN/Fox/BBC/ITV news, but I care that it has a consistent and trustworthy editorial perspective, that may be carried over multiple people.
I guess transparency and a greater overarching perspective both work.
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.
I'm not sure that "a decade-old game runs smoothly" would qualify as an innovation, rather than as a showcase of the exact problem the author was hinting at. Just getting stuff shoehorned into the browser that we already had running perfectly fine outside of it is not "innovation".
What about truly new stuff that nobody has seen before, neither inside browsers nor in native applications?
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).
Surfing on a smart phone is a real pain. Pages take longer to load than in the 90s and contrary to the 90s you can't start reading before it all has loaded.
Java tried to be C++, but run on every machine. That turned out to be difficult. But I don't think the author is thinking of Java. I guess he more has in mind domain specific languages, which are abstract enough in nature to be executed faithfully on any system with given capabilities.
Security also goes hand-in-hand with this form of abstraction. If the language can only express safe actions, the program will not be malicious. In pure languages, such as Haskell, one can use type-guarantees to enforce these restraints. One could imagine a virtual machine with this kind of typing.
> If the language can only express safe actions, the program will not be malicious.
Because 'safe' is not well defined, I can't argue rigorously against this, but it seems like the sort of thing that falls afoul of Rice's theorem (https://en.wikipedia.org/wiki/Rice%27s_theorem): for most reasonable definitions of 'safe', you can have a proveably safe language or you can have a Turing-complete language, but not both.
Rice theorem is not really applicative here. It is a beautiful theorem, but it has to do with what we can compute, while "safe" has to do with what one can access.
A function taking Integers to Integers in a pure language cannot do I/O, and thus is "safe" to run, in the sense that I can be guaranteed it does not contain a trojan making my computer into a peer on a botnet. This is true, even if I allow it to compute any computable function.
Computational expressiveness and "safeness" are in a sense orthogonal. And just as I don't think it is always appropriate for any function to do I/O, I am not convinced all functions should be able to perform any computation. But that's a different discussion.
Regarding definedness of the term "safe", I would say it is defined by your threat model. It not an absolute term, but dependent on context.
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.
> 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”.
Not sarcasm, but an honest question: barring the argument "even full virtual machines have bugs", to which one might as well retort "even multiply heavily tested browsers have bugs", why isn't it safe to run such a program in a virtual machine? It seems that most of the pain of Flash exploits comes from the fact that Flash doesn't run in a (proper) sandbox.
(I'm not a web developer, so I could easily be talking nonsense.)
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.
> For scientific coding, comments should align with the underlying theory for the code
100x this. Scientific software should be held to a different set of standards than non-scientific software, primarily because you can probably not assume that your reading is familiar with the underlying domain.
> Scientific software should be held to a different set of standards than non-scientific software, primarily because you can probably not assume that your reading is familiar with the underlying domain.
As someone who works as a programmer and system analyst dealing with code in a non-scientific business domain where I've also worked on the domain side, I don't think that this separates scientific code from any other codes. Programmers often disdain domain knowledge beyond that which they already have found to be immediately relevant. Which is perfectly understandable -- there's a reason they chose to specialize in programming rather than as domain experts in whatever domain.
I thought through this some, and your comment resonates -- it's not right to set aside scientific code from other code with a complicated domain.
But I think complicated program segments related to business practices etc. also deserves comments, even just "see spec xyz" or "see section 1.2.3 of code xyz" (similar to how you might say "See Smith et al. '14" in a scientific setting)
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?