10 ms·

HTML is done

160 points by AndrewDucker 11y ago

nkozyra 11y ago
Popular javascript frameworks exist to "work around" problems with javascript and CSS frameworks exist to "work around" problems with CSS? There's no magic with Angular or Bootstrap, they're codifying an approach using 100% native JS or CSS. Even SASS and LESS are just alternative ways to produce CSS. This is not novel in computing.
- bradhe 11y ago
  Totally true. That's like saying the Ruby on Rails exists because Ruby is somehow deficient.
  - fao_ 11y ago
    But, your analogy is flawed; the situations are incomparable. You're not forced to use Rails for your server application, many other software exists as well as Rails: Django, PHP, etc. However you /are/ forced to use Javascript, CSS and the DOM; Unless you're a Big Browser Vendor and can try and coerce support (and even so, the amount of websites made in something like Dash is pitiful afaik). People made frameworks and libraries that make it bearable (SCSS, JQuery, etc), but that doesn't mean everything is solved...
    - nkozyra 11y ago
      That's a totally different analogy altogether. The argument expressed on that page isn't that there is a lack of choices, but that the choices are inherently flawed (and somehow "fixed" by frameworks that lie on top).
- krapp 11y ago
  This seems to basically be the argument for preferring compile-to-js languages over vanilla javascript, even though by definition any advantages in the former have to exist in the latter. Yet if I were to call coffeescript an overly complex javascript framework, people would probably strenuously disagree. But that is what it amounts to.
  - amsheehan 11y ago
    I disagree, but not strenuously :) Purescript compiles down to javascript but helps save programmers from themselves by introducing a better type system as well as great data structures, and functional paradigms Typescript adds static typing and OOP CoffeeScript...is syntactic sugar? (okay maybe I agree with the coffeescript sentiment)
    - krapp 11y ago
      Fair enough. Although I don't entirely agree that compiling a statically typed language into javascript really helps much, since the end result is still... javascript in a browser. But the last time I tried to defend that I got almost universally disagreed with, so I'll concede that the process might have value I just don't see.
jph 11y ago
HTML has many areas to improve still -- for example HTML-next can make it easier to do hypertext markup to a list of articles, including article title, author, date, contact links to social sites, and some summary text. (Currently this is accomplished by munging the tags for cite, article, author, and jumping through some small hoops for microformats.)
javajosh 11y ago
Tim Bray or not, it's irresponsible to point out a pile of shit without pointing to a shovel. (And for the record I disagree that there is a pile of shit. I see a bazaar of indy components.) The browser exists in open opposition to iOS and Android, technically, culturally, and stewardship-wise. No-one in their right mind is going to pick a web host that charges you 30% of revenue. And yet, that's what Apple has managed to get (and they just control the BLOB distribution channel, they don't even provide runtime servers!). The whole shebang is sorting itself out and I for one think it's going to be very, very cool.
- pourhhd 11y ago
  People pick that "web host" because the platform you think is so great sucks ass. People have said this morass of nonsense was sorting itself out since gmail came on the scene. Things have been sorting out for web apps before mobile was even a viable thing.
- nly 11y ago
  > No-one in their right mind is going to pick a web host that charges you 30% of revenue. Eh? What stops you from publishing a free app with ads?
  - mikegioia 11y ago
    Integrity? User experience?
    - nly 11y ago
      Nobody seems to care about that on the web.
- leoc 11y ago
  > it's irresponsible to point out a pile of shit without pointing to a shovel. That's not true in general, but since in this case Tim Bray seems to be implicitly proposing an alternative of sorts (never mind whether it's in fact any better) that isn't really relevant. For what it's worth, this https://news.ycombinator.com/item?id=2119057 https://news.ycombinator.com/item?id=2119057 is the correct solution.
serve_yay 11y ago
I basically agree, except that I really like JavaScript (the language, not the APIs necessarily) and I think it gets a bad rap.
- savanaly 11y ago
  I have only programmed in Ruby and Java and Javascript (and the first two only a little). ES5 and before js does seem worse than the other languages I've experienced, but not by much. And ES6 is sort of a joy to write. Leaving callbacks behind for promises and writing in a largely functional style is very satisfying in js right now.
Udo 11y ago
The point of the article seems to be that HTML is done because it's "basically OK", and everything around it is done because it's awful and can't be salvaged anyway. I hope the next logical step implied here after this is NOT going back to native applications for everything. The browser-as-a-platform is based on a lousy programming language addressing a lousy object model and using a lousy stylesheet language for visuals. I think JavaScript is a suboptimal programming language because it has too many features, and on top of that they tacked on yet more features recently. I wouldn't call CSS lousy either, and the API of the DOM even got better over the years. We almost never phase anything out, and that's a problem, but I think the core issue causing suckage within the 3 pillars (4 if you count the DOM separately) is that they have been explicitly designed to not work together very well. While you can - and often are forced to - extend CSS and HTML with JavaScript, they didn't make the interplay between them especially synergistic. As for HTML? Not perfect, but plenty good enough. no, I don't think so, especially if we're discarding JS and CSS as garbage, HTML does not deserve to get a free pass. Even if we wanted to improve it, there are no obvious candidates to do the work. I don't get why we're all of a sudden in an arbitrarily constructed situation where the whole web platform can never be iterated on again. Ever. But if the point is that whatever comes next probably won't come out of a committee that sounds about right. I agree that some of the frameworks mentioned exist to work around the issues we created in the browser platform. Especially the functionality of React should be considered for an adoption scenario, maybe not the exact React API, but something along those lines that makes working on (or at least applying) diffs easier. The same goes for handlebars-like templating. I would rather see some of these adopted than the effort that goes into giving classes to JavaScript.
- deleted 11y ago
  [deleted]
- vezzy-fnord 11y ago
  I hope the next logical step implied here after this is NOT going back to native applications for everything. Out of curiosity, why? I always thought the model of static documents was a conceptual fit for the web, thinking of it as a file server. The move towards SPAs and real-time apps is really showing the browser's inner-platform effect, and the rough edges of the APIs thereof. Since we are using techniques to create a full parallel OS runtime inside the browser, I wouldn't be surprised if a surge of interest from web developers emerged into simply using the host OS again. By and large I believe the ideal of the browser as being the universal WORA platform to be largely bunk, in that cross-browser compatibility has always been grueling, with the reliance on polyfills and all sorts of ECMAScript and browser API incompatibilities persisting to the point where entire tables and guides are being drawn about them. In hindsight this should have been unsurprising. Just like the Unixes diverge, so do the browsers.
agumonkey 11y ago
Joking about how html6 should be p,a,li,h,span only I googled it. And some people are pretty serious about a massive future version http://www.html6.io/ http://www.html6.io/
- wtetzner 11y ago
  Doesn't seem super serious, given that it's Turtle-based :)
- bpicolo 11y ago
  "This specification is about the 6th version of HТML (HyperTurtle Markup Language), not HTML"
  - agumonkey 11y ago
    Oh the shame. I read that after this http://html6spec.com/ http://html6spec.com/ and thought they were the same (except for the "distribution" side).
  - misuba 11y ago
    "HТML uses a Cyrillic ‘Т’ to avoid any possible confusion with HTML." brb laughing until I cry
briholt 11y ago
With CSS, the concept of differentiated HTML tags basically became obsolete. The purpose of HTML now is just to break apart and identify the content fields in an XML format. The only tags I really use in the HTML body are div and a - and I only use a because I can't add a href attribute into a div. Some people have tried to argue against this way of doing things ("divitus") but as far as I can tell their criticisms are pedantic, not practical. If some one has a good practical argument for specialized HTML tag names, I'd love to hear it.
- artursapek 11y ago
  > If some one has a good practical argument for specialized HTML tag names, I'd love to hear it It can matter in ways for SEO. Having an <h1> helps the robots figure out what your page is called; using <link>s can help explain the organization of your pages; having a <nav> can help influence what your sitelinks[1] will be (if you're enough of a baller to be getting them). [1] https://support.google.com/webmasters/answer/47334?hl=en https://support.google.com/webmasters/answer/47334?hl=en
