13 ms·

HTML6 proposal for single-page apps without JavaScript

187 points by matthewmacleod 12y ago

hias 12y ago
so...iframes?
- CraneWorm 12y ago
  ... except instead of loading arbitrary url he actually proposes some structure. This could work for most websites depending on ajax to load their content. Say, instead of xml you get a language similar to django templates.
baby 12y ago
I'm very skeptical about this. HTML is a fixed language for reasons. It is not supposed to be able to parse a JSON file.
agumonkey 12y ago
Other members are worried this is just shifting complexity for no real value. A mistake they did in the past. https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Mar/0073.html https://lists.w3.org/Archives/Public/public-whatwg-archive/2... My opinion too.
RandomBK 12y ago
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.
- Someone1234 12y ago
  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="" <b> <i> <font> 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 <br /> style (and bans things like <br> which make no sense). I understand why they went the way they did (backwards compatibility mostly), but feel like the web would be in a better place ten years from now if a strict spec for at least HTML was commonly used.
  - TazeTSchnitzel 12y ago
    Strictness accomplishes nothing whatsoever. If you remove presentational elements, people just abuse semantic elements.
    - astine 12y ago
      I would make parsers and generators much easier to write.
      - emodendroket 12y ago
        But there are millions of pages that will never be updated and if a browser can't render them people are going to blame the browser, not the use of deprecated HTML elements (an issue they won't even have awareness of).
        Someone1234 12y ago
        That's just a generic argument for no new HTML ever.
        emodendroket 12y ago
        No it isn't; it's an argument against breaking changes.
    - Someone1234 12y ago
      > Strictness accomplishes nothing whatsoever. Sure it does, it means it is impossible to mix logic or styling into your HTML inline. That makes HTML more maintainable and teaching it easier (less is always easier to teach than more). What semantic elements are you worried about them abusing? I cannot think of a semantic element which replaces defunct presentational elements without any CSS (which would makes the entire argument redundant).
      - TazeTSchnitzel 12y ago
Dirlewanger 12y ago
Never too early to start work on something we'll see in a couple decades.
daemonk 12y ago
I think we should keep HTML simple and enforce a strict separation between template and logic. However, I do like the idea of adding a native "model" attribute to the DOM element that can automatically get/parse json and update accordingly.
- smt88 12y ago
  Have you ever used React? What do you think about the React/Flux methods of mixing template and logic?
  - daemonk 12y ago
    Good point. I do use react and I find jsx to be very convenient. I guess the question is: would I want to write something similar to JSX and have the browser be able to interpret that natively. I honestly don't know.
    - smt88 12y ago
      Yeah, I'm ambivalent myself. The main problem with W3 standards is that they assumed they knew what we'd want to do with them. No one predicted HTML would become the UI layer for complex replacements for desktop applications, so for a long time, it sucked at that job. Now they're trying to rectify those mistakes, but I think they might be going too far in the other direction. Instead, web standards need to be as simple, low-level, and generic as possible. The more HTML approaches an opinionated UI framework, the worse off we all are (in my opinion).
arenaninja 12y ago
Great, now I need 3 years experience in it by the end of the month
- Roboprog 12y ago
  No kidding. I just started learning Angular, and now this. Fortunately, it sounds like it will die an unpopular death.
_wmd 12y ago
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 producing network-friendly compound representations for data, rather than the typical small collection of pure CRUD endpoints over fixed structures (/users/1, /comments/1231, etc.), since XSLT had limited ability to trigger loading external data without falling back to Javascript hacks or similar. But I imagine the tragic flaw in both the data binding proposal here and how XSLT worked is massively increased complexity for fairly little gain - and I think that's why XSLT has died a gentle death over the past decade. Still, both ideas appeal to me from the perspective of escaping horrendous chunks of procedural macros being shipped with data just to make it render on the client.
- outsidetheparty 12y ago
  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.)
  - pjmlp 12y ago
    Yet, alongside XHTML it would allow to move HTML to a proper layout engine like most native GUIs have, instead of the hack-a-mole we have to deal with.
  - jkoudys 12y ago
    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 looked terrible (still do). I fell in love with the idea that was championed back in the late 90s, where you use your application to build XML, which only describes your data. You'd then have some XSLT on your web server (or in-browser) that would transform the XML into your document. Nowadays, this isn't that different of an approach from using my server-side PHP/python/node/Go to generate JSON, then building my DOM based on client-side templates; since I use ReactJS, my transforms are even still XML. A lot of the best-practices I learned from XSLT transferred over nicely too, e.g. avoiding control logic (<xsl:if>) in favour of <xsl:apply-templates>, since good javascript client-side templates should avoid branching control logic in favour of just Array.prototype.map() wherever you can. I think the real key isn't about understanding recursion, though you will gradually gain an appreciation for it, but understanding composition. Templating is too often done in the style common among poor developers, where they think about building a whole "page", instead of defining the components of that page. XSLT, in theory, would've been great for that, it's just a pain in the butt to actually implement. tl;dr if there is a need for this proposal, it would be better met by cleaning out all the cruft from XSLT, and building implementations that don't require such arcane syntax nobody can use it.
itsbits 12y ago
Its not completely to replace Javascript but basically a standard to load HTML like iframes except its not.
tinganho 12y ago
I definitely don't like this proposal. SPA:s is under a heavily innovative period. Standardizing it will only slow downs its' development.
- iso8859-1 12y ago
  No one will force you to use it, browsers have always been reasonably backwards compatible, except regarding stuff like ActiveX, applets, and HSTS.
jalfresi 12y ago
Am I mistaken, but this kinda looks like XForms. Why not just use XForms? Edit: Obviously I understand that XForms isn't a viable option these days, but that is kinda my point. Why isn't XForms an option? Those reasons appear to apply to this proposal too...
- pjmlp 12y ago
  Because XHTML was killed, when it could have become the XAML of the web, so the circle comes back to "another day another hack".
bananaoomarang 12y ago
This is interesting, but like others I think HTML should be kept strictly for templating, and this adds an unnecessary amount of logic. It might be tempting to see this as removing complication, but in actuality it will probably add to it by reducing separation of concerns. I think it would be good for less ambitious projects, but in the end it would cripple the building of more ambitious ones. If we already have Angular/React/Components/Whatever, shouldn't we just keep working on them and leave the HTML spec unpolluted?
- moron4hire 12y ago
  HTML does not do templating, either.
  - pfooti 12y ago
    I'm just going to leave this here: https://html.spec.whatwg.org/multipage/scripting.html#the-template-element https://html.spec.whatwg.org/multipage/scripting.html#the-te...
    - path411 12y ago
      That's really just an alias'd script tag. You are still using javascript to actually do the templating.
