Just my two cents - the worst pieces of tech I ever worked with in my 40+ year career were Hibernate (second) and XSLT templating for an email templating system around 2005. Would not touch it with a stick if I can avoid it.
XSLT – Native, zero-config build system for the Web
101–110 of 337 posts
Re: XSLT – Native, zero-config build system for the Web
#102What is this "XSLT works natively in the browser" sourcery? The last time I used XSLT was like 20 years ago- but I used it A LOT, FOR YEARS. In those days you needed a massive wobbly tower of enterprise Java to make it work which sort of detracted from the elegance of XSLT itself. But if XSLT actually works in the browser- has the holy grail of host-anywhere static templating actually been sitting under our noses thi…
> massive wobbly tower of enterprise Java to make it work
It wasn't that bad. We used tomcat and some apache libraries for this. Worked fine.
Our CMS was spitting out XML files with embedded HTML that were very cachable. We handled personalization and rendering to HTML (and js) server side with a caching proxy. The XSL transformation ran after the cache and was fast enough to keep up with a lot of traffic. Basically the point of the XML here was to put all the ready HTML in blobs and all the stuff that needed personalization as XML tags. So the final transform was pretty fast. The XSL transformer was heavily optimized and the trick was to stream its output straight to the response output stream and not do in memory buffering of the full content. That's still a good trick BTW. that most frameworks do wrong out of the box because in memory buffering is easier for the user. It can make a big difference for large responses.
These days, you can run whatever you want in a browser via wasm of course. But back then javascript was a mess and designers delivered photoshop files, at best. Which you then had to cut up into frames and tables and what not. I remember Google Maps and Gmail had just come out and we were doing a pretty javascript heavy UI for our CMS and having to support both Netscape and Internet Explorer, which both had very different ideas about how to do stuff.
Re: XSLT – Native, zero-config build system for the Web
#103Earlier quoted context omitted.
That timeline doesn't sound right to me. JS was rarely used to standardise behaviour - we had lots of user agent detection and relying on quirks ordering to force the right layout. JS really was for the interactivity at the beginning - DHTML and later AJAX. I don't think it even had easy access to layout related things? (I may be mistaken though) CSS didn't really make things more consistent either - once it became c…
For me, JQuery was the thing that fixed the browser inconsistencies. If you used JQuery for everything, your code worked in all the browsers. This was maybe 2008?
Before jQuery there was Prototype.js, part of early AJAX support in RoR, which fixed inconsistencies in how browsers could fetch data, especially in the era between IE 5 and 7 (native JS `XMLHttpRequest` was only available from IE 7 onwards, before that it was some ActiveX thing. The other browsers supported it from the get go). My memory is vague, but it also added stuff like selectors, and on top of that was script.aculo.us which added animations and other such fanciness.
jQuery took over very quickly though for all of those.
Re: XSLT – Native, zero-config build system for the Web
#104Ok, so it might be a long shot, but I would say that 1. the browsers were inconsistent in 1990-2000 so we started using JS to make them behave the same 2. meanwhile the only thing we needed were good CSS styles which were not yet present and consistent behaviour 3. over the years the browsers started behaving the same (mainly because Highlander rules - there can be only one, but Firefox is also coping well) 4. but we…
That timeline doesn't sound right to me. JS was rarely used to standardise behaviour - we had lots of user agent detection and relying on quirks ordering to force the right layout. JS really was for the interactivity at the beginning - DHTML and later AJAX. I don't think it even had easy access to layout related things? (I may be mistaken though) CSS didn't really make things more consistent either - once it became c…
Old guy here. Agreed- the actual story of web development and JavaScript’s use was much different.
HTML was the original standard, not JS. HTML was evolving early on, but the web was much more standard than it was today.
Early-mid 1990s web was awesome. HTML served HTTP, and pages used header tags, text, hr, then some backgound color variation and images. CGI in a cgi-bin dir was used for server-side functionality, often written in Perl or C: https://en.m.wikipedia.org/wiki/Common_Gateway_Interface
Back then, if you learned a little HTML, you could serve up audio, animated gifs, and links to files, or Apache could just list files in directories to browse like a fileserver without any search. People might get a friend to let them have access to their server and put content up in it or university, etc. You might be on a server where they had a cgi-bin script or two to email people or save/retrieve from a database, etc. There was also a mailto in addition to href for the a (anchor) tag for hyperlinks so you could just put you email address there.
Then a ton of new things were appearing. PhP on server-side. JavaScript came out but wasn’t used much except for a couple of party tricks. ColdFusion on server-side. Around the same time was VBScript which was nice but just for IE/Windows, but it was big. Perl then PhP were also big on server-side. If you installed Java you could use Applets which were neat little applications on the page. Java Web Server came out serverside and there were JSPs. Java Tomcat came out on server-side. ActionScript came out to basically replace VBScript but do it on serverside with ASPs. VBScript support went away.
During this whole time, JavaScript had just evolved into more party tricks and thing like form validation. It was fun, but it was PhP, ASP, JSP/Struts/etc. serverside in early 2000s, with Rails coming out and ColdFusion going away mostly. Facebook was PhP mid-2000s, and LAMP stack, etc. People breaking up images using tables, CSS coming out with slow adoption. It wasn’t until mid to later 2000s until JavaScript started being used for UI much, and Google’s fostering of it and development of v8 where it was taken more seriously because it was slow before then. And when it finally got big, there was an awful several years where it was framework after framework super-JavaScript ADHD which drove a lot of developers to leave web development, because of the move from server-side to client-side, along with NoSQL DBs, seemingly stupid things were happening like client-side credential storage, ignoring ACID for data, etc.
So- all that to say, it wasn’t until 2007-2011 before JS took off.
Re: XSLT – Native, zero-config build system for the Web
#105It's sad how the bloat of '00s enterprise XML made the tech seem outdated and drove everyone to 'cleaner' JSON, because things like XSLT and XPath were very mature and solved a lot of the problems we still struggle with in other formats. I'm probably guilty of some of the bad practice: I have fond memories of (ab)using XSLT includes back in the day with PHP stream wrappers to have stuff like ` ` This may be out-of-da…
It's been 84 years but I still miss some of the "basics" of XML in JSON - a proper standards organization, for one. But things like schemas were (or, felt like) so much better defined in XML land, and it took nearly a decade for JSON land to catch up.
Last thing I really did with XML was a technology called EXI, a transfer method that converted an XML document into a compressed binary data stream. Because translating a data structure to ASCII, compressing it, sending it over HTTP etc and doing the same thing in reverse is a bit silly. At this point protobuf and co are more popular, but imagine if XML stayed around. It's all compatible standards working with each other (in my idealized mind), whereas there's a hard barrier between e.g. protobuf/grpc and JSON APIs. Possibly for the better?
Re: XSLT – Native, zero-config build system for the Web
#106Still maintaining an e-commerce site using XML/xslt and Java/servlet... Passed easily each wave of tech and survived 2 databases migrations (mainframe/db2 => sqlserver => ERP)
Re: XSLT – Native, zero-config build system for the Web
#107Ok, so it might be a long shot, but I would say that 1. the browsers were inconsistent in 1990-2000 so we started using JS to make them behave the same 2. meanwhile the only thing we needed were good CSS styles which were not yet present and consistent behaviour 3. over the years the browsers started behaving the same (mainly because Highlander rules - there can be only one, but Firefox is also coping well) 4. but we…
AJAX and updating DOM wasn't there just to "make things faster" it was implemented there to change paradigm of "web sites" or "web documents" — because web was for displaying documents. Full page reload makes sense if you are working in a document paradigm.
It works well here on HN for example as it is quite simple.
There are a lot of other examples where people most likely should do a simple website instead of using JS framework.
But "we could all go back to full page reloads" is not true, as there really are proper "web applications" out there for which full page reloads would be a terrible UX.
To summarize there are:
"websites", "web documents", "web forms" that mostly could get away with full page reloads
"web applications" that need complex stuff presented and manipulated while full page reload would not be a good solution
Re: XSLT – Native, zero-config build system for the Web
#108I have worked for a company that (probably still is) heavily invested in XSLT for XML templating. It's not good, and they would probably migrate from it if they could. 1. Even though there are newer XSLT standards, XSLT 1.0 is still dominant. It is quite limited and weird compared to the newer standards. 2. Resolving performance problems of XSLT templates is hell. XSLT is a Turing-complete functional-style language,…
Are you using the commercial version of Saxon? It's not expensive, and IMHO worth it for the features it supports (including the newer standards) and the performance. If I remember correctly (it was a long time ago) it does some clever optimizations.
Re: XSLT – Native, zero-config build system for the Web
#109Earlier quoted context omitted.
For me, JQuery was the thing that fixed the browser inconsistencies. If you used JQuery for everything, your code worked in all the browsers. This was maybe 2008?
Wasn't it more about inconsistencies in JS though? For stuff which didn't need JS at all, there also shouldn't be much need for JQuery.
jQuery, along with a number of similar attempts and more single-item-focused polyfills¹ was as much about DOM inconsistencies as JS ones. It was also about making dealing with the DOM more convenient² even where it was already consistent between commonly used browsers.
DOM manipulation of that sort is JS dependent, of course, but I think considering language features and the environment, like the DOM, to be separate-but-related concerns is valid. There were less kitchen-sink-y libraries that only concentrated on language features or specific DOM features. Some may even consider a few parts in a third section: the standard library, though that feature set might be rather small (not much more than the XMLHTTPRequest replacement/wrappers?) to consider its own thing.
> For stuff which didn't need JS at all, there also shouldn't be much need for JQuery.
That much is mostly true, as it by default didn't do anything to change non-scripted pages. Some polyfills for static HTML (for features that were inconsistent, or missing entirely in, usually, old-IE) were implemented as jQuery plugins though.
--------
[1] Though I don't think they were called that back then, the term coming later IIRC.
[2] Method chaining³, better built-in searching and filtering functions⁴, and so forth.
[3] This divides opinions a bit though was generally popular, some other libraries did the same, others tried different approaches.
[4] Which we ended up coding repeatedly in slightly different ways when needed otherwise.
Re: XSLT – Native, zero-config build system for the Web
#110Long time ago somebody wanted to put a searchable directory of products on a CD. It was maybe 100MB. There was no sqlite back then and the best browser you could count on your client having was probably IE 5.5
JS was waay too slow, but it turned out that even back then XSLT was blazing fast. So I basically generated XML with all the data, wrote a simple XSLT with one clever XPath that generated search input form, did the search and displayed the results, slapped the xml file in CD auto-run and called it a day. It was finding results in a second or less. One of my best hacks ever.
Since then I always wanted to make a html templating system that compiles to XSLT and does the HTML generation on client side. I wrote some, but back then Firefox didn't support displaying XML+XSLT directly and the workaround I came up with I didn't like. Then the AJAX came and then JS got faster and client side rendering with JS became viable. But I still think it's a good idea, to send just dynamic XMLs with static XSLTs preloaded and cached, if we ever want to come back to purely server driven request-response flow. Especially if binary format for XML catches on.