- bjudson 11y ago
  The argument against this approach is that it's not always humans accessing web pages. And even if it is humans, sometimes they need computer assistance to interpret the content. http://en.wikipedia.org/wiki/Semantic_HTML http://en.wikipedia.org/wiki/Semantic_HTML
  - briholt 11y ago
    As the article says, this is equivalently achieved by naming div classes and IDs (or some other attribute like itemprop a la schema.org). Also I'd say a completely style-free HTML scheme with open-ended semantic tag names (XML) styled by CSS is equivalent. The point is HTML doesn't serve a useful styling purpose.
    - bjudson 11y ago
      I don't have a strong opinion on whether browsers should provide default styling, as it's trivial to override (although many web pages do rely on it). I agree that HTML tag names don't serve a very useful styling purpose, but they provide a useful structural purpose that cannot be easily replaced by using open-ended tag names or classnames. Custom Elements (http://w3c.github.io/webcomponents/spec/custom/ http://w3c.github.io/webcomponents/spec/custom/) are in the process of being implemented, but I don't think that's an argument for throwing out the standard, structural elements that provide a common API for interpreting document structure.
jnbiche 11y ago
I lean toward languages with static typing for application development, but now that there is ES6 and typed arrays, JavaScript is a pretty nice language to program in. And there are a number of very powerful APIs available to browser JS that many people still aren't aware of/don't use to their full potential: WebRTC, Web Audio, WebGL, Transferable Objects in Web Workers, and so forth. I've now stopped using jQuery for DOM manipulations, and use plain JavaScript in most cases involving simple manipulations (I do use React for complex applications). CSS has some problems that grid and Flexbox should help alleviate. But all in all, I'd say the Web is in a pretty good state.
- at-fates-hands 11y ago
  >> But all in all, I'd say the Web is in a pretty good state. Agreed. Not sure why people are always trying to fix something which isn't broke. Ok, yeah, we could fix some things, when you start to micro manage all the tools and technologies people use to build things these days for the interwebs. But seriously, is it really that bad?