jerf 12y ago
The use of XMLHttpRequest to fetch JSON has come to dominate to the point that people seem to forget that it had any other use, but it is worth occasionally reminding people that the original purpose was to fetch HTML, which the browser turned into DOM nodes via its fast parsing path, which could then be added to the page via DOM manipulation. I fully realize this is not what the linked page is proposing, but it is not clear to me that using that wouldn't be a better idea, leaving the selection of templating to the user. Template languages, while smaller than programming languages, share their characteristic that there isn't obvious One Solution That Solves Everything. You can optimize them for different use cases and it is not clear to me that we can or should privilege one over the others. Given how rapidly the web is heading away from an overprivileged programming language being the only choice, this seems like going the wrong direction. (Also, if your template language is slowing your server down, fix that. That's a problem with your implementation language, not the fundamental concept.)
- TazeTSchnitzel 12y ago
  Uh, the original purpose of XMLHttpRequest was to fetch XML, as its name implies. AJAX stands for Asynchronous JavaScript And XML
  - jerf 12y ago
    I'm not able to substantiate this with links, but I believe the idea was that the "XML" in question was going to be XHTML most likely, rather than generic "XML", though it did support the generic XML use case. I could be wrong, if the original Outlook web interface this was supported for really did return XML that was not XHTML at some point. It was a crazy time. XHTML was still "inevitable", and people were pretty sloppy with the terms.
    - frik 12y ago
      Wrong. It was called "XMLHTTP", created by Microsoft for Outlook Web Access 2000. Mozilla implemented it as XMLHttpRequest JavaScript object in Gecko. The main reason of XHR/AJAX was XML, but Text and HTML are supported too. See Wikipedia for the correct history: http://en.wikipedia.org/wiki/XMLHttpRequest http://en.wikipedia.org/wiki/XMLHttpRequest Microsoft never implemented the XHTML standards in Internet Explorer. IE cannot open files with .xhtml file extension and with .htm(l) extension the page is rendered with HTML quirksmode.
miralabs 12y ago
spa apps are more complex that the example. Sure it looks it could work but the amount of logic within an SPA is not just a simple click here , fetch json , replace html fragment. The title is a bit misleading. I don't think it's possible to do SPA without Javascript.
outsidetheparty 12y ago
Lots and lots of very bad ideas here -- backwards-incompatibility with previous versions of HTML is always a good litmus test that a proposal hasn't been thought through, as is "hey let's restructure everything around this one currently-fashionable design pattern". (I kind of love how he just casually embeds a SQL interpreter in the browser, too, that's a nice finishing touch.) But the main thing is that this doesn't solve any problem that exists. We can already do everything his proposal would enable; all this does is make it more inflexible.
- antonpug 12y ago
  +1
  - ryannevius 12y ago
    There's an "upvote" button, just to the left of the comment above.
    - deleted 12y ago
      [deleted]
    - deleted 12y ago
      [deleted]
    - thomasahle 12y ago
      You shouldn't use the upvote button for agreement. On the other hand "+1" and "I agree" and "Well said!" clutter the forum. How do we solve this?
      - preek 12y ago
        Honest question: If not for showing agreement, what is the reason for the upvote button?
        egeozcan 12y ago
deitcher 12y ago
I don't like this. I would like to see a standardized html way to load html partials into other html, similar to ng-include. I think that is clean. But to start mixing logic? How are you supposed to render a JSON array loaded via ajax? How do you put in authentication information or headers? How do you do error handling? This is the stuff that is handled by angular or ember or knockout or aurelia or etc.
pothibo 12y ago
> Everyone’s into it because the responsiveness is so much better than loading a full page - 10-50ms with a clean API load vs. 300-1500ms for a full HTML page load. Maybe if you start with an argument to support your claim, you want to have actual numbers. And those real numbers would tell a different story.
ape4 12y ago
As for a name... Single-Page Apps Without JavaScript = SPAWJS. Or just SPAWS.
madoublet 12y ago
Single page apps seem like a hack to make browser apps feel like they are closer to native apps. Because most SPAs have a set flow, it seems like we should be able to use prefetching to tell the browser what is most likely to happen next. For example, if you are on a list, then you can tell the browser to prefetch the details. <link rel="next" href="details.html"> What I feel like is missing from this equation is a nice transition between pages. How nice would it be to have something like this: <a href="details.html" transition="slide-left">Details</a> If the browser prefetched the details and handled the transition, I would see no need for an SPA. We would get the benefits without having to implement a hack.
- Touche 12y ago
  So if you have a list of 100 links you are going to prefetch all 100?
  - madoublet 12y ago
    No, that is not really the use of prefetch. It is for more predictable flows.
- e12e 12y ago
  And today you can use that markup and shim the transition you want with js - and still gracefully downgrade.
  - toxican 12y ago
    But wouldn't having it in the HTML mean you don't need the js? And then it wouldn't need to downgrade in modern browsers at all.
    - e12e 12y ago
      If you want to change the HTML spec and have something happen, you'd have to upgrade the browsers before anything happens... rel-links do work today, but transitions don't automatically work, and UI/UX (using the "forward"-arrow to go to "next" etc) is inconsistent or non-existent. But you can write some js to make them all work. And your HTML can be semantic and nice, and you can still get advanced features.
Cshelton 12y ago
Instead, why don't we eliminate the need for Apps in a browser to require HTML. Right now, our large scale app has one div inside the <body>. It's just an anchor for our SPA built in React js. We should push for browsers that can launch from a .js file, rather than requiring html. Have a base UI.kit that can even keep css, or use javascript to stylize. I'd like the 'base' UI to be as skeleton and simple as possible. We can keep the <html> style markup, but with javascript first. Similar to what JSX does with React. This would also fix the DOM problem we are currently stuck with. This is a rough, quick typeup, thoughts though? EDIT: and most importantly, get multi-threaded javascrip in the browser. Running the UI, events, and logic all on separate threads. Many observe patterns would most likely be used.
- Touche 12y ago
  > Instead, why don't we eliminate the need for Apps in a browser to require HTML. Accessibility.
  - thomasfoster96 12y ago
    A canvas accessibility api would be great.
  - Cshelton 12y ago
    Touche, love the user name. Yes, right now it would seem impossible and browsers would have to support backwards compatibility. What I'm saying is let browsers still support regular html sites. In addition though, be able to specify a 'javascript app'. I see no limiting reason in modern browsers why this would be an issue. At some point, the web has to move forward and say, 'sorry, if you are not running JS, we can't really support you'. Yes, I know the backlash that would come, but we've got to move forward, maybe there is a better way? I'm not sure. (My project does not require supporting anything below IE 11, it's the greatest blessing, ever.)
  - pjmlp 12y ago
    All major native UI toolkits support accessibility as required by many governments.
cjfont 12y ago
“<A href="sql:select from *”>" An anti-pattern if I've ever seen one.
- yc1010 12y ago
  Yeh my thought when I seen that was "...what could possibly go wrong..."
thomasfoster96 12y ago
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 parts of a resource easily using HTTP. Luckily these issues have solutions: 1. Invest time in a new successor or radical improvement over the current DOM - think an asynchronous, thread safe API. Fix things that deal with HTML, don't try and make HTML anything more than a markup language. 2. Either make your web apps fallback to HTML + CSS or start convincing people that using Javascript isn't a huge privacy issue. Fallbacks can be easy if you want them to be. 3. I'm sure there are way to request specific parts of a page (indeed, I coded such a way myself in PHP a few years ago), but someone needs to build an awesome abstraction over HTTP to make this easier.
- emodendroket 12y ago
  > Either make your web apps fallback to HTML + CSS So make two Web apps with the same functionality, basically?
  - insin 12y ago
    Or make one app with an isomorphic base which gets progressively enhanced when JavaScript runs on the client.
    - emodendroket 12y ago
      Yes, but if you're doing a true "SPA" then "progressive enhancement" really does just mean having two versions of everything.
      - insin 12y ago
        Not any more - once you can prerender the "SPA" on the server and use the same codebase to rehydrate it on the client and take over - which you can do today with React and soon with Ember - then with the right setup the "progressive enhancement" bit can be "am I on the client now? let's do some extra stuff" implemented as part of the same component. e.g. here's a form that uses the same React component to render on the server, to handle regular form submissions and render redisplay when invalid and to progressively enhance with live validation and ajax form submission when JavaScript is available on the client: https://isomorphic-lab.herokuapp.com/add-thing https://isomorphic-lab.herokuapp.com/add-thing
lovamova 12y ago
Why not DOM streaming or lazy DOM? We don’t need HTML6.
doczoidberg 12y ago
I don't like this proposal. An SPA is more than just getting json from a server.
evvvvr 12y ago
Among all the other reasons why this is bad, i think that guy never had heard about different environments (production, staging etc.) API URL's in mark-up, yeah
ender7 12y ago
I don't want to be flippant here, but anyone who thinks you can build a high-quality UI with a solely declarative system hasn't built very many UIs.
antonpug 12y ago
This is why you don't let "Editor-In-Chief" do web development. Sounds to me like someone's too lazy to learn JavaScript. When will people stop trying to make HTML into an all-in-one product? It was built to be simple, to provide markup and that's it. That's the magic behind the troika of HTML-JS-CSS. They all deal with individual, meaningful functions to make a site work. Blending function with markup is just bad coding. Thumbs down.
lollipop26 12y ago
Have seen several tries on this approach: - Angular seems to provide something similar already with its ng-* attributes and directives. - JavaServer Faces also do the same thing, where a server-side controller is bound to HTML or UI widgets (and skip writing CSS and JS because they're pre-styled, pre-programmed). This works for simple stuff, but for much more complex stuff (multiple view interactions, custom views), this becomes a pain to write because you start to create workarounds for things it wasn't prepared to do. Also, while I'm no expert, but let's just leave HTML, CSS and JS as is. You can always create a framework that provides you that same functionality. In fact, Angular has directives, React has JSX, Ember has components. Several other frameworks do it as well. Reminds me of E4X, where they tried to bake in XML syntax into JS. This time, it's behavior and logic into the markup. Nope.
xsace 12y ago
Model references are defined so that it can call any object, with the ability to define conditions to access objects, perhaps looping through lists of objects via SQL select statements and using TEMPLATE tags to create new DOM objects. What - the - fuck
aikah 12y ago
What happened to web components ? isn't supposed to solve these issues ?
- Svenstaro 12y ago
  I wonder the same. Isn't that the quasi standard way of doing this?
k_sze 12y ago
Technically, I don't think it would be very useful except for apps that are simple state machines. If you want something Turing-complete, you might as well stick to JavaScript.
windar 12y ago
This must be a joke. Why force a design pattern on anyone who wants to create an SPA?
jkoudys 12y ago
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 now, can we implement this directly in the browsers via HTML so users can directly style their content without CSS? I propose adding a <font> tag, so people can style their fonts, a <blink> tag so things can blink, and a fun <marquee> tag so content can scroll.
- thomasahle 12y ago
  > 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.)
  - pg_is_a_butt 12y ago
    HTML was adopted BECAUSE it was that way. bastardizing it BECAUSE it is so wildly adopted is retarded. you really don't detect any sarcasm at all? are you a moron or an idiot? which is it?
  - virmundi 12y ago
    It should stay close to what it is because it's fairly good at its job. To make it more than that would be to generalize it away from its job into some new job. This violates single responsibility. We've already learned our lesson with that and HTML; thus was born CSS. Making a web standard for single page apps doesn't really seem necessary. Applications are by their nature different than web sites. A web site is a collection of content displayed largely as pages that are designated by a URI. An application is an abstraction over the page model that minimizes the transparent page/resource model with an opaque process flow model. HTML, as it stands, can be the V in MVC in either. Making it take on the M or C gains us little and stands to lose us much.
- askmike 12y ago
phkahler 12y ago
I always thought XSLT has some SQL-like capabilities and I have always been angry that one can't simply pass a parameter to the interpreter via link. The idea being that menus could become active just by having links specify an item selected when they are clicked on and reload the same page. It's one little tiny thing (passing the parameter) that could make dynamic static pages.
adambrod 12y ago
One of HTML's largest flaws is speed. Can't we work on making the DOM faster?
- Someone1234 12y ago
  HTML's DOM isn't slow, it is the CSS which makes it slow. When you manipulate the DOM the vast majority of the time spent regenerating it is in CSS, the raw node tree itself is fairly cheap.
deleted 12y ago
[deleted]
- vasilakisfil 12y ago
  This is fixed in Ember at least with history API
- deleted 12y ago
  [deleted]
- NathanKP 12y ago
  Unless you are using IE <10 this is a trivial problem to solve using history.pushState() http://caniuse.com/#feat=history http://caniuse.com/#feat=history
  - joshstrange 12y ago
    There are quite a large number of people who still have to support < IE10 (myself included). Hopefully in the next year or two we will drop support for IE9 and then we can use it but we aren't there yet. 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.
    - NathanKP 12y ago
      Yeah I agree the SEO issues. Anything that is dependent on search traffic should not be a single page app, as it will hurt your ranking greatly. Google actually runs JS these days, but you'll still get penalized for slow speed if you load all the content in via JS instead of just serving a flat HTML page to the bot. And that's not even considering Bing and other web bots that almost certainly do not have JS running capability. They will just see an empty page. If you are making a dashboard or web app which is not intended to be crawled by Google, and not really dependent on search traffic though then single page is a great way to go.
sumitgt 12y ago
I'm sure no one wants to go down this path. Why mess with the amazing separation of concern that exists between HTML, JavaScript and CSS.
romaniv 12y ago
Honestly, looks too complicated. I'm doing AJAX without custom JavaScript right now. The way it looks: <form action="x" replace="#y">  </form> <div id="y" /> You submit the form, it loads the result in the background and replaces content of Y div with content of whatever has id="y" on the new page. splice-result-into takes any CSS selector as its parameter, so you can apply this to multiple elements at once. The entire library is around 100 lines of code with no dependencies. 100% backwards compatible, degradable and easy to add to existing multipage apps. It could easily be implemented as a standard HTML feature.
wantab 12y ago
Too many new people creating web pages these days ignore the science behind it all.
33a 12y ago
Thankfully this looks like it is never gonna happen, and is instead just a random suggestion posted to a newsgroup (which carries very little weight/credibility). In my judgment this feature is highly redundant and unnecessarily complicated.
kowdermeister 12y ago
Too bad, this is already implemented as a standard (cough-cough Mozilla) as part of Web Components. http://www.html5rocks.com/en/tutorials/webcomponents/imports/ http://www.html5rocks.com/en/tutorials/webcomponents/imports... Reading the comments I felt many people thought this is an official recommendation. It's the mailing list folks, the same place where somebody suggested to replace JavaScript with AS3 because it would solve every problem of mankind.
- drinchev 12y ago
  That was my initial thought. Also you can basically declare any custom tags ( with dash in the name [1] ). Which with some good javascript could accomplish easily ( and I would say in more clean way ) what it's being offered by the OP. If he likes this kind of writing his AJAX implementation he can easily do so by doing his own framework. I think HTML5 is doing pretty, pretty good and it's underestimated in what it can be achieved. [1] http://www.html5rocks.com/en/tutorials/webcomponents/customelements/ http://www.html5rocks.com/en/tutorials/webcomponents/custome...
asimpletune 12y ago
I'm pretty sure this is similar to meteor js and transparent reactive programming, except just getting rid of the templates and using html instead. I don't think he realizes it that way, bc he keeps mentioning wanting to not have to use js. I would be down to have a nice standard way of providing templates , adding onto html thus keeping it backwards compatible but that's it. what he's proposing could be could be backwards compatible
simi_ 12y ago
As someone who thinks about making a HTML/CSS/JS replacement at some point in the future, I look forward to these guys completely fucking up the standard.
AngryAntlion 12y ago
Has anyone looked at the source of his site? www.futureclaw.com
- natewich 12y ago
  Goddamn, that's atrocious.
- frik 12y ago
  The worst site I saw in 2015, it's broken in IE11 and Firefox. Or are all the double and triple scrollbars intentional? And the code, the "Editor-In-Chief" seem to be stuck the 1990s, with all CAPS HTML tags and HTML 2 style code.
- marvel_boy 12y ago
  Man, serioulsy? This is the worst site I've seen in a while!
davesque 12y ago
Don't agree with this. I think improving Javascript's API for the DOM is a much better path forward.
Yuioup 12y ago
HTML is like violence. If it doesn't work, use more.
lobo_tuerto 12y ago
It seems it is the same idea behind Polymer's core-ajax, what do you think? https://www.polymer-project.org/0.5/docs/elements/core-ajax.html https://www.polymer-project.org/0.5/docs/elements/core-ajax....
picks_at_nits 12y ago
“All DSLs grow in complexity until they are Turing-Complete, then JWZ’s Law takes over.”
sebastianconcpt 12y ago
A naive attempt to do the same we do now just waaaaaaay more inflexibly. The author needs to watch this a meditate on why Alan Kay said what he said about the web architecture: http://youtu.be/oKg1hTOQXoY http://youtu.be/oKg1hTOQXoY
jkot 12y ago
Nice, now it only needs some scripting language. I am sure you could invite something in a few days.... WTF?? Please please, just start over!
namuol 12y ago
What is this moonspeak? Modern web apps do so much more than what this proposal is trying to solve. React + Relay/GraphQL is much more likely to be the next real big step forward on the horizon of web/app development.
liuyanghejerry 12y ago
It is pretty funny these years, cause app(qml, for example) really wants to be web, and web(single-page-app-like web) really wants to be app.
copsarebastards 12y ago
These single-page apps are becoming pervasive but they are also fundamentally breaking the internet. Here are some common ways in which they are broken: 1. History is screwed up. You wanted a back button that took you back to the content you were looking at? Sucks to be you. The content you were looking at was dynamically loaded after ten different buttons you clicked, and now that the page is loaded fresh those button clicks are gone. Good luck finding it again. This especially goes for any of those infinite scroll websites: those should die. 2. Tabs don't work. Hey this link looks interesting, I'll open it in a new tab to look at later. Oh wait that was actually a JavaScript link and what often ends up happening is you end up with a blank page, or the same one page app loaded with it's initial content. 3. Save page doesn't work. You can save the page and pull it up and everything works because the JavaScript fetches the content. But there's one problem: I was saving that page to view on the bus where I have spotty internet if any. Sucks to be me. 4. Accessibility is broken. Oh, you're blind? Arthritic and have trouble using a mouse? Well, sorry, we had to size things in a certain way to make the animations work and tab order was too hard to get working, so I guess you can't use my website. Sucks to be you! 5. Security is broken. If you app loads content from a server that isn't yours, you can no longer verify security. There are solutions to all of these problems but they're very difficult and 90% of one page apps don't solve these problems because they don't care. I'm not against one page apps on principal, but a one page app standard that doesn't address these concerns is only going to make them worse. Unless we can solve these issues I'm against any one page app standard.
- nilliams 12y ago
  I agree with you in principle that if apps don't meet 1, 2, 4 & 5 they shouldn't see light of day but I think your points are largely spurious or handled by any semi-competent dev. 1 & 2 are a basic feature of JS MVC frameworks. I get that some people still probably mess this up, but there's no excuse to do so at this point. 3. Irrelevant/FUD? No normal user 'saves' web-pages, unless it's something like a receipt, which any sane dev would make a separate html page and not part of the app. 4. is totally false as screen-readers support JavaScript. 5. is false/strawman as any half-sane SPA developer still authenticates using a regular back-end framework and I've no idea what 'If you app loads content from a server that isn't yours' has to do with single-page apps.
jeeyoungk 12y ago
There are some dangerous thoughts in this thread, for example: https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Mar/0079.html https://lists.w3.org/Archives/Public/public-whatwg-archive/2... "These javascript frameworks are all trying to do this, but none of them do it easily and they’re always being redesigned." Things are being redesigned because there are flaws and limitations. Making something, and stamping it as "HTML6" doesn't automatically make it perfect. It would simply hinder the development further.
nishantrana 12y ago
Yes we have to make html and css more powerfull and dynamic and this will make browser similar no need of hacks for compatibility and there is no use of extra coding because when we make an app or make a website we use most of javascript plugins some time we dont need of extra features in the plugin so we have to modify those plugins that will make some extra hours
nishantrana 12y ago
Yes we have to make the html and css more dynamic for single page application because it will take less time and single handed coded by the developers. So in this time we have to use frameworks that have some additional features that we dont use in our website or application we use some of them which is really suit to our need and there are lots of browser having compatibility issues if html and css become more dynamic and independent the compatibility issue will be solve and we dont need for extra time for using plugins and make them for our needs.
deleted 12y ago
[deleted]

187 points by matthewmacleod 12y ago

hias 12y ago

so...iframes?

CraneWorm 12y ago
... except instead of loading arbitrary url he actually proposes some structure. This could work for most websites depending on ajax to load their content. Say, instead of xml you get a language similar to django templates.

baby 12y ago

I'm very skeptical about this. HTML is a fixed language for reasons. It is not supposed to be able to parse a JSON file.

agumonkey 12y ago

Other members are worried this is just shifting complexity for no real value. A mistake they did in the past. https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Mar/0073.html https://lists.w3.org/Archives/Public/public-whatwg-archive/2... My opinion too.

RandomBK 12y ago

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.

Someone1234 12y ago
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="" <b> <i> <font> 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 <br /> style (and bans things like <br> which make no sense). I understand why they went the way they did (backwards compatibility mostly), but feel like the web would be in a better place ten years from now if a strict spec for at least HTML was commonly used.
- TazeTSchnitzel 12y ago
  Strictness accomplishes nothing whatsoever. If you remove presentational elements, people just abuse semantic elements.
  - astine 12y ago
    I would make parsers and generators much easier to write.
    - emodendroket 12y ago
      But there are millions of pages that will never be updated and if a browser can't render them people are going to blame the browser, not the use of deprecated HTML elements (an issue they won't even have awareness of).
      - Someone1234 12y ago
        That's just a generic argument for no new HTML ever.
        emodendroket 12y ago
        No it isn't; it's an argument against breaking changes.
  - Someone1234 12y ago
    > Strictness accomplishes nothing whatsoever. Sure it does, it means it is impossible to mix logic or styling into your HTML inline. That makes HTML more maintainable and teaching it easier (less is always easier to teach than more). What semantic elements are you worried about them abusing? I cannot think of a semantic element which replaces defunct presentational elements without any CSS (which would makes the entire argument redundant).
    - TazeTSchnitzel 12y ago

Dirlewanger 12y ago

Never too early to start work on something we'll see in a couple decades.

daemonk 12y ago

I think we should keep HTML simple and enforce a strict separation between template and logic. However, I do like the idea of adding a native "model" attribute to the DOM element that can automatically get/parse json and update accordingly.

smt88 12y ago
Have you ever used React? What do you think about the React/Flux methods of mixing template and logic?
- daemonk 12y ago
  Good point. I do use react and I find jsx to be very convenient. I guess the question is: would I want to write something similar to JSX and have the browser be able to interpret that natively. I honestly don't know.
  - smt88 12y ago
    Yeah, I'm ambivalent myself. The main problem with W3 standards is that they assumed they knew what we'd want to do with them. No one predicted HTML would become the UI layer for complex replacements for desktop applications, so for a long time, it sucked at that job. Now they're trying to rectify those mistakes, but I think they might be going too far in the other direction. Instead, web standards need to be as simple, low-level, and generic as possible. The more HTML approaches an opinionated UI framework, the worse off we all are (in my opinion).

arenaninja 12y ago

Great, now I need 3 years experience in it by the end of the month

Roboprog 12y ago
No kidding. I just started learning Angular, and now this. Fortunately, it sounds like it will die an unpopular death.

_wmd 12y ago

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 producing network-friendly compound representations for data, rather than the typical small collection of pure CRUD endpoints over fixed structures (/users/1, /comments/1231, etc.), since XSLT had limited ability to trigger loading external data without falling back to Javascript hacks or similar. But I imagine the tragic flaw in both the data binding proposal here and how XSLT worked is massively increased complexity for fairly little gain - and I think that's why XSLT has died a gentle death over the past decade. Still, both ideas appeal to me from the perspective of escaping horrendous chunks of procedural macros being shipped with data just to make it render on the client.

outsidetheparty 12y ago
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.)
- pjmlp 12y ago
  Yet, alongside XHTML it would allow to move HTML to a proper layout engine like most native GUIs have, instead of the hack-a-mole we have to deal with.
