Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

191–200 of 337 posts

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

#191

Post by mlok »

I believe some people might find Zjs Components interesting for this matter :

https://news.ycombinator.com/item?id=44290315

Paper abstract :

ZjsComponent: A Pragmatic Approach to Modular, Reusable UI Fragments for Web Development

    In this paper, I present ZjsComponent, a lightweight and framework-agnostic web component designed for creating modular, reusable UI elements with minimal developer overhead. ZjsComponent is an example implementation of an approach to creating components and object instances that can be used purely from HTML. Unlike traditional approaches to components, the approach implemented by ZjsComponent does not require build-steps, transpiling, pre-compilation, any specific ecosystem or any other dependency. All that is required is that the browser can load and execute Javascript as needed by Web Components. ZjsComponent allows dynamic loading and isolation of HTML+JS fragments, offering developers a simple way to build reusable interfaces with ease. This approach is dependency-free, provides significant DOM and code isolation, and supports simple lifecycle hooks as well as traditional methods expected of an instance of a class.

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

#192

Post by PantaloonFlames »

bambax wrote: post #169
badmintonbaseba wrote: post #81

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 1.0 is still dominant How, where? In 2013 I was still working a lot with XSLT and 1.0 was completely dead everywhere one looked. Saxon was free for XSLT 2 and was excellent. I used to do transformation of both huge documents, and large number of small documents, with zero performance problems.

I recently had the occasion to work with a client that was heavily invested in XML processing for a set of integrations. They’re migrating / modernizing but they’re so heavily invested in XSL that they don’t want to migrate away from it. So I conducted some perf tests and, the performance I found for xslt in .NET (“core”) was slightly to significantly better than the performance of Java (current) and Saxon. But they were both fast.

In the early days the xsl was all interpreted. And was slow. From ~2004 or so, all the xslt engines came to be jit compiled. XSL benchmarks used to be a thing, but rapidly declined in value from then onward because the perf differences just stopped mattering.

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

#193

Post by bravesoul2 »

mike_hearn wrote: post #57
murukesh_s wrote: post #9

Sometimes I wish we could have kept XML alive alongside JSON.. I miss the comments, CDATA etc, especially when you have to serialize complex state. I know there are alternatives to JSON like YAML but I felt XML was better than YAML. We adopted JSON for its simplicity but tried to retrofit schema and other things that made XML complex. Like we kind of reinvented JSON Schema, and ended up like what XSD did decades ago…

The XSL:T equivalent for JSON is React. Let's not romanticize XML. I wrote a whole app that used XSL:T about 25 years ago (it was a military contract and for some reason that required the use of an XML database, don't ask me). Yes it had some advantages over JSON but XSL:T was a total pain to work with at scale. It's a functional language, so you have to get into that mindset first. Then it's actually multiple functi…

The XSL:T equivalent for JSON is jq

https://github.com/jqlang/jq

Learn it. It is insanely useful for mungling json in day to day work.

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

#194

Post by chriswarbo »

_heimdall wrote: post #140
em-bee wrote: post #58

Earlier quoted context omitted.

Application that searches the apartments to rent? Not really I would say. not a good example. i can't find it now, but there was a story/comment about a realtor app that people used to sell houses. often when they were out with a potential buyer they had bad internet access and loading new data and pictures for houses was a pain. it wasn't until they switched to using a frontend framework to preload everything with t…

Prefetching pages doesn't require a frontend framework though. All it takes is a simple script to preload all or specific anchor links on the page, or you could get fancier with a service worker and a site manifest if you want to preload pages that may not be linked on the current page.

It shouldn't need any scripts https://en.wikipedia.org/wiki/Link_prefetching

It can also be imposed by the client, e.g. via a https://en.wikipedia.org/wiki/Web_accelerator

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

#196

Post by codelikeawolf »

I know XML and XSLT gets a lot of hate. To some extent, the hate for XSLT is warranted. But I have to work with XML files for my job, and it was pretty refreshing to not have to install any libraries to work with them in a web app. We use XML as the serialization format for a spaceflight mission planning app, so there's a lot of complex data that would be trickier to represent with JSON. At the end of the day, HTML is spicy XML, so you can use all the native web APIs to read/write/query/manipulate XML files and even apply XSLT transformations.

I suspect some of the hate towards XML from the web dev community boils down to it being "old". I'll admit that used to have the same opinion until I actually started working with it. It's a little bit more of a PITA than working with JSON, but I think I'm getting a much more expressive and powerful serialization format for the cost of the added complexity.

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

#198

Post by _heimdall »

chriswarbo wrote: post #194
_heimdall wrote: post #140

Earlier quoted context omitted.

Prefetching pages doesn't require a frontend framework though. All it takes is a simple script to preload all or specific anchor links on the page, or you could get fancier with a service worker and a site manifest if you want to preload pages that may not be linked on the current page.

It shouldn't need any scripts https://en.wikipedia.org/wiki/Link_prefetching It can also be imposed by the client, e.g. via a https://en.wikipedia.org/wiki/Web_accelerator

Yep, that works as well. I'll reach for a script still if I want more logic around when to prefetch, like only prefetching on link hover or focus. A script is also needed for any links that you need to preload but aren't included on the current page.

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

#199

Post by thechao »

nithril wrote: post #146
badmintonbaseba wrote: post #81

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.

Can you name a non-Saxon XSLT processor? I'd really like one. Preferably, open-source.

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

#200

Post by a4isms »

A long time ago, in a dystopic project far, far, away:

Depressed and quite pessimistic about the team’s ability to orchestrate Java development in parallel with the rapid changes to the workbook, he came up with the solution: a series of XSLT files that would automatically build Java classes to handle the Struts actions defined by the XML that was built by Visual Basic from the workbook that was written in Excel.

https://raganwald.com/2008/02/21/mouse-trap.html

HN Discussions:

https://news.ycombinator.com/item?id=120379 · https://news.ycombinator.com/item?id=947952

Post reply on HN