- hliyan 11y ago
  I agree. As a C++ developer of ten years (before switching two years back), trust me when I say: JavaScript is not a bad language at all. Six years ago I used to laugh at the language. It has come a long way since then (or I've learned more). So much so, it is now my favorite language. As a side note: do try to not convert JavaScript into a static language -- there are certain types of boilerplate/generated code that I could never eliminate with C++ due to static typing. With JS, it was a breeze.
  - innguest 11y ago
    Unsurprisingly, from the point of view of a C++ programmer, JS doesn't look bad at all.
    - zerr 11y ago
      That's not generally true. Another C++ dev here. I wish Dart had more success... If I were forced today (to do front-end) at least it should be TypeScript.
forrest92 11y ago
What frustrates me about these kind of articles is that they ignore things other than technical perfection. Yes, the web platform isn't the ideal work environment, but at least its got mass adoption and has some kind of standard. Its much easier to program a web front end than it is to program and distribute a gui application using qt. Yes, the web development area needs improvement. JS, CSS, etc. aren't perfect, but improvements are being made, the technology is being pushed forward with every new version number.
- harigov 11y ago
  I disagree when you say that its easier to program web front-end than Qt/GUI application. Although improvements are being made, they are mostly patches rather than rethinking the design given the current usage. I do agree with the author in that there are many broken tools and languages.
  - protomyth 11y ago
    I look at web development tools this way, It is still easier to write an application on NeXTSTEP (edit: machine web was developed on) with its tools than a modern web application. HTML is ok for documents, but I hoping something better comes along in the next 10 or so years.
  - bryanlarsen 11y ago
    It may be easier to program a Qt application, but it's not easier to program and distribute a Qt application.
    - meddlepal 11y ago
      Distribution seems like an easy problem to solve... App stores or software repositories. Am I missing something here? In 2015 all the major platforms have or the other other.
      - coldtea 11y ago
        Exactly. For every web startup or established player, there's an equivalent native app running on a mobile phone, or also on the Desktop (from Facebook, and Twitter to Skype etc).
PretzelFisch 11y ago
There needs to come a point where we let html and javascript exist for static linked documents. And build something better for our applications. Java and Silverlight have failed spectacularly at this so that future does seem quite bleak. There is still some hope with chrome plugins I think.
Kenji 11y ago
As long as we distribute "HTML is done" messages in HTML, it is not done. Well played, though.
- itistoday2 11y ago
  This is the problem with reading only the title of an article...
  - Kenji 11y ago
    I did read the entirety of the article. Do you mind elaborating?
    - itistoday2 11y ago
      He's not saying "HTML is done" as in "over" or "not to be used". He seems to mean something along the lines of "feature complete" and suggests further efforts focus on parts of the web that are lacking (JavaScript, DOM, CSS).
pacomerh 11y ago
Headline means HTML is in an acceptable state, a little misleading
intrasight 11y ago
They are all "done" in that it is unlikely that anything will replace them any time soon. We don't event have, AFAICT, anything on the horizon. But there's a reason for that, and that is that the HTML/JS/CSS stack is the "virtual machine" or "assembly language" of UI development, and as such, we can't any more say they suck than does programming in assembly language. Assembly language is the "given" - unless you build your own CPU. This stack is likewise the "given" at the moment, and developers build an amazing array of tool, services, and billion dollar companies on this VM. Nobody controls this VM, so nobody can engage in rent-seeking behaviour. This has the pleasant effect also that most libraries built on top of are also open-source, and we end up with a very Darwinian landscape. We are now in the Cambrian Explosion, and the body plans that evolve must, by that way of thinking, be the best adapted for their environment.
- deleted 11y ago
  [deleted]
cbr 11y ago
As long as there are very common things that you can only do with JavaScript, HTML is not done. With declarative syntax the browser can be so much faster.
crimsonalucard 11y ago
On the backend the developer chooses his universe. Whether it'd be ruby, python, mongo, postgresql, nodejs, haskell, go, whatever. If the universe sucks people can change everything. If you hate the mopho stack (mongo and php), that's ok, you got other options. With the browser everyone is stuck with one universe. The only thing that changes are front end frameworks which offer some flexibility. Still, if html sucks we're stuck with it. If you hate html or javascript then you hate the entire front end. You exist outside of that universe because Nothing can change it. End of story. I don't know how it could be done while keeping things secure, but it would be awesome if the browser universe was as flexible as the backend. If I could swap between html and any other kind of media based declarative language as easily as I can swap between python and ruby on the backend, it would change the face of frontend development and make it more accessible. In fact what if I wanted to develop my own language that interfaces with the rendering engine? The browser should permit that, because the Web is too broad to be dominated by a single language(HTML). I think this should be the next step.
- isaiahg 11y ago
  What would be really nice is something similar to .Net's virtual machine CLR. It would offer the flexibility to design in whatever language you want and possibly a performance boost as well.
  - nerraga 11y ago
    That only addresses the language component though, right? You'd still be stuck with HTML and CSS. I'm okay with javascript although I'd love to see another language supported in a similar first class fashion. It's HTML and particularly CSS that feel too overloaded, document-centric, and just plain hacky. I think something a little closer to XAML, or possibly like AML, would be a great addition. It'd be great to have support for a responsive layout without having to deal with responsive design as it exists today (amazing as it is).
  - Too 11y ago
    Java applets and Silverlight were attempts on this idea but both failed quite miserably. Not necessarily because the idea itself was bad, in the Java case the execution was bad and the .net case came in a time where moving away from flash was the latest trend and the fear of proprietary lockin from MS too high.
isaiahg 11y ago
I happen to like JavaScript but I agree about HTML, CSS, and the DOM. Actually I would like them to die. It doesn't take a PHD to see that we've moved beyond what the original platform was designed to do. It was designed for documents and styling those documents, but very little of what we do today is making documents. Webapps are king now and designing them means having to work around this outdated platform built for documents. It's so bad that now we require books such as JavaScript the Good Parts to explicitly tell us how to avoid these warts. Instead of iterating further on HTML I think a new open platform should be built that specifically targets interactivity and building applications. Keep HTML for documents, what it was meant for, and begin focusing on something that can address the current needs of developers.
- jdub 11y ago
  very little of what we do today is making documents Do you spend more of your time on the web using applications than you do reading documents? I kind of doubt it. Maybe. But probably not. It may be that you spend more time making web applications than documents. That's understandable. But is the web primarily for you as a developer, or as a user?
  - industriousthou 11y ago
    I would say a substantial amount of time is spent by most users using applications. For instance, Facebook might eat up more than 50% of some users time on the internet, which I think falls under the category of application. Or Youtube, Gmail, etc. There may be a small minority or users who spend a lot of time reading documents (and I applaud them!), but most users are interacting with web applications.
    - chipotle_coyote 11y ago
      Of the three examples you gave -- Facebook, YouTube, and Gmail -- you could make a good case that only Gmail is actually an application: it's a mail client that runs in the browser. YouTube is arguably almost as document-centric than Hacker News is; it's simply that the documents in question are built around embedded videos and their comments. Facebook is somewhere in the middle. It's accreted application-like qualities over the years, but at its core it's assembling a list of text and image items -- i.e., documents -- into a master timeline. I'd submit that an awful lot of web sites that people spend time on have been made very JS-heavy and "application-y" despite being fundamentally document-driven. In part I'm sure this is due to the rise of native mobile applications -- have your server just use a JSON API and make your "web page" a JavaScript application that talks to it the same way your iOS and Android apps do. That development model has become the hammer web developers are using to hit an awful lot of things that maybe really aren't that nail-like.
founderling 11y ago
Would be nice to see some examples of what people don't like about HTML+CSS+JS. I find it quite wonderful. You can make all kinds of magic happen in a simple text file. In an intuitive way. Want to tell something? Just write it: This is some text. How easy was that? Want to show an image? Just a few keystrokes: <img id=animal src="my_kitten.jpg"> Want to style it? Here we go: <style>.animal { border: 5px solid green }</style> Want to change it programmatically? Easy: <script>document.getElementById("animal").src="my_dog.jpg"</script> Deployment? Instantly. Developer tools needed? A text editor. Compatibility? Runs everywhere. Speed? Im often shocked, how fast stuff runs these days. I think we created a paradise. And I enjoy "living" in it every day.
- crimsonalucard 11y ago
  What if I want to use html+css+js to dynamically draw a 1024x1024 picture of a cat with pixel level detail? I'm sure it can be done. But wow. That code would be ugly. Or how about dynamically drawing a diagonal line or swirl across the page? I apologize for the lack of an example, but I'm sure you can imagine how much harder that would be in html and css then it is with a renderer that has bezier curves and lines as primitives.
  - founderling 11y ago
    What if I want to use html+css+js to dynamically draw a 1024x1024 picture of a cat Here is your cat: http://upload.wikimedia.org/wikipedia/commons/f/fd/Ghostscript_Tiger.svg http://upload.wikimedia.org/wikipedia/commons/f/fd/Ghostscri... a renderer that has bezier curves and lines SVG is part of the HTML standard and has those. And much more: http://www.google.com/search?q=svg+examples http://www.google.com/search?q=svg+examples
    - crimsonalucard 11y ago
      I said pixel level. That's vector level. Also by html+css+javascript I thought you meant strictly primitives within that domain like spans and divs. While svg is part of html5 people typically don't think of svg when someone says to write something in html+css+javascript. Either way, well played, sir.
jokoon 11y ago
It's the same problem XML has. It's bloated and unreadable for a human. YAML is much better in that regard, and I wonder if one could build a document language with a syntax that resemble json. Have you ever opened the html content of any common webpage ? It's insane, in size and indenting, it's impossible to make sense of it, it would make much more sense to have an open binary format and let developers deal with it. HTML has way too many attribute that stacked on each others. People will defend its openness, but I pity the guys who write html parser for internet browsers. HTML thrived because its openness allowed to bypass microsoft and its closed solutions, but other than that...
ivanhoe 11y ago
Different people have different problems. For a web dev HTTP is "basically OK" as author says, but for a network engineer it is very much not (to the point that 2.0 was created to be completely different). I personally don't see how some new html/js/css dialect could efficiently solve the problems for everyone out there. How do you make both CoffeeScript and Dart user happy with a single syntax? I prefer to have a bunch of specialized high-level tools to choose from depending on a situation, than forcing them all into some one-size-fits-all mishmash (which almost always fails)
peterashford 11y ago
The basic problem can be described quite simply. HTML was designed for the World Wide Web - a matrix of hyperlinked documents. For that purpose it more or less has succeeded (some people were more ambitious about what authoring hypertext should have achieved but I'll ignore that wrinkle). However, these days people want to do things with the web other than write hypertext - they're wanting applications on the web in just the same way we want applications on our computers or apps on our phones. And for THAT purpose, HTML / CSS / DOM is utter gobshite. If I want to write an application, the bottom of layer of that shouldn't be "now convert that into something that perverts document layout of the browser to look like something that hasn't been laid out like an HTML document". We need a technology that is suitable as a compilation target: a virtual machine. It can be optimised to hell (better than JS which necessarily is always compromised by having to be JavaScript and not byte code) and we need a suite of basic machine systems - sound, graphics, storage. We're not really all that far off from these things with what is supplied with HTML 5 it just sucks that the core of the affair - HTML/CSS/JS - is rotten through and through.
- sktrdie 11y ago
  I think UI really shines using the Web stack because it was built using async tools from the very beginning. UI development should be async from the get go. In other non-webby systems you do UI using async but you're still using blocking tools (for example by using Java's mixture of async for UI but blocking for other stuff). JavaScript on the other hand, and all of its libraries, are entirely async which makes it a pleasure to work with - it's a much more natural environment to be doing UI in (single thread and everything is there to be used without multi-threading complicated stuff). This is a big insight that JS and other webby-tools have given to the UI world, and I strongly believe something entirely async needs to exist for the desktop/mobile world as well - fortunately there is in the form of node.js/electron/nw.js. Now in terms of how that's handled behind the scenes, I don't really care (use a nice VM, use a whatever mixture of whatever you want). Just give me a fully-async toolset to build my app in a single thread and I'm happy.
  - peterashford 11y ago
    I can't agree that UI via JS async is a pleasure to work with. I can't think of a UI technology I've found less pleasurable to work with. No - there was an ancient C GUI that used all C Macros to compose - that was worse... but only just.

160 points by AndrewDucker 11y ago

Popular javascript frameworks exist to "work around" problems with javascript and CSS frameworks exist to "work around" problems with CSS? There's no magic with Angular or Bootstrap, they're codifying an approach using 100% native JS or CSS. Even SASS and LESS are just alternative ways to produce CSS. This is not novel in computing.

bradhe 11y ago
Totally true. That's like saying the Ruby on Rails exists because Ruby is somehow deficient.
- fao_ 11y ago
  But, your analogy is flawed; the situations are incomparable. You're not forced to use Rails for your server application, many other software exists as well as Rails: Django, PHP, etc. However you /are/ forced to use Javascript, CSS and the DOM; Unless you're a Big Browser Vendor and can try and coerce support (and even so, the amount of websites made in something like Dash is pitiful afaik). People made frameworks and libraries that make it bearable (SCSS, JQuery, etc), but that doesn't mean everything is solved...
  - nkozyra 11y ago
    That's a totally different analogy altogether. The argument expressed on that page isn't that there is a lack of choices, but that the choices are inherently flawed (and somehow "fixed" by frameworks that lie on top).
krapp 11y ago
This seems to basically be the argument for preferring compile-to-js languages over vanilla javascript, even though by definition any advantages in the former have to exist in the latter. Yet if I were to call coffeescript an overly complex javascript framework, people would probably strenuously disagree. But that is what it amounts to.
- amsheehan 11y ago
  I disagree, but not strenuously :) Purescript compiles down to javascript but helps save programmers from themselves by introducing a better type system as well as great data structures, and functional paradigms Typescript adds static typing and OOP CoffeeScript...is syntactic sugar? (okay maybe I agree with the coffeescript sentiment)
  - krapp 11y ago
    Fair enough. Although I don't entirely agree that compiling a statically typed language into javascript really helps much, since the end result is still... javascript in a browser. But the last time I tried to defend that I got almost universally disagreed with, so I'll concede that the process might have value I just don't see.