- jkoudys 12y ago
  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 looked terrible (still do). I fell in love with the idea that was championed back in the late 90s, where you use your application to build XML, which only describes your data. You'd then have some XSLT on your web server (or in-browser) that would transform the XML into your document. Nowadays, this isn't that different of an approach from using my server-side PHP/python/node/Go to generate JSON, then building my DOM based on client-side templates; since I use ReactJS, my transforms are even still XML. A lot of the best-practices I learned from XSLT transferred over nicely too, e.g. avoiding control logic (<xsl:if>) in favour of <xsl:apply-templates>, since good javascript client-side templates should avoid branching control logic in favour of just Array.prototype.map() wherever you can. I think the real key isn't about understanding recursion, though you will gradually gain an appreciation for it, but understanding composition. Templating is too often done in the style common among poor developers, where they think about building a whole "page", instead of defining the components of that page. XSLT, in theory, would've been great for that, it's just a pain in the butt to actually implement. tl;dr if there is a need for this proposal, it would be better met by cleaning out all the cruft from XSLT, and building implementations that don't require such arcane syntax nobody can use it.

itsbits 12y ago

Its not completely to replace Javascript but basically a standard to load HTML like iframes except its not.

tinganho 12y ago

I definitely don't like this proposal. SPA:s is under a heavily innovative period. Standardizing it will only slow downs its' development.

