Live data from Hacker News

XSLT – Native, zero-config build system for the Web

github.com

141–150 of 337 posts

Re: XSLT – Native, zero-config build system for the Web

#141

Earlier quoted context omitted.

It's odd cause xslt was clearly made in an era where expecting long source xml to be processed was the norm, and nested loops would blow up obviously..

It was in the era when everything walk on the DOM tree, not streams. Streaming is not supported until later version.

Hmm my memory is fuzzy but I remember seeing backend processing of xml files a lot around 2005.

Re: XSLT – Native, zero-config build system for the Web

#142
post #46

i have a static website with a menu. keeping the menu synchronized over the half dozen pages is a pain. my only option to fix this are javascript, xslt or a server side html generator. (and before you ask, static site generators are no better, they just make the generation part manual instead of automatic.) i don't actually care if the site is static. i only care that maintenance is simple. build tools are not simple…

Frames. Use frames. They're the future. Definitely.

Re: XSLT – Native, zero-config build system for the Web

#143
My first intranet job early 2000s reporting was done this way. You could query a db via asp to get some xml, then transform using xslt and get a big html report you could print. I got pretty good at xslt. Nowadays I steer towards a reporting system for reports, but for other scenario you’re typically doing one of the stacks he mentioned: JSON or md + angular/vue/react/next/nuxt/etc

I’ve kinda gotten to a point and curious if others feel same: it’s all just strings. You get some strings from somewhere, write some more strings to make those strings show other strings to the browser. Sometimes the strings reference non strings for things like video/audio/image. But even those get sent over network with strings in the http header. Sometimes people have strong feelings about their favorite strings, and there are pros and cons to various strings. Some ways let you write less strings to do more. Some are faster. Some have angle brackets, some have curly brackets, some have none at all! But at the end of the day- it’s just strings.

Re: XSLT – Native, zero-config build system for the Web

#144

Earlier quoted context omitted.

It was in the era when everything walk on the DOM tree, not streams. Streaming is not supported until later version.

Hmm my memory is fuzzy but I remember seeing backend processing of xml files a lot around 2005.

But they worked on the xml body as a whole, in memory, which is where all the headaches started. Then we introduced WSDLs on top, and then we figured out streaming.

Re: XSLT – Native, zero-config build system for the Web

#145
post #114

Earlier quoted context omitted.

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…

> native JS `XMLHttpRequest` was only available from IE 7 onwards, before that it was some ActiveX thing. Almost sure it was available on IE6. But even if not, you could emulate it using hidden iframes to call pages which embedded some javascript interacting with the main page. I still have fond memories of using mootools for lightweight nice animations and less fond ones of dojo.

Internet Explorer 5–6 was the ActiveX control. Then other browsers implemented XMLHTTPRequest based on how that ActiveX control worked, then Internet Explorer 7 implemented it without ActiveX the same way as the other browsers, and then WHATWG standardised it.

Kuro5hin had a dynamic commenting system based on iframes like you describe.

Re: XSLT – Native, zero-config build system for the Web

#146

I 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,…

XSLT/XPath have evolved since XSLT 1.0.

Features are now available like key (index) to greatly speedup the processing. Good XSLT implementation like Saxon definitively helps as well on the perf aspect.

When it comes to transform XML to something else, XSLT is quite handy by structuring the logic.

Re: XSLT – Native, zero-config build system for the Web

#148
post #107
post #34

Ok, 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…

Yes, of course for web applications you can't do full page reload (you weren't either back in the days, where web applications existed in form of java applets or flash content).

Let's face it, most uses of JS frameworks are for blogs or things that with full page reload you not even notice: nowadays browsers are advanced and only redraw the screen when finished loading the content, meaning that they would out of the box mostly do what React does (only render DOM elements who are changes), meaning that a page reload with a page that only changes one button at UI level does not result in a flicker or loading of the whole page.

BTW, even React now is suggesting people to run the code server-side if it is possible (it's the default of Next.JS), since it makes the project easier to maintain, debug, test, as well as get better score in SEO from search engines.

I'm still a fan of the "old" MVC models of classical frameworks such as Laravel, Django, Rails, etc. to me make overall projects that are easier to maintain for the fact that all code runs in the backend (except maybe some jQuery animation client side), model is well separated from the view, there is no API to maintain, etc.

Re: XSLT – Native, zero-config build system for the Web

#149

My first intranet job early 2000s reporting was done this way. You could query a db via asp to get some xml, then transform using xslt and get a big html report you could print. I got pretty good at xslt. Nowadays I steer towards a reporting system for reports, but for other scenario you’re typically doing one of the stacks he mentioned: JSON or md + angular/vue/react/next/nuxt/etc I’ve kinda gotten to a point and cu…

My first personal page was made this way too. Nightmare to debug, since "view source" only gave the XML code, not the computed XHTML.

Re: XSLT – Native, zero-config build system for the Web

#150
post #84

It'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…

XML is fine. A bit wordy, but I appreciate its precision and expressiveness compared to YAML. XPath is kind of fine. It's hard to remember all the syntax but I can usually get there with a bit of experimentation. XSLT is absolutely insane nonsense and needs to die in a fire.

It depends what you use it for. I worked on a interbank messaging platform that normalised everything into a series of standard xml formats, and then used xslt for representing data to the client. Common use case - we could rerender data to what a receiver’s risk system were expecting in config (not compiled code). You could have people trained in xslt doing that, they did not need to be more experienced developers. Fixes were fast. It was good for this. Another time i worked on a production pipeline for a publisher of education books. Again, data stored in normalised xml. Xslt is well suited to mangling in that scenario.
Post reply on HN