jph 11y ago

HTML has many areas to improve still -- for example HTML-next can make it easier to do hypertext markup to a list of articles, including article title, author, date, contact links to social sites, and some summary text. (Currently this is accomplished by munging the tags for cite, article, author, and jumping through some small hoops for microformats.)

javajosh 11y ago

Tim Bray or not, it's irresponsible to point out a pile of shit without pointing to a shovel. (And for the record I disagree that there is a pile of shit. I see a bazaar of indy components.) The browser exists in open opposition to iOS and Android, technically, culturally, and stewardship-wise. No-one in their right mind is going to pick a web host that charges you 30% of revenue. And yet, that's what Apple has managed to get (and they just control the BLOB distribution channel, they don't even provide runtime servers!). The whole shebang is sorting itself out and I for one think it's going to be very, very cool.

pourhhd 11y ago
People pick that "web host" because the platform you think is so great sucks ass. People have said this morass of nonsense was sorting itself out since gmail came on the scene. Things have been sorting out for web apps before mobile was even a viable thing.
nly 11y ago
> No-one in their right mind is going to pick a web host that charges you 30% of revenue. Eh? What stops you from publishing a free app with ads?
- mikegioia 11y ago
  Integrity? User experience?
  - nly 11y ago
    Nobody seems to care about that on the web.
leoc 11y ago
> it's irresponsible to point out a pile of shit without pointing to a shovel. That's not true in general, but since in this case Tim Bray seems to be implicitly proposing an alternative of sorts (never mind whether it's in fact any better) that isn't really relevant. For what it's worth, this https://news.ycombinator.com/item?id=2119057 https://news.ycombinator.com/item?id=2119057 is the correct solution.

serve_yay 11y ago

I basically agree, except that I really like JavaScript (the language, not the APIs necessarily) and I think it gets a bad rap.

savanaly 11y ago
I have only programmed in Ruby and Java and Javascript (and the first two only a little). ES5 and before js does seem worse than the other languages I've experienced, but not by much. And ES6 is sort of a joy to write. Leaving callbacks behind for promises and writing in a largely functional style is very satisfying in js right now.

Udo 11y ago

The point of the article seems to be that HTML is done because it's "basically OK", and everything around it is done because it's awful and can't be salvaged anyway. I hope the next logical step implied here after this is NOT going back to native applications for everything. The browser-as-a-platform is based on a lousy programming language addressing a lousy object model and using a lousy stylesheet language for visuals. I think JavaScript is a suboptimal programming language because it has too many features, and on top of that they tacked on yet more features recently. I wouldn't call CSS lousy either, and the API of the DOM even got better over the years. We almost never phase anything out, and that's a problem, but I think the core issue causing suckage within the 3 pillars (4 if you count the DOM separately) is that they have been explicitly designed to not work together very well. While you can - and often are forced to - extend CSS and HTML with JavaScript, they didn't make the interplay between them especially synergistic. As for HTML? Not perfect, but plenty good enough. no, I don't think so, especially if we're discarding JS and CSS as garbage, HTML does not deserve to get a free pass. Even if we wanted to improve it, there are no obvious candidates to do the work. I don't get why we're all of a sudden in an arbitrarily constructed situation where the whole web platform can never be iterated on again. Ever. But if the point is that whatever comes next probably won't come out of a committee that sounds about right. I agree that some of the frameworks mentioned exist to work around the issues we created in the browser platform. Especially the functionality of React should be considered for an adoption scenario, maybe not the exact React API, but something along those lines that makes working on (or at least applying) diffs easier. The same goes for handlebars-like templating. I would rather see some of these adopted than the effort that goes into giving classes to JavaScript.

deleted 11y ago
[deleted]
vezzy-fnord 11y ago
I hope the next logical step implied here after this is NOT going back to native applications for everything. Out of curiosity, why? I always thought the model of static documents was a conceptual fit for the web, thinking of it as a file server. The move towards SPAs and real-time apps is really showing the browser's inner-platform effect, and the rough edges of the APIs thereof. Since we are using techniques to create a full parallel OS runtime inside the browser, I wouldn't be surprised if a surge of interest from web developers emerged into simply using the host OS again. By and large I believe the ideal of the browser as being the universal WORA platform to be largely bunk, in that cross-browser compatibility has always been grueling, with the reliance on polyfills and all sorts of ECMAScript and browser API incompatibilities persisting to the point where entire tables and guides are being drawn about them. In hindsight this should have been unsurprising. Just like the Unixes diverge, so do the browsers.

agumonkey 11y ago

Joking about how html6 should be p,a,li,h,span only I googled it. And some people are pretty serious about a massive future version http://www.html6.io/ http://www.html6.io/

wtetzner 11y ago
Doesn't seem super serious, given that it's Turtle-based :)
bpicolo 11y ago
"This specification is about the 6th version of HТML (HyperTurtle Markup Language), not HTML"
- agumonkey 11y ago
  Oh the shame. I read that after this http://html6spec.com/ http://html6spec.com/ and thought they were the same (except for the "distribution" side).
- misuba 11y ago
  "HТML uses a Cyrillic ‘Т’ to avoid any possible confusion with HTML." brb laughing until I cry

briholt 11y ago

With CSS, the concept of differentiated HTML tags basically became obsolete. The purpose of HTML now is just to break apart and identify the content fields in an XML format. The only tags I really use in the HTML body are div and a - and I only use a because I can't add a href attribute into a div. Some people have tried to argue against this way of doing things ("divitus") but as far as I can tell their criticisms are pedantic, not practical. If some one has a good practical argument for specialized HTML tag names, I'd love to hear it.

artursapek 11y ago
> If some one has a good practical argument for specialized HTML tag names, I'd love to hear it It can matter in ways for SEO. Having an <h1> helps the robots figure out what your page is called; using <link>s can help explain the organization of your pages; having a <nav> can help influence what your sitelinks[1] will be (if you're enough of a baller to be getting them). [1] https://support.google.com/webmasters/answer/47334?hl=en https://support.google.com/webmasters/answer/47334?hl=en
bjudson 11y ago
The argument against this approach is that it's not always humans accessing web pages. And even if it is humans, sometimes they need computer assistance to interpret the content. http://en.wikipedia.org/wiki/Semantic_HTML http://en.wikipedia.org/wiki/Semantic_HTML
- briholt 11y ago
  As the article says, this is equivalently achieved by naming div classes and IDs (or some other attribute like itemprop a la schema.org). Also I'd say a completely style-free HTML scheme with open-ended semantic tag names (XML) styled by CSS is equivalent. The point is HTML doesn't serve a useful styling purpose.
  - bjudson 11y ago
    I don't have a strong opinion on whether browsers should provide default styling, as it's trivial to override (although many web pages do rely on it). I agree that HTML tag names don't serve a very useful styling purpose, but they provide a useful structural purpose that cannot be easily replaced by using open-ended tag names or classnames. Custom Elements (http://w3c.github.io/webcomponents/spec/custom/ http://w3c.github.io/webcomponents/spec/custom/) are in the process of being implemented, but I don't think that's an argument for throwing out the standard, structural elements that provide a common API for interpreting document structure.