iso8859-1 12y ago
No one will force you to use it, browsers have always been reasonably backwards compatible, except regarding stuff like ActiveX, applets, and HSTS.

jalfresi 12y ago

Am I mistaken, but this kinda looks like XForms. Why not just use XForms? Edit: Obviously I understand that XForms isn't a viable option these days, but that is kinda my point. Why isn't XForms an option? Those reasons appear to apply to this proposal too...

pjmlp 12y ago
Because XHTML was killed, when it could have become the XAML of the web, so the circle comes back to "another day another hack".

bananaoomarang 12y ago

This is interesting, but like others I think HTML should be kept strictly for templating, and this adds an unnecessary amount of logic. It might be tempting to see this as removing complication, but in actuality it will probably add to it by reducing separation of concerns. I think it would be good for less ambitious projects, but in the end it would cripple the building of more ambitious ones. If we already have Angular/React/Components/Whatever, shouldn't we just keep working on them and leave the HTML spec unpolluted?

moron4hire 12y ago
HTML does not do templating, either.
- pfooti 12y ago
  I'm just going to leave this here: https://html.spec.whatwg.org/multipage/scripting.html#the-template-element https://html.spec.whatwg.org/multipage/scripting.html#the-te...
  - path411 12y ago
    That's really just an alias'd script tag. You are still using javascript to actually do the templating.

