... 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.
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.
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.
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).
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).
Strictly speaking, HTML5 did eliminate all presentational elements; formerly presentation HTML4.1 elements retained in HTML5 were redefined as semantic elements.
Many elements (even ones that were always, even before HTML5, semantic rather than presentational, e.g., <a href="...">...</a>) have common default presentation effects in most browsers, but that doesn't make them any less semantic.
I suppose you could strictly separating presentation from semantic by requiring conforming user-agents to apply no styling differences to any element other than that that provided by CSS (e.g., every element would have the same default presentation.) But its debatable whether that gets you anything useful other than purity for the sake of abstract theory.
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.
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.
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).
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.
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.)
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.
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.
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)
Count me among those reeling in disgust: XML is unpleasant to work with, XSLT just adds layers of complexity on top of that.
I wrote transforms for the few cases where I needed straight XML-to-XML conversions, but anything of complexity I retreated to a "real" language. It's obviously a personal choice, but I find working in XSL/XML like running through mud.
The success of JSON is due in part to the low signal-to-noise inherent in XML, and maybe XSL's low popularity is likely due to the necessary complexity of dealing with unnecessarily noisy data.
I sometimes daydream about a present where YAML got there first.
XSLT is conceptually sound indeed, a transformation of tree structures. But the requirements and real-world usage cases thrown at it are often terribly suited for it.
Real applications just don't fall neatly into tree transformations. I inherited a financial reporting web app using XSLT as the rendering mechanism. Requirements included things like running totals (state!), suppressing leading values when repeated between rows (also state), alternating row colors, external dependencies such as numeric formatting based on user's locale settings. A stateless tree transformation doesn't express that elegantly, so you end up with fantastically complicated and ugly XPath hacks. A running total would come from something like "sum all my parent's children with an index less than mine". Then that breaks when something comes up to introduce a need for another layer beneath that parent.
XSLT is purely functional. <xsl:if>template</xsl:if> isn't even control logic, it is functional evaluation, the same as Lisp's (if x template nil). <xsl:for-each> also isn't an imperative loop (it's map) even though it looks imperative and most enterprise programmers trained on imperative languages think it is and use it as such. So it's no surprise that XSLT in the wild ends up as a messy ball of mud.
Most templating languages have this problem, including PHP/HTML. The messy nature of real requirements isn't unique to XSLT. But XSLT manifests it most dramatically since it lacks a stateful and imperative framework to fall back on.
Just in case you're using XSL still, you could use <xsl:key/> to let you quickly do subtotals by summing the node set of items that match whatever grouping level you're on when you emit the last item in the group.
<xsl:key name="items-by-order" match="item" use="../@orderid"/>
...snip...
<!-- Union current item node with last item node of the order - if it's the same, the count will be one -->
<xsl:if test="count(. | key('items-by-order', ../@orderid)[last()]) = 1">
<xsl:value-of select="sum(key('items-by-order', ../@orderid))"/>
</xsl:if>
Running totals would be similar, except that your apply-templates for the item group would include a select that restricts the available nodes to the key() function's result, and you would sum current node with preceding nodes.
I built a whole website based on spitting out XML and using XSLT on either the server or (optionally; hidden behind a flag) in the browser to transform the XML to HTML.
It gave us 90% of our API "for free": On any page you could add an argument to the URL to spit out the XML data for the page, and others to get the items on the page as ATOM or RDF.
The developers hated the constraints it placed on them. But it was exactly because of the things the developers were prone to doing that was the reason for structuring it that way in the first place.
I used to despise XSLT. Actually, I still do. As a front-end developer I found it absolutely horrid to work with. I jumped ship on that as soon as possible.
XSLT is a good idea, everything else about it is just tragic, especially the language to the point I would support Nuremberg style Trials for this kind of events in computer history.
XSLT is a good idea with terrible implementation IMO. There's language called cduce. I'm not sure if it alive but it was interesting alternative implementation, though it was too much academical to be practical. But there could be usable language for trees transformation. Overall this idea is much better than current state of things.
Maybe it is not because that XSLT is complex, but because XML has failed to become a language for the web. JSON has come to be the preferred choice.
Which brings me to JSON and complexity: The complexity of retrieving data has been paved over multiple times using libraries. This has encouraged people to skip XML and go directly to JSON. If retrieval of XML data, or better yet JSON data, were to become simpler, I think more people would structure their webpages to use these types of resources. In the end, it would be a victory for both open Web and open applications.
And that brings me to my last point: Dynamic elements. This web ain't succeeding without variable based dynamics. These pathways for dynamic behaviors have to be baked into browsers from the start. Then let JS abuse that dynamic just like JQuery abuses attributes, styles, and content.
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.
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...
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?
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.)
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.
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.
Any idea what the MSDN tree view used in the 1998 timeframe? I know it loaded the contents on demand when you expand3d a node and I remember it doing so using an automation object with CreateObject.
MSDN used HTML4 frames for a long time (afaik until ca. 2006). The left side bar (left frame) with the tree was a Java applet and with the relauch in 2000 a DHTML page. The tree was expanded using DHTML (a marketing term that describes HTML with heavy Javascript usage). Javascript was used to change the visibility of DOM nodes (tree). That data of the TOC tree was loaded as XML (XMLHTTP).
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.
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.
I thought it meant "nice contribution to the conversation". It's easy to come to this conclusion when you think down-vote means "you're not contributing". I up-voted many comments I totally disagree and down-voted many I agree (because they were unrelated to the discussion). Am I a minority?
Well, the HN guidelines[1] do not mention any rule as what constitutes 'right' voting criteria. As a regular HN user of over 6 years it feels even surreal to be in a discussion about the basic features of this wonderful platform. It's never wrong to question the basic premises of life, though(;
I do believe we have the a similar kind of understanding for when to up-vote. What is a 'nice contribution to the conversation' other than arguments or facts that 'I do agree with' in them being a nice contribution to the conversation.
I fear we would have to have a meta-discussion on the concepts of good and bad and how they are flawed in that there are no montains without valleys^^
Upvoting based on "this comment brings up good points and arguments" rather than "this comment says things that I think are true" helps fight against the community becoming an echo chamber.
Exactly. It's not that interesting to be in a forum where people are only awarded for being in line with the popular opinion. The alternative is to award constructive contributions.
Add a separate +1/thumbs-up button next to the arrow. It doesn't really need to do anything more than show that people are in agreement (better even if it can do it without showing numbers).
I agree, I think there are real problems in modern web development, but they aren't in replacing javascript; they should be focusing on ideas like the shadow Dom that make things that weren't possible possible iMO, and leave these kinds of improvements to userspace frameworks built on their new features.
Absolutely agree. I got that about 3 seconds into reading this. For example, I'm close to releasing a SPA application platform. Yes, that is "application" twice. This proposal doesn't square at all with what this next generation application platform is all about.
I visited the author's site in the signature (futureclaw), and it's not exactly a slick experience. Front page doesn't let me use space to scroll it; 'more fashion' page looks janky and out of order, and has a wide scrollbar that requires mouse work; click through to Coach Men's Fall 2015 and we have a page that takes forever to load, a scrollbar on the left which does nothing when it's moved; and now I notice a side-scroll at the very bottom, which scrolls me through all the pages I've visited so far (the previous issue is actually the scrollbar for the 'previous page'), including a large thumbnail page I never visited; a side-scrollbar in the middle of the page to scroll through the model's pictures, but no other controls visible...
This is definitely not the site I'd have in my signature when talking about the emerging trend of single-page apps and proposing a new standard. It's such a non-standard site, and feels clunky and clumsy.
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.
> 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.
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:
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.
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.
That said, I wouldn't go down that road again. Better pre-fetching hints are good and HTML is a good place for a fallback (HTTP 2.0 provides better ways of doing it if you have control of the server), but page transitions are something better left to CSS, to my mind.
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, 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.)
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.
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
I'm Sure a lot of single page app features have a simple fallback - things like tabs, sliders, carousels and most navigation can be done with just html + css.
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
176 comments
[ 84.1 ms ] story [ 2327 ms ] threadhttps://lists.w3.org/Archives/Public/public-whatwg-archive/2...
My opinion too.
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.
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).
<em>
<strong>
<del>
Many elements (even ones that were always, even before HTML5, semantic rather than presentational, e.g., <a href="...">...</a>) have common default presentation effects in most browsers, but that doesn't make them any less semantic.
I suppose you could strictly separating presentation from semantic by requiring conforming user-agents to apply no styling differences to any element other than that that provided by CSS (e.g., every element would have the same default presentation.) But its debatable whether that gets you anything useful other than purity for the sake of abstract theory.
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).
Fortunately, it sounds like it will die an unpopular death.
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.
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.
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)
I wrote transforms for the few cases where I needed straight XML-to-XML conversions, but anything of complexity I retreated to a "real" language. It's obviously a personal choice, but I find working in XSL/XML like running through mud.
The success of JSON is due in part to the low signal-to-noise inherent in XML, and maybe XSL's low popularity is likely due to the necessary complexity of dealing with unnecessarily noisy data. I sometimes daydream about a present where YAML got there first.
Real applications just don't fall neatly into tree transformations. I inherited a financial reporting web app using XSLT as the rendering mechanism. Requirements included things like running totals (state!), suppressing leading values when repeated between rows (also state), alternating row colors, external dependencies such as numeric formatting based on user's locale settings. A stateless tree transformation doesn't express that elegantly, so you end up with fantastically complicated and ugly XPath hacks. A running total would come from something like "sum all my parent's children with an index less than mine". Then that breaks when something comes up to introduce a need for another layer beneath that parent.
XSLT is purely functional. <xsl:if>template</xsl:if> isn't even control logic, it is functional evaluation, the same as Lisp's (if x template nil). <xsl:for-each> also isn't an imperative loop (it's map) even though it looks imperative and most enterprise programmers trained on imperative languages think it is and use it as such. So it's no surprise that XSLT in the wild ends up as a messy ball of mud.
Most templating languages have this problem, including PHP/HTML. The messy nature of real requirements isn't unique to XSLT. But XSLT manifests it most dramatically since it lacks a stateful and imperative framework to fall back on.
It gave us 90% of our API "for free": On any page you could add an argument to the URL to spit out the XML data for the page, and others to get the items on the page as ATOM or RDF.
The developers hated the constraints it placed on them. But it was exactly because of the things the developers were prone to doing that was the reason for structuring it that way in the first place.
But if you like it, that's cool.
Maybe it is not because that XSLT is complex, but because XML has failed to become a language for the web. JSON has come to be the preferred choice.
Which brings me to JSON and complexity: The complexity of retrieving data has been paved over multiple times using libraries. This has encouraged people to skip XML and go directly to JSON. If retrieval of XML data, or better yet JSON data, were to become simpler, I think more people would structure their webpages to use these types of resources. In the end, it would be a victory for both open Web and open applications.
And that brings me to my last point: Dynamic elements. This web ain't succeeding without variable based dynamics. These pathways for dynamic behaviors have to be baked into browsers from the start. Then let JS abuse that dynamic just like JQuery abuses attributes, styles, and content.
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.
Edit: In fact, lose the XML completely and go with JSON and JSONPath.
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...
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?
https://html.spec.whatwg.org/multipage/scripting.html#the-te...
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.)
AJAX stands for Asynchronous JavaScript And XML
It was a crazy time. XHTML was still "inevitable", and people were pretty sloppy with the terms.
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
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.
Article that explains the MSDN server backend (1999): https://web.archive.org/web/19990505061257/http://msdn.micro...
Before that relaunch in 2000, the MSDN library used (MS) Java for the left side bar (TOC tree): https://web.archive.org/web/19990423231040/http://msdn.micro...
The DHTML version of MSN library (2000): https://web.archive.org/web/20000510200809/http://msdn.micro... , the 2001 version works: https://web.archive.org/web/20011108064645/http://msdn.micro...
XML toc tree data: https://web.archive.org/web/*/http://msdn.microsoft.com/libr... (sadly not archived)
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.
On the other hand "+1" and "I agree" and "Well said!" clutter the forum.
How do we solve this?
I do believe we have the a similar kind of understanding for when to up-vote. What is a 'nice contribution to the conversation' other than arguments or facts that 'I do agree with' in them being a nice contribution to the conversation.
I fear we would have to have a meta-discussion on the concepts of good and bad and how they are flawed in that there are no montains without valleys^^
1. https://news.ycombinator.com/newsguidelines.html
The community is in many ways already an echo-chamber; that battle was lost a few years ago. Don't let it bug you.
In either case, both are accepted uses. PG has said as much:
https://news.ycombinator.com/item?id=117171
However to me it feels a bit like discouraging alternative opinions, when they are hidden/greyed out.
Is this commonly accepted then?
It makes sense, then, that the upvote button be used for agreement.
This is definitely not the site I'd have in my signature when talking about the emerging trend of single-page apps and proposing a new standard. It's such a non-standard site, and feels clunky and clumsy.
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.
<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.
That said, I wouldn't go down that road again. Better pre-fetching hints are good and HTML is a good place for a fallback (HTTP 2.0 provides better ways of doing it if you have control of the server), but page transitions are something better left to CSS, to my mind.
[1]: https://msdn.microsoft.com/en-us/library/ms532847%28v=vs.85%...
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.
Accessibility.
(My project does not require supporting anything below IE 11, it's the greatest blessing, ever.)
An anti-pattern if I've ever seen one.
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.
So make two Web apps with the same functionality, basically?
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