|
|
|
|
|
|
by hoechst
1210 days ago
|
|
|
So you'd write (presumably a big) admin web interface in straight XML + CSS by hand? I don't know the details, but that sounds like a very long and painful process which will end up being hellish to maintain, plus a huge amount of training time for new devs to get familiar with the system. If you even find new devs who'd want to work on this. Who wants to acquire very niche domain knowledge that you can't apply anywhere else? |
|
|
That's not what I said. I think, that what you mean when you say "by hand" is the opposite of generating XML (and in case of XML, it's not CSS, the stylesheets are XSL that transform XML into HTML).
Before JavaScript frameworks were a thing, technologies like ColdFusion, JSP, ASP Classic proliferated. You can even find remains of this approach in relatively modern frameworks like Django. The idea was to generate XML or directly HTML on the server and send it to the client ready to be displayed rather than sending JavaScript that will request more data as it interacts with the user to build the interface. The former would be called "thin client", while the later is the "thick client". The former used to be more popular because programmers didn't see JavaScript or HTML as a worthwhile to learn language, not enough to build programs in it. It was seen as a target for transpilers.
This was before single page applications, or AJAX... The perceived downside of this approach was that for sites with many very similar pages the application server would have to generate a ton of HTMLs, which would be hard to cache server-side, so, allegedly, it would work slowly (compared to AJAX, where a basic HTML page with JavaScript framework would sit in cache and communicate using XML or JSON with the server to build missing parts).
XML + stylesheets is one of the ways to address this problem: essentially it does the same thing, but without JavaScript in the middle. The function of the XML part of the equation is to transfer the data that needs to be displayed, and the stylesheet transforms the XML into HTML that the browser knows how to display. Stylesheet can be generic and reused between different XMLs. It's not as flexible as using JavaScript but a lot easier on resources, and will probably beat AJAX solution in terms of speed.
Another benefit of XML + stylesheets is good integration with the browser testing tools. With tools like Selenium, you will always struggle to catch page state changes, and will not be able to respond to change as it happens, instead needing to poll for expected condition (that might never materialize). Stylesheets take this aspect completely away because there's nothing in them that happens asynchronously or in chunks. Unlike in single page application, where "page loaded" is undefined, there's an obvious way to tell when "page loaded happens".
The problem of XML + XSL(T) is that people have some preconceived notions about it. Very few people know the tool well, and for no particular reason, most people who know anything about the tool know very little about it, but are also very angry about it. Lots of polls for the "worst programming language" would mention XSL(T)... While the truth is that it's just very different from C, and that's what irks programmers. From engineering perspective, sites like, eg. this one, or Reddit or GMail would land themselves well to XML + XSL(T), but the reality is that modern day Web programmers, well, a lot of them, don't even know they have such a tool.