Live data from Hacker News

HTML6 proposal for single-page apps without JavaScript

lists.w3.org

71–80 of 177 posts

Re: HTML6 proposal for single-page apps without JavaScript

#71
post #6

I really don't like this proposal. For me, HTML is the markup for the design of the page, while JavaScript makes up the logic. While some frameworks break this, they are strictly opt-in, and they still offer a bit of separation of duties. I'd rather see the HTML standard stay markup-focus for now.

I wish strict XHTML was taken more seriously. HTML is the structure, CSS is the look, and JavaScript is the logic. With a strict XHTML style you can further enforce this by removing former standards which don't follow that design (e.g. OnClick="" etc). HTML5 is alright, but I'd like to see a strict HTML5 which bans a ton of classic HTML4.1 elements completely and also follows XHTML's much more logical style (and bans…

Strictness accomplishes nothing whatsoever. If you remove presentational elements, people just abuse semantic elements.

Re: HTML6 proposal for single-page apps without JavaScript

#74
post #56

[deleted]

Unless you are using IE http://caniuse.com/#feat=history

There are quite a large number of people who still have to support Also the whole SEO issues are not something the sneeze at. I've yet to see a comprehensive approach to this that doesn't involve phantomjs running to serve up HTML to search engine bots. Maybe the bots will just get smarter and we won't have to worry about it but the jury is still out on that.

Luckity once I get to stop supporting IE9 I can go to single page (with push state) because the app I work on does not get seen by search bots and SEO is not a concern.

Re: HTML6 proposal for single-page apps without JavaScript

#75
post #10

I'm not necessarily opposed to something along these lines, except that it's basically already been tried: XSLT was essentially the inverse of this, where data endpoints were annotated with some static rendering descriptors. To me the XSLT approach seems cleaner, in that the URLs the browser is visiting are for the raw data itself, the URL scheme between machine and human is identical, and so on. XSLT also encouraged…

XSLT was an interesting language that unfortunately tried to solve the wrong problem. What we needed was AWK for the DOM. Instead we got a vision where XML would be used to transform other forms XML into yet OTHER forms of XML, and the result was a mess.

I think there's still a place for an "AWK for the DOM". The XML extensions to gawk are interesting, but not really what I'm talking about; it works at a lower level (more like an "AWK for SAX"). jQuery comes closer to what I'm talking about, but I still wouldn't really call it a clean match.

Re: HTML6 proposal for single-page apps without JavaScript

#76

I see three problem here, none of which have anything to do with HTML as a markup language. 1. The amount of DOM manipulation required for a relatively advanced single page app is not very efficient, quick or performant. 2. Web apps don't work well without a reasonably up to date javascript engine - users may not even allow Javasacript to be run. This breaks alot of web apps. 3. There isn't an (easy) way to request p…

> Either make your web apps fallback to HTML + CSS

So make two Web apps with the same functionality, basically?

Re: HTML6 proposal for single-page apps without JavaScript

#77
post #50

Earlier quoted context omitted.

Yep. I used to love XSLT -- working in it finally forced me to understand recursion at, like, a deep cellular level -- but the whole time I was using it I knew it was a doomed language (because most people don't want to have to understand recursion at a deep cellular level just to be able to lay out a damn web page.)

XSLT is still good to learn -- I think it's conceptually sound, but its implementations are often terrible. I think the big pain points for most people are how finicky XML is in general, but also that any libs you use to generate your XML and translate it require an absurd amount of configuration. Years ago, I saw all the weaknesses in mixed PHP/html for building pages, but all the server-side templating languages lo…

Agreed re composition -- the sign that the language had finally 'clicked' was when you started seeing lots of little xsl:templates instead of one gigantic mass of if statements.

I don't really agree that cruft or configuration difficulties were the problem, though. Verbose, sure, fine, but otherwise spare to a fault.

I suspect it's more that it demanded understanding of fairly sophisticated coding concepts to be at all useful, but was too often perceived as "front end" tech, or as just another markup language -- so ended up being dropped in the laps of too many designers-with-a-few-javascript-recipes-under-their-belts who simply weren't equipped to cope with it.

I spent a while running XSLT training sessions for a corporate client; 95% of my trainees would just reel away in disgust and confusion the instant they learned they wouldn't be able to, say, increment a variable. (The remaining handful would be all OMG THIS IS WHAT I HAVE BEEN WAITING FOR MY WHOLE LIFE. It got to be a little game of mine to try to predict ahead of time who would be which.)

Maybe it was just ahead of its time; the average front-end web developer is a lot more sophisticated these days than we were back then. (yes yes get off my lawn I have clouds to shout at)

Re: HTML6 proposal for single-page apps without JavaScript

#78
post #10

I'm not necessarily opposed to something along these lines, except that it's basically already been tried: XSLT was essentially the inverse of this, where data endpoints were annotated with some static rendering descriptors. To me the XSLT approach seems cleaner, in that the URLs the browser is visiting are for the raw data itself, the URL scheme between machine and human is identical, and so on. XSLT also encouraged…

XSLT was an interesting language that unfortunately tried to solve the wrong problem. What we needed was AWK for the DOM. Instead we got a vision where XML would be used to transform other forms XML into yet OTHER forms of XML, and the result was a mess. I think there's still a place for an "AWK for the DOM". The XML extensions to gawk are interesting, but not really what I'm talking about; it works at a lower level…

That's a good idea - keep XPath but lose the XML based syntax.

Edit: In fact, lose the XML completely and go with JSON and JSONPath.

Re: HTML6 proposal for single-page apps without JavaScript

#79
post #53

This proposal is trying to take a common web design pattern, MVC, and make it part of the official spec. HTML is a _markup language_, it's ridiculous to use it as anything but a semantic language. Here's my HTML6 proposal: There’s a standard design pattern emerging via cascading style sheets, where content is styled directly via CSS. Everyone’s into it because the layout looks so much nicer. Since this is so common n…

> HTML is a _markup language_, it's ridiculous to use it as anything but a semantic language.

So which is it? A semantic language or a markup (syntax) language?

Why does it have to stay that way? (Even if the proposal is a bad one.)

Post reply on HN