HTML is still quite limited compared to native UI toolkits. It's still fundamentally a document model that we're using to write applications. Especially where layout is concerned: HTML and CSS are pretty clearly designed for document layout (and they're not half bad at that!). Flexbox helps, but it's still not there compared to e.g. layout constraints in Cassowary[1].
It's a thread, started about 2004-ish, apparently updated through 2011-ish, complaining that people should use native apps instead of web apps. It starts with the premise that using HTML to implement an application is abusive, since it was developed as a document display language, not an app framework.
They focus a lot on E-Mule as a non-HTML-based, native web app. (someone else eventually points out that it doesn't fit the customary definition of "web app").
E-Mule isn't a web app at all, it's just an Internet application. The fact that we have so confused the Internet and the WWW, to the point that even people complaining about WWW conflate it with the Internet, is a fucking tragedy.
I think that their argument (translated from rant) is basically that the web should be used for documents, and that we should build some other internet-based technology to implement applications on top of. It doesn't seem like there was a whole lot of justification beyond "this isn't what HTML was designed for", "Javascript bad", and "native app good".
Sadly, the original wiki fell prey to JavaScript. What used to be one of the cleanest, simplest, easiest-to-use sites no longer really functions, and it's all due to trying to due in the client what should be done on the server.
I think it's a bit slow because it appears to load a file (names.txt) containing all of the names of every article in the wiki every time you load a page.
If you click a link to load a new article, it loads all of the names again.
I guess it depends on what how your browser behaves. Using Firefox, the second request is conditional (using If-Modified-Since), so the server actually sends a 304 Not Modified response instead of the names list.
Anything that has a certain level of utility gets "abused." Problems result, then are solved, sometimes generating huge wealth for the solvers. This happened with highways. This happened with cars. This happened with email. This happened with "The Web." This even happened with print. Hell, this happened many times with agriculture!
How much does anyone want to bet that this won't happen to AI/deep learning? (And would I still be around to collect on the bet?)
When was this written? 1995? They suggest loading Java applets. (2011, apparently, but maybe the original post is earlier.)
(Thing to avoid in web design: just displaying month and day, not year, even if something is more than a year old. Some blogs do that to look cool and current. Then they get stale and confusing.)
> (Thing to avoid in web design: just displaying month and day, not year, even if something is more than a year old. Some blogs do that to look cool and current. Then they get stale and confusing.)
Related, thing to avoid in web design: displaying time as something other than ISO-8601 combined date & time format (preferably omitting the 'T' separator, for the sake of non-tech people). If you absolutely must display dates relative to current time (like "4 hours ago", "5 days ago"), please at least provide a full ISO timestamp in a title attribute (i.e. in a tooltip text).
HN has this problem, too. I get some find "4 hours ago" easier to read (never mind how imprecise it is), but then soon it becomes "1139 days ago", which is no longer funny.
</rant>
('dang, et al. - could we please have ISO timestamp as a title attribute to the relative date here? Pretty please :).)
Give this guy a Chromebook! See how he gets on without files where the operating system considers all programs hostile.
I was surprised he suggested an offline SQL editor, thought he would suggest command line which is definitely impressive to clients sat next to you wanting to see their programmer doing stuff Bourne movie style.
"Those who do not learn history are doomed to repeat it."
It gives you snapshot into what developers thought about web development in the early to mid 2000's. Bandwidth and processor speed was in short supply. Early web app's would bog down the average machine. And our ISP (internet service provider for those who may not know that acronym) charged us by the minute of usage, not by the month.
Desktop clients (games and email) would download a local copy of just the data and cache it. Many of these were applications were set to dial in the ISP, pull your information, and then disconnect. I remember a chess client that could be set up to dial in to the ISP every minute and then disconnect so that you might make it under the 60 seconds charge. That was cure for bandwidth. And the local clients were optimized for your machine so yo got faster everything.
You actually see the same thing going on with tablets and phone. Sure you can use Facebook through Chrome. But its slow and eats us your mobile data cap. But if you install the app its a lot faster, richer experience. And it only download the data it needs once without constantly reload the same contents over and over again.
36 comments
[ 2.1 ms ] story [ 80.1 ms ] thread[1] https://en.wikipedia.org/wiki/Cassowary_(software)
They focus a lot on E-Mule as a non-HTML-based, native web app. (someone else eventually points out that it doesn't fit the customary definition of "web app").
http://webcache.googleusercontent.com/search?q=cache:u3lFxVi...
If you click a link to load a new article, it loads all of the names again.
https://archive.is/jFhIq
How much does anyone want to bet that this won't happen to AI/deep learning? (And would I still be around to collect on the bet?)
(Thing to avoid in web design: just displaying month and day, not year, even if something is more than a year old. Some blogs do that to look cool and current. Then they get stale and confusing.)
The page has grown substantially since then, but that initial version already has a mention of Java.
Related, thing to avoid in web design: displaying time as something other than ISO-8601 combined date & time format (preferably omitting the 'T' separator, for the sake of non-tech people). If you absolutely must display dates relative to current time (like "4 hours ago", "5 days ago"), please at least provide a full ISO timestamp in a title attribute (i.e. in a tooltip text).
HN has this problem, too. I get some find "4 hours ago" easier to read (never mind how imprecise it is), but then soon it becomes "1139 days ago", which is no longer funny.
</rant>
('dang, et al. - could we please have ISO timestamp as a title attribute to the relative date here? Pretty please :).)
https://developer.mozilla.org/docs/Web/HTML/Element/time
I was surprised he suggested an offline SQL editor, thought he would suggest command line which is definitely impressive to clients sat next to you wanting to see their programmer doing stuff Bourne movie style.
What's the point of this site?
It gives you snapshot into what developers thought about web development in the early to mid 2000's. Bandwidth and processor speed was in short supply. Early web app's would bog down the average machine. And our ISP (internet service provider for those who may not know that acronym) charged us by the minute of usage, not by the month.
Desktop clients (games and email) would download a local copy of just the data and cache it. Many of these were applications were set to dial in the ISP, pull your information, and then disconnect. I remember a chess client that could be set up to dial in to the ISP every minute and then disconnect so that you might make it under the 60 seconds charge. That was cure for bandwidth. And the local clients were optimized for your machine so yo got faster everything.
You actually see the same thing going on with tablets and phone. Sure you can use Facebook through Chrome. But its slow and eats us your mobile data cap. But if you install the app its a lot faster, richer experience. And it only download the data it needs once without constantly reload the same contents over and over again.