3 ms·
I think deep down people writing SPAs really just Flash apps or Applets would come back. They want to ignore everything about the web except the ability to deli
by giantrobot 7y ago
I think deep down people writing SPAs really just Flash apps or Applets would come back. They want to ignore everything about the web except the ability to deliver content over a network. I'd go so far as to say they hate the web as a concept.
Most problems stem from that disdain for the web. Many of those problems are then exacerbated by "opinionated" frameworks being en vogue. None of them are helped by the shit platform that is JavaScript.
I've seen the justification for SPAs front end JavaScript frameworks being a desire to separate data and presentation. A back end API serves data that's displayed by the app. We had that fifteen years ago with XSL!
There were these things called "browsers" and they could parse and display HTML and even XML. They supported stylesheets that could arbitrarily style those documents for display. They could even decide to use different styling depending on the display device! If they sound amazing they were.
I mentioned XML parsing. An XML document could be used to represent all kinds of arbitrary data. While a browser might consume XML, a native application or service could also consume it. But arbitrary XML in a browser wasn't super useful since a browser didn't have rules to display every different XML document that could be made.
The people that developed XML also came up with a way to transform data in XML to different formats. Browsers, being able to handle XML already, added support for this transforming. An XML document could include a link to this stylesheet and the browser could transform it into something (XHTML) that it did have rules for displaying, including CSS to further style elements and JavaScript to make everything terrible.
A native app or service consuming an XML doc could and often would ignore the stylesheet so to them it was just data. Even JavaScript asynchronously loading XML data would ignore stylesheets. Usually it was only browsers that cared about linked stylesheets.
But this let a single API serve browsers and native apps and even JavaScript. Presentation and data were separate concerns. Browsers would also cache all the display resources for a document so when a new document was viewed all of those resources would be cached locally.
But then for whatever dumb set of reasons web developers ignored these "browsers" and and their cool abilities. They insisted on ingesting XML to their JavaScript and then manipulating the DOM of an HTML page causing hundreds or thousands of repaints. Then they knew better still and replaced XML with JSON. By making the data serialization format require JavaScript they could obviate the browser even more. Now browsers are relegated JavaScript runtimes and even web servers are just load balancing proxies for JavaScript runtimes running on servers.
- int_19h 7y agoWe also had XSL-FO, allowing for very precise control over the rendering of that server-served XML. Oh, and this all was more than 20 years ago, not 15. IE5 had XSLT support, and it shipped in 1999!
- giantrobot 7y agoYou're right, I was thinking of FireFox 4.x having full XSLT support which was 2004/5 IIRC.
- tannhaeuser 7y agoNo reason to be bitter about XML having failed on the web; some important vocabularies, like SVG and MathML, have been incorporated into HTML, and some other parts of the XHTML effort, like XForms, really didn't work out. The web wasn't created on XML but on HTML which is an SGML not XML vocabulary, so there's no point in appealing to a glorious past that never existed (and yes, I actually developed <?xslt-stylesheet ...>-based sites in the early/mid 2000's). If you like XML, maybe you like SGML, XML's big sister, as well. Since XML is per definition just a subset of SGML, everything that applies to XML equally applies to SGML as well. Only that SGML has additional concepts and much more power as an actual text authoring, document composition, and templating format, and, unlike XML, SGML can parse regular HTML, including HTML5.
- giantrobot 7y agoI didn't like the promise of XML on the web because I fetishize markup languages. I felt it is/was a good solution for the separation of data and presentation on the web. A website could simultaneously be a site for a browser and an API for native or web apps by serving the exact same documents to everyone. The server side could focus on data and the client would be responsible for the display or processing. It did the things modern JavaScript monstrosities do but natively in the browser. XForms even proposed to handle a lot of the stupid validation and state management that requires megabytes of JavaScript to handle today. Tons of resources are wasted every second parsing and running JavaScript to do the same thing browsers can do natively.