jerf 12y ago

The use of XMLHttpRequest to fetch JSON has come to dominate to the point that people seem to forget that it had any other use, but it is worth occasionally reminding people that the original purpose was to fetch HTML, which the browser turned into DOM nodes via its fast parsing path, which could then be added to the page via DOM manipulation. I fully realize this is not what the linked page is proposing, but it is not clear to me that using that wouldn't be a better idea, leaving the selection of templating to the user. Template languages, while smaller than programming languages, share their characteristic that there isn't obvious One Solution That Solves Everything. You can optimize them for different use cases and it is not clear to me that we can or should privilege one over the others. Given how rapidly the web is heading away from an overprivileged programming language being the only choice, this seems like going the wrong direction. (Also, if your template language is slowing your server down, fix that. That's a problem with your implementation language, not the fundamental concept.)

TazeTSchnitzel 12y ago
Uh, the original purpose of XMLHttpRequest was to fetch XML, as its name implies. AJAX stands for Asynchronous JavaScript And XML
- jerf 12y ago
  I'm not able to substantiate this with links, but I believe the idea was that the "XML" in question was going to be XHTML most likely, rather than generic "XML", though it did support the generic XML use case. I could be wrong, if the original Outlook web interface this was supported for really did return XML that was not XHTML at some point. It was a crazy time. XHTML was still "inevitable", and people were pretty sloppy with the terms.
  - frik 12y ago
    Wrong. It was called "XMLHTTP", created by Microsoft for Outlook Web Access 2000. Mozilla implemented it as XMLHttpRequest JavaScript object in Gecko. The main reason of XHR/AJAX was XML, but Text and HTML are supported too. See Wikipedia for the correct history: http://en.wikipedia.org/wiki/XMLHttpRequest http://en.wikipedia.org/wiki/XMLHttpRequest Microsoft never implemented the XHTML standards in Internet Explorer. IE cannot open files with .xhtml file extension and with .htm(l) extension the page is rendered with HTML quirksmode.

miralabs 12y ago

spa apps are more complex that the example. Sure it looks it could work but the amount of logic within an SPA is not just a simple click here , fetch json , replace html fragment. The title is a bit misleading. I don't think it's possible to do SPA without Javascript.

outsidetheparty 12y ago

Lots and lots of very bad ideas here -- backwards-incompatibility with previous versions of HTML is always a good litmus test that a proposal hasn't been thought through, as is "hey let's restructure everything around this one currently-fashionable design pattern". (I kind of love how he just casually embeds a SQL interpreter in the browser, too, that's a nice finishing touch.) But the main thing is that this doesn't solve any problem that exists. We can already do everything his proposal would enable; all this does is make it more inflexible.

antonpug 12y ago
+1
- ryannevius 12y ago
  There's an "upvote" button, just to the left of the comment above.
  - deleted 12y ago
    [deleted]
  - deleted 12y ago
    [deleted]
  - thomasahle 12y ago
    You shouldn't use the upvote button for agreement. On the other hand "+1" and "I agree" and "Well said!" clutter the forum. How do we solve this?
    - preek 12y ago
      Honest question: If not for showing agreement, what is the reason for the upvote button?
      - egeozcan 12y ago

deitcher 12y ago

I don't like this. I would like to see a standardized html way to load html partials into other html, similar to ng-include. I think that is clean. But to start mixing logic? How are you supposed to render a JSON array loaded via ajax? How do you put in authentication information or headers? How do you do error handling? This is the stuff that is handled by angular or ember or knockout or aurelia or etc.

pothibo 12y ago

> Everyone’s into it because the responsiveness is so much better than loading a full page - 10-50ms with a clean API load vs. 300-1500ms for a full HTML page load. Maybe if you start with an argument to support your claim, you want to have actual numbers. And those real numbers would tell a different story.

ape4 12y ago

As for a name... Single-Page Apps Without JavaScript = SPAWJS. Or just SPAWS.

madoublet 12y ago

Single page apps seem like a hack to make browser apps feel like they are closer to native apps. Because most SPAs have a set flow, it seems like we should be able to use prefetching to tell the browser what is most likely to happen next. For example, if you are on a list, then you can tell the browser to prefetch the details. <link rel="next" href="details.html"> What I feel like is missing from this equation is a nice transition between pages. How nice would it be to have something like this: <a href="details.html" transition="slide-left">Details</a> If the browser prefetched the details and handled the transition, I would see no need for an SPA. We would get the benefits without having to implement a hack.

Touche 12y ago
So if you have a list of 100 links you are going to prefetch all 100?
- madoublet 12y ago
  No, that is not really the use of prefetch. It is for more predictable flows.
e12e 12y ago
And today you can use that markup and shim the transition you want with js - and still gracefully downgrade.
- toxican 12y ago
  But wouldn't having it in the HTML mean you don't need the js? And then it wouldn't need to downgrade in modern browsers at all.
  - e12e 12y ago
    If you want to change the HTML spec and have something happen, you'd have to upgrade the browsers before anything happens... rel-links do work today, but transitions don't automatically work, and UI/UX (using the "forward"-arrow to go to "next" etc) is inconsistent or non-existent. But you can write some js to make them all work. And your HTML can be semantic and nice, and you can still get advanced features.

Cshelton 12y ago

Instead, why don't we eliminate the need for Apps in a browser to require HTML. Right now, our large scale app has one div inside the <body>. It's just an anchor for our SPA built in React js. We should push for browsers that can launch from a .js file, rather than requiring html. Have a base UI.kit that can even keep css, or use javascript to stylize. I'd like the 'base' UI to be as skeleton and simple as possible. We can keep the <html> style markup, but with javascript first. Similar to what JSX does with React. This would also fix the DOM problem we are currently stuck with. This is a rough, quick typeup, thoughts though? EDIT: and most importantly, get multi-threaded javascrip in the browser. Running the UI, events, and logic all on separate threads. Many observe patterns would most likely be used.

Touche 12y ago
> Instead, why don't we eliminate the need for Apps in a browser to require HTML. Accessibility.
- thomasfoster96 12y ago
  A canvas accessibility api would be great.
- Cshelton 12y ago
  Touche, love the user name. Yes, right now it would seem impossible and browsers would have to support backwards compatibility. What I'm saying is let browsers still support regular html sites. In addition though, be able to specify a 'javascript app'. I see no limiting reason in modern browsers why this would be an issue. At some point, the web has to move forward and say, 'sorry, if you are not running JS, we can't really support you'. Yes, I know the backlash that would come, but we've got to move forward, maybe there is a better way? I'm not sure. (My project does not require supporting anything below IE 11, it's the greatest blessing, ever.)
- pjmlp 12y ago
  All major native UI toolkits support accessibility as required by many governments.

cjfont 12y ago

“<A href="sql:select from *”>" An anti-pattern if I've ever seen one.

yc1010 12y ago
Yeh my thought when I seen that was "...what could possibly go wrong..."

thomasfoster96 12y ago

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 parts of a resource easily using HTTP. Luckily these issues have solutions: 1. Invest time in a new successor or radical improvement over the current DOM - think an asynchronous, thread safe API. Fix things that deal with HTML, don't try and make HTML anything more than a markup language. 2. Either make your web apps fallback to HTML + CSS or start convincing people that using Javascript isn't a huge privacy issue. Fallbacks can be easy if you want them to be. 3. I'm sure there are way to request specific parts of a page (indeed, I coded such a way myself in PHP a few years ago), but someone needs to build an awesome abstraction over HTTP to make this easier.

emodendroket 12y ago
> Either make your web apps fallback to HTML + CSS So make two Web apps with the same functionality, basically?
- insin 12y ago
  Or make one app with an isomorphic base which gets progressively enhanced when JavaScript runs on the client.
  - emodendroket 12y ago
    Yes, but if you're doing a true "SPA" then "progressive enhancement" really does just mean having two versions of everything.
    - insin 12y ago
      Not any more - once you can prerender the "SPA" on the server and use the same codebase to rehydrate it on the client and take over - which you can do today with React and soon with Ember - then with the right setup the "progressive enhancement" bit can be "am I on the client now? let's do some extra stuff" implemented as part of the same component. e.g. here's a form that uses the same React component to render on the server, to handle regular form submissions and render redisplay when invalid and to progressively enhance with live validation and ajax form submission when JavaScript is available on the client: https://isomorphic-lab.herokuapp.com/add-thing https://isomorphic-lab.herokuapp.com/add-thing

lovamova 12y ago

Why not DOM streaming or lazy DOM? We don’t need HTML6.

doczoidberg 12y ago

I don't like this proposal. An SPA is more than just getting json from a server.

evvvvr 12y ago

Among all the other reasons why this is bad, i think that guy never had heard about different environments (production, staging etc.) API URL's in mark-up, yeah

ender7 12y ago

I don't want to be flippant here, but anyone who thinks you can build a high-quality UI with a solely declarative system hasn't built very many UIs.

antonpug 12y ago

This is why you don't let "Editor-In-Chief" do web development. Sounds to me like someone's too lazy to learn JavaScript. When will people stop trying to make HTML into an all-in-one product? It was built to be simple, to provide markup and that's it. That's the magic behind the troika of HTML-JS-CSS. They all deal with individual, meaningful functions to make a site work. Blending function with markup is just bad coding. Thumbs down.

lollipop26 12y ago

Have seen several tries on this approach: - Angular seems to provide something similar already with its ng-* attributes and directives. - JavaServer Faces also do the same thing, where a server-side controller is bound to HTML or UI widgets (and skip writing CSS and JS because they're pre-styled, pre-programmed). This works for simple stuff, but for much more complex stuff (multiple view interactions, custom views), this becomes a pain to write because you start to create workarounds for things it wasn't prepared to do. Also, while I'm no expert, but let's just leave HTML, CSS and JS as is. You can always create a framework that provides you that same functionality. In fact, Angular has directives, React has JSX, Ember has components. Several other frameworks do it as well. Reminds me of E4X, where they tried to bake in XML syntax into JS. This time, it's behavior and logic into the markup. Nope.

xsace 12y ago

Model references are defined so that it can call any object, with the ability to define conditions to access objects, perhaps looping through lists of objects via SQL select statements and using TEMPLATE tags to create new DOM objects. What - the - fuck

aikah 12y ago

What happened to web components ? isn't supposed to solve these issues ?

Svenstaro 12y ago
I wonder the same. Isn't that the quasi standard way of doing this?

k_sze 12y ago

Technically, I don't think it would be very useful except for apps that are simple state machines. If you want something Turing-complete, you might as well stick to JavaScript.

windar 12y ago

This must be a joke. Why force a design pattern on anyone who wants to create an SPA?

jkoudys 12y ago

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 now, can we implement this directly in the browsers via HTML so users can directly style their content without CSS? I propose adding a <font> tag, so people can style their fonts, a <blink> tag so things can blink, and a fun <marquee> tag so content can scroll.

thomasahle 12y ago
> 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.)
- pg_is_a_butt 12y ago
  HTML was adopted BECAUSE it was that way. bastardizing it BECAUSE it is so wildly adopted is retarded. you really don't detect any sarcasm at all? are you a moron or an idiot? which is it?
- virmundi 12y ago
  It should stay close to what it is because it's fairly good at its job. To make it more than that would be to generalize it away from its job into some new job. This violates single responsibility. We've already learned our lesson with that and HTML; thus was born CSS. Making a web standard for single page apps doesn't really seem necessary. Applications are by their nature different than web sites. A web site is a collection of content displayed largely as pages that are designated by a URI. An application is an abstraction over the page model that minimizes the transparent page/resource model with an opaque process flow model. HTML, as it stands, can be the V in MVC in either. Making it take on the M or C gains us little and stands to lose us much.
askmike 12y ago

phkahler 12y ago

I always thought XSLT has some SQL-like capabilities and I have always been angry that one can't simply pass a parameter to the interpreter via link. The idea being that menus could become active just by having links specify an item selected when they are clicked on and reload the same page. It's one little tiny thing (passing the parameter) that could make dynamic static pages.

adambrod 12y ago

One of HTML's largest flaws is speed. Can't we work on making the DOM faster?

Someone1234 12y ago
HTML's DOM isn't slow, it is the CSS which makes it slow. When you manipulate the DOM the vast majority of the time spent regenerating it is in CSS, the raw node tree itself is fairly cheap.

deleted 12y ago

[deleted]

vasilakisfil 12y ago
This is fixed in Ember at least with history API
deleted 12y ago
[deleted]
NathanKP 12y ago
Unless you are using IE <10 this is a trivial problem to solve using history.pushState() http://caniuse.com/#feat=history http://caniuse.com/#feat=history
- joshstrange 12y ago
  There are quite a large number of people who still have to support < IE10 (myself included). Hopefully in the next year or two we will drop support for IE9 and then we can use it but we aren't there yet. 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.
  - NathanKP 12y ago
    Yeah I agree the SEO issues. Anything that is dependent on search traffic should not be a single page app, as it will hurt your ranking greatly. Google actually runs JS these days, but you'll still get penalized for slow speed if you load all the content in via JS instead of just serving a flat HTML page to the bot. And that's not even considering Bing and other web bots that almost certainly do not have JS running capability. They will just see an empty page. If you are making a dashboard or web app which is not intended to be crawled by Google, and not really dependent on search traffic though then single page is a great way to go.

sumitgt 12y ago

I'm sure no one wants to go down this path. Why mess with the amazing separation of concern that exists between HTML, JavaScript and CSS.

romaniv 12y ago

Honestly, looks too complicated. I'm doing AJAX without custom JavaScript right now. The way it looks: <form action="x" replace="#y">  </form> <div id="y" /> You submit the form, it loads the result in the background and replaces content of Y div with content of whatever has id="y" on the new page. splice-result-into takes any CSS selector as its parameter, so you can apply this to multiple elements at once. The entire library is around 100 lines of code with no dependencies. 100% backwards compatible, degradable and easy to add to existing multipage apps. It could easily be implemented as a standard HTML feature.

wantab 12y ago

Too many new people creating web pages these days ignore the science behind it all.

33a 12y ago

Thankfully this looks like it is never gonna happen, and is instead just a random suggestion posted to a newsgroup (which carries very little weight/credibility). In my judgment this feature is highly redundant and unnecessarily complicated.

kowdermeister 12y ago

Too bad, this is already implemented as a standard (cough-cough Mozilla) as part of Web Components. http://www.html5rocks.com/en/tutorials/webcomponents/imports/ http://www.html5rocks.com/en/tutorials/webcomponents/imports... Reading the comments I felt many people thought this is an official recommendation. It's the mailing list folks, the same place where somebody suggested to replace JavaScript with AS3 because it would solve every problem of mankind.

drinchev 12y ago
That was my initial thought. Also you can basically declare any custom tags ( with dash in the name [1] ). Which with some good javascript could accomplish easily ( and I would say in more clean way ) what it's being offered by the OP. If he likes this kind of writing his AJAX implementation he can easily do so by doing his own framework. I think HTML5 is doing pretty, pretty good and it's underestimated in what it can be achieved. [1] http://www.html5rocks.com/en/tutorials/webcomponents/customelements/ http://www.html5rocks.com/en/tutorials/webcomponents/custome...

asimpletune 12y ago

I'm pretty sure this is similar to meteor js and transparent reactive programming, except just getting rid of the templates and using html instead. I don't think he realizes it that way, bc he keeps mentioning wanting to not have to use js. I would be down to have a nice standard way of providing templates , adding onto html thus keeping it backwards compatible but that's it. what he's proposing could be could be backwards compatible

simi_ 12y ago

As someone who thinks about making a HTML/CSS/JS replacement at some point in the future, I look forward to these guys completely fucking up the standard.

AngryAntlion 12y ago

Has anyone looked at the source of his site? www.futureclaw.com

natewich 12y ago
Goddamn, that's atrocious.
frik 12y ago
The worst site I saw in 2015, it's broken in IE11 and Firefox. Or are all the double and triple scrollbars intentional? And the code, the "Editor-In-Chief" seem to be stuck the 1990s, with all CAPS HTML tags and HTML 2 style code.
marvel_boy 12y ago
Man, serioulsy? This is the worst site I've seen in a while!

davesque 12y ago

Don't agree with this. I think improving Javascript's API for the DOM is a much better path forward.

Yuioup 12y ago

HTML is like violence. If it doesn't work, use more.

lobo_tuerto 12y ago

It seems it is the same idea behind Polymer's core-ajax, what do you think? https://www.polymer-project.org/0.5/docs/elements/core-ajax.html https://www.polymer-project.org/0.5/docs/elements/core-ajax....

picks_at_nits 12y ago

“All DSLs grow in complexity until they are Turing-Complete, then JWZ’s Law takes over.”

sebastianconcpt 12y ago

A naive attempt to do the same we do now just waaaaaaay more inflexibly. The author needs to watch this a meditate on why Alan Kay said what he said about the web architecture: http://youtu.be/oKg1hTOQXoY http://youtu.be/oKg1hTOQXoY

jkot 12y ago

Nice, now it only needs some scripting language. I am sure you could invite something in a few days.... WTF?? Please please, just start over!

namuol 12y ago

What is this moonspeak? Modern web apps do so much more than what this proposal is trying to solve. React + Relay/GraphQL is much more likely to be the next real big step forward on the horizon of web/app development.

liuyanghejerry 12y ago

It is pretty funny these years, cause app(qml, for example) really wants to be web, and web(single-page-app-like web) really wants to be app.

copsarebastards 12y ago

These single-page apps are becoming pervasive but they are also fundamentally breaking the internet. Here are some common ways in which they are broken: 1. History is screwed up. You wanted a back button that took you back to the content you were looking at? Sucks to be you. The content you were looking at was dynamically loaded after ten different buttons you clicked, and now that the page is loaded fresh those button clicks are gone. Good luck finding it again. This especially goes for any of those infinite scroll websites: those should die. 2. Tabs don't work. Hey this link looks interesting, I'll open it in a new tab to look at later. Oh wait that was actually a JavaScript link and what often ends up happening is you end up with a blank page, or the same one page app loaded with it's initial content. 3. Save page doesn't work. You can save the page and pull it up and everything works because the JavaScript fetches the content. But there's one problem: I was saving that page to view on the bus where I have spotty internet if any. Sucks to be me. 4. Accessibility is broken. Oh, you're blind? Arthritic and have trouble using a mouse? Well, sorry, we had to size things in a certain way to make the animations work and tab order was too hard to get working, so I guess you can't use my website. Sucks to be you! 5. Security is broken. If you app loads content from a server that isn't yours, you can no longer verify security. There are solutions to all of these problems but they're very difficult and 90% of one page apps don't solve these problems because they don't care. I'm not against one page apps on principal, but a one page app standard that doesn't address these concerns is only going to make them worse. Unless we can solve these issues I'm against any one page app standard.

nilliams 12y ago
I agree with you in principle that if apps don't meet 1, 2, 4 & 5 they shouldn't see light of day but I think your points are largely spurious or handled by any semi-competent dev. 1 & 2 are a basic feature of JS MVC frameworks. I get that some people still probably mess this up, but there's no excuse to do so at this point. 3. Irrelevant/FUD? No normal user 'saves' web-pages, unless it's something like a receipt, which any sane dev would make a separate html page and not part of the app. 4. is totally false as screen-readers support JavaScript. 5. is false/strawman as any half-sane SPA developer still authenticates using a regular back-end framework and I've no idea what 'If you app loads content from a server that isn't yours' has to do with single-page apps.

jeeyoungk 12y ago

There are some dangerous thoughts in this thread, for example: https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Mar/0079.html https://lists.w3.org/Archives/Public/public-whatwg-archive/2... "These javascript frameworks are all trying to do this, but none of them do it easily and they’re always being redesigned." Things are being redesigned because there are flaws and limitations. Making something, and stamping it as "HTML6" doesn't automatically make it perfect. It would simply hinder the development further.

nishantrana 12y ago

Yes we have to make html and css more powerfull and dynamic and this will make browser similar no need of hacks for compatibility and there is no use of extra coding because when we make an app or make a website we use most of javascript plugins some time we dont need of extra features in the plugin so we have to modify those plugins that will make some extra hours

nishantrana 12y ago

Yes we have to make the html and css more dynamic for single page application because it will take less time and single handed coded by the developers. So in this time we have to use frameworks that have some additional features that we dont use in our website or application we use some of them which is really suit to our need and there are lots of browser having compatibility issues if html and css become more dynamic and independent the compatibility issue will be solve and we dont need for extra time for using plugins and make them for our needs.

deleted 12y ago

[deleted]