jnbiche 11y ago

I lean toward languages with static typing for application development, but now that there is ES6 and typed arrays, JavaScript is a pretty nice language to program in. And there are a number of very powerful APIs available to browser JS that many people still aren't aware of/don't use to their full potential: WebRTC, Web Audio, WebGL, Transferable Objects in Web Workers, and so forth. I've now stopped using jQuery for DOM manipulations, and use plain JavaScript in most cases involving simple manipulations (I do use React for complex applications). CSS has some problems that grid and Flexbox should help alleviate. But all in all, I'd say the Web is in a pretty good state.

at-fates-hands 11y ago
>> But all in all, I'd say the Web is in a pretty good state. Agreed. Not sure why people are always trying to fix something which isn't broke. Ok, yeah, we could fix some things, when you start to micro manage all the tools and technologies people use to build things these days for the interwebs. But seriously, is it really that bad?
hliyan 11y ago
I agree. As a C++ developer of ten years (before switching two years back), trust me when I say: JavaScript is not a bad language at all. Six years ago I used to laugh at the language. It has come a long way since then (or I've learned more). So much so, it is now my favorite language. As a side note: do try to not convert JavaScript into a static language -- there are certain types of boilerplate/generated code that I could never eliminate with C++ due to static typing. With JS, it was a breeze.
- innguest 11y ago
  Unsurprisingly, from the point of view of a C++ programmer, JS doesn't look bad at all.
  - zerr 11y ago
    That's not generally true. Another C++ dev here. I wish Dart had more success... If I were forced today (to do front-end) at least it should be TypeScript.

forrest92 11y ago

What frustrates me about these kind of articles is that they ignore things other than technical perfection. Yes, the web platform isn't the ideal work environment, but at least its got mass adoption and has some kind of standard. Its much easier to program a web front end than it is to program and distribute a gui application using qt. Yes, the web development area needs improvement. JS, CSS, etc. aren't perfect, but improvements are being made, the technology is being pushed forward with every new version number.

harigov 11y ago
I disagree when you say that its easier to program web front-end than Qt/GUI application. Although improvements are being made, they are mostly patches rather than rethinking the design given the current usage. I do agree with the author in that there are many broken tools and languages.
- protomyth 11y ago
  I look at web development tools this way, It is still easier to write an application on NeXTSTEP (edit: machine web was developed on) with its tools than a modern web application. HTML is ok for documents, but I hoping something better comes along in the next 10 or so years.
- bryanlarsen 11y ago
  It may be easier to program a Qt application, but it's not easier to program and distribute a Qt application.
  - meddlepal 11y ago
    Distribution seems like an easy problem to solve... App stores or software repositories. Am I missing something here? In 2015 all the major platforms have or the other other.
    - coldtea 11y ago
      Exactly. For every web startup or established player, there's an equivalent native app running on a mobile phone, or also on the Desktop (from Facebook, and Twitter to Skype etc).

PretzelFisch 11y ago

There needs to come a point where we let html and javascript exist for static linked documents. And build something better for our applications. Java and Silverlight have failed spectacularly at this so that future does seem quite bleak. There is still some hope with chrome plugins I think.

Kenji 11y ago

As long as we distribute "HTML is done" messages in HTML, it is not done. Well played, though.

itistoday2 11y ago
This is the problem with reading only the title of an article...
- Kenji 11y ago
  I did read the entirety of the article. Do you mind elaborating?
  - itistoday2 11y ago
    He's not saying "HTML is done" as in "over" or "not to be used". He seems to mean something along the lines of "feature complete" and suggests further efforts focus on parts of the web that are lacking (JavaScript, DOM, CSS).

pacomerh 11y ago

Headline means HTML is in an acceptable state, a little misleading

intrasight 11y ago

They are all "done" in that it is unlikely that anything will replace them any time soon. We don't event have, AFAICT, anything on the horizon. But there's a reason for that, and that is that the HTML/JS/CSS stack is the "virtual machine" or "assembly language" of UI development, and as such, we can't any more say they suck than does programming in assembly language. Assembly language is the "given" - unless you build your own CPU. This stack is likewise the "given" at the moment, and developers build an amazing array of tool, services, and billion dollar companies on this VM. Nobody controls this VM, so nobody can engage in rent-seeking behaviour. This has the pleasant effect also that most libraries built on top of are also open-source, and we end up with a very Darwinian landscape. We are now in the Cambrian Explosion, and the body plans that evolve must, by that way of thinking, be the best adapted for their environment.

deleted 11y ago
[deleted]

cbr 11y ago

As long as there are very common things that you can only do with JavaScript, HTML is not done. With declarative syntax the browser can be so much faster.

crimsonalucard 11y ago

On the backend the developer chooses his universe. Whether it'd be ruby, python, mongo, postgresql, nodejs, haskell, go, whatever. If the universe sucks people can change everything. If you hate the mopho stack (mongo and php), that's ok, you got other options. With the browser everyone is stuck with one universe. The only thing that changes are front end frameworks which offer some flexibility. Still, if html sucks we're stuck with it. If you hate html or javascript then you hate the entire front end. You exist outside of that universe because Nothing can change it. End of story. I don't know how it could be done while keeping things secure, but it would be awesome if the browser universe was as flexible as the backend. If I could swap between html and any other kind of media based declarative language as easily as I can swap between python and ruby on the backend, it would change the face of frontend development and make it more accessible. In fact what if I wanted to develop my own language that interfaces with the rendering engine? The browser should permit that, because the Web is too broad to be dominated by a single language(HTML). I think this should be the next step.

isaiahg 11y ago
What would be really nice is something similar to .Net's virtual machine CLR. It would offer the flexibility to design in whatever language you want and possibly a performance boost as well.
- nerraga 11y ago
  That only addresses the language component though, right? You'd still be stuck with HTML and CSS. I'm okay with javascript although I'd love to see another language supported in a similar first class fashion. It's HTML and particularly CSS that feel too overloaded, document-centric, and just plain hacky. I think something a little closer to XAML, or possibly like AML, would be a great addition. It'd be great to have support for a responsive layout without having to deal with responsive design as it exists today (amazing as it is).
- Too 11y ago
  Java applets and Silverlight were attempts on this idea but both failed quite miserably. Not necessarily because the idea itself was bad, in the Java case the execution was bad and the .net case came in a time where moving away from flash was the latest trend and the fear of proprietary lockin from MS too high.

isaiahg 11y ago

I happen to like JavaScript but I agree about HTML, CSS, and the DOM. Actually I would like them to die. It doesn't take a PHD to see that we've moved beyond what the original platform was designed to do. It was designed for documents and styling those documents, but very little of what we do today is making documents. Webapps are king now and designing them means having to work around this outdated platform built for documents. It's so bad that now we require books such as JavaScript the Good Parts to explicitly tell us how to avoid these warts. Instead of iterating further on HTML I think a new open platform should be built that specifically targets interactivity and building applications. Keep HTML for documents, what it was meant for, and begin focusing on something that can address the current needs of developers.

jdub 11y ago
very little of what we do today is making documents Do you spend more of your time on the web using applications than you do reading documents? I kind of doubt it. Maybe. But probably not. It may be that you spend more time making web applications than documents. That's understandable. But is the web primarily for you as a developer, or as a user?
- industriousthou 11y ago
  I would say a substantial amount of time is spent by most users using applications. For instance, Facebook might eat up more than 50% of some users time on the internet, which I think falls under the category of application. Or Youtube, Gmail, etc. There may be a small minority or users who spend a lot of time reading documents (and I applaud them!), but most users are interacting with web applications.
  - chipotle_coyote 11y ago
    Of the three examples you gave -- Facebook, YouTube, and Gmail -- you could make a good case that only Gmail is actually an application: it's a mail client that runs in the browser. YouTube is arguably almost as document-centric than Hacker News is; it's simply that the documents in question are built around embedded videos and their comments. Facebook is somewhere in the middle. It's accreted application-like qualities over the years, but at its core it's assembling a list of text and image items -- i.e., documents -- into a master timeline. I'd submit that an awful lot of web sites that people spend time on have been made very JS-heavy and "application-y" despite being fundamentally document-driven. In part I'm sure this is due to the rise of native mobile applications -- have your server just use a JSON API and make your "web page" a JavaScript application that talks to it the same way your iOS and Android apps do. That development model has become the hammer web developers are using to hit an awful lot of things that maybe really aren't that nail-like.

founderling 11y ago

Would be nice to see some examples of what people don't like about HTML+CSS+JS. I find it quite wonderful. You can make all kinds of magic happen in a simple text file. In an intuitive way. Want to tell something? Just write it: This is some text. How easy was that? Want to show an image? Just a few keystrokes: <img id=animal src="my_kitten.jpg"> Want to style it? Here we go: <style>.animal { border: 5px solid green }</style> Want to change it programmatically? Easy: <script>document.getElementById("animal").src="my_dog.jpg"</script> Deployment? Instantly. Developer tools needed? A text editor. Compatibility? Runs everywhere. Speed? Im often shocked, how fast stuff runs these days. I think we created a paradise. And I enjoy "living" in it every day.

crimsonalucard 11y ago
What if I want to use html+css+js to dynamically draw a 1024x1024 picture of a cat with pixel level detail? I'm sure it can be done. But wow. That code would be ugly. Or how about dynamically drawing a diagonal line or swirl across the page? I apologize for the lack of an example, but I'm sure you can imagine how much harder that would be in html and css then it is with a renderer that has bezier curves and lines as primitives.
- founderling 11y ago
  What if I want to use html+css+js to dynamically draw a 1024x1024 picture of a cat Here is your cat: http://upload.wikimedia.org/wikipedia/commons/f/fd/Ghostscript_Tiger.svg http://upload.wikimedia.org/wikipedia/commons/f/fd/Ghostscri... a renderer that has bezier curves and lines SVG is part of the HTML standard and has those. And much more: http://www.google.com/search?q=svg+examples http://www.google.com/search?q=svg+examples
  - crimsonalucard 11y ago
    I said pixel level. That's vector level. Also by html+css+javascript I thought you meant strictly primitives within that domain like spans and divs. While svg is part of html5 people typically don't think of svg when someone says to write something in html+css+javascript. Either way, well played, sir.

jokoon 11y ago

It's the same problem XML has. It's bloated and unreadable for a human. YAML is much better in that regard, and I wonder if one could build a document language with a syntax that resemble json. Have you ever opened the html content of any common webpage ? It's insane, in size and indenting, it's impossible to make sense of it, it would make much more sense to have an open binary format and let developers deal with it. HTML has way too many attribute that stacked on each others. People will defend its openness, but I pity the guys who write html parser for internet browsers. HTML thrived because its openness allowed to bypass microsoft and its closed solutions, but other than that...

ivanhoe 11y ago

Different people have different problems. For a web dev HTTP is "basically OK" as author says, but for a network engineer it is very much not (to the point that 2.0 was created to be completely different). I personally don't see how some new html/js/css dialect could efficiently solve the problems for everyone out there. How do you make both CoffeeScript and Dart user happy with a single syntax? I prefer to have a bunch of specialized high-level tools to choose from depending on a situation, than forcing them all into some one-size-fits-all mishmash (which almost always fails)

peterashford 11y ago

The basic problem can be described quite simply. HTML was designed for the World Wide Web - a matrix of hyperlinked documents. For that purpose it more or less has succeeded (some people were more ambitious about what authoring hypertext should have achieved but I'll ignore that wrinkle). However, these days people want to do things with the web other than write hypertext - they're wanting applications on the web in just the same way we want applications on our computers or apps on our phones. And for THAT purpose, HTML / CSS / DOM is utter gobshite. If I want to write an application, the bottom of layer of that shouldn't be "now convert that into something that perverts document layout of the browser to look like something that hasn't been laid out like an HTML document". We need a technology that is suitable as a compilation target: a virtual machine. It can be optimised to hell (better than JS which necessarily is always compromised by having to be JavaScript and not byte code) and we need a suite of basic machine systems - sound, graphics, storage. We're not really all that far off from these things with what is supplied with HTML 5 it just sucks that the core of the affair - HTML/CSS/JS - is rotten through and through.

sktrdie 11y ago
I think UI really shines using the Web stack because it was built using async tools from the very beginning. UI development should be async from the get go. In other non-webby systems you do UI using async but you're still using blocking tools (for example by using Java's mixture of async for UI but blocking for other stuff). JavaScript on the other hand, and all of its libraries, are entirely async which makes it a pleasure to work with - it's a much more natural environment to be doing UI in (single thread and everything is there to be used without multi-threading complicated stuff). This is a big insight that JS and other webby-tools have given to the UI world, and I strongly believe something entirely async needs to exist for the desktop/mobile world as well - fortunately there is in the form of node.js/electron/nw.js. Now in terms of how that's handled behind the scenes, I don't really care (use a nice VM, use a whatever mixture of whatever you want). Just give me a fully-async toolset to build my app in a single thread and I'm happy.
- peterashford 11y ago
  I can't agree that UI via JS async is a pleasure to work with. I can't think of a UI technology I've found less pleasurable to work with. No - there was an ancient C GUI that used all C Macros to compose - that was worse... but only just.