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

251–260 of 337 posts

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

#251

Post by diggan »

colejohnson66 wrote: post #209
diggan wrote: post #138

Earlier quoted context omitted.

> It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them Generally speaking I feel like this is true for a lot of stuff in programming circles, XML included. New technology appears, some people play around with it. Others come up with using it for something else. Give it some time, and eventually people start putting it everywhere…

A controversial opinion, but JSON is that too. Not as bad as XML was (̶t̶h̶e̶r̶e̶'̶s̶ ̶n̶o̶ ̶"̶J̶S̶L̶T̶"̶)̶, but wasting cycles to manifest structured data in an unstructured textual format has massive overhead on the source and destination sides. It only took off because "JavaScript everywhere" was taking off — performance be damned. Protobufs and other binary formats already existed, but JSON was appealing because…

Yup, agree with everything you said!

I think the only left out part is about people currently believing in the current hyped way, "because this time it's right!" or whatever they claim. Kind of the way TypeScript people always appear when you say that TypeScript is currently one of those hyped things and will eventually be overshadowed by something else, just like the other languages before it, then soon sure enough, someone will share why TypeScript happen to be different.

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

#252

Post by bmacho »

kbolino wrote: post #246
bmacho wrote: post #243

Earlier quoted context omitted.

> Every frame on a page was a separate, independent, coequal instance of the browser engine. This is almost never what you actually want. Most frames are used for menu, navigation, frame for data, frame for additional information of data. And they are great for that. I don't think that frames are different instances of the browser engine(?) but that doesn't matter the slightest(?). They are fast and lightweight. > Th…

With a frameset page: History doesn't work right Bookmarks don't work right -- this applies to link sharing and incoming links too Back button doesn't work right The concept is good. The implementation is bad.

Yup, they are not enough for an SPA, not without javascript. And if you have javascript to handle history, URL, bookmarks and all that, you can just use divs without frames.

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

#253

Post by pyuser583 »

darwi wrote: post #233

The x86-cpuid-db project [1] heavily uses XSLT 3.0 through the “saxonche” PIP package. It has worked amazingly well for us, and the generated files are already merged in the Linux Kernel. [1] https://gitlab.com/x86-cpuid.org/x86-cpuid-db

Thank you! I've been looking for python support for XSLT 3.0! Not looking very hard, but this is still saved me some time!

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

#254

Post by kbolino »

bmacho wrote: post #252
kbolino wrote: post #246

Earlier quoted context omitted.

With a frameset page: History doesn't work right Bookmarks don't work right -- this applies to link sharing and incoming links too Back button doesn't work right The concept is good. The implementation is bad.

Yup, they are not enough for an SPA, not without javascript. And if you have javascript to handle history, URL, bookmarks and all that, you can just use divs without frames.

This has nothing to do with SPAs.

Take the POSIX specs linked in a sibling comment.

Or take the classic Javadocs. I am currently looking at the docs for java.util.ArrayList. Here's a link to it from my browser's URL bar: https://docs.oracle.com/javase/8/docs/api/

But you didn't go to the docs for java.util.ArrayList, you went to the starting page. Ok, fine, I'll link you directly to the ArrayList docs, for which I had to "view frame source" and grab the URL: https://docs.oracle.com/javase/8/docs/api/java/util/ArrayLis...

Ok, but now you don't see any of the other frames, do you? And I had one of those frames pointing at the java.util class. So none of these links show you what I saw.

And if I look in my history, there is no entry that corresponds to what I actually saw. There are separate entries for each frame, but none of them load the frameset page with the correct state.

These are strongly hyperlinked reference documents. Classic use of HTML. No JavaScript or even CSS needed.

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

#255

Post by imtringued »

colejohnson66 wrote: post #209
diggan wrote: post #138

Earlier quoted context omitted.

> It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them Generally speaking I feel like this is true for a lot of stuff in programming circles, XML included. New technology appears, some people play around with it. Others come up with using it for something else. Give it some time, and eventually people start putting it everywhere…

A controversial opinion, but JSON is that too. Not as bad as XML was (̶t̶h̶e̶r̶e̶'̶s̶ ̶n̶o̶ ̶"̶J̶S̶L̶T̶"̶)̶, but wasting cycles to manifest structured data in an unstructured textual format has massive overhead on the source and destination sides. It only took off because "JavaScript everywhere" was taking off — performance be damned. Protobufs and other binary formats already existed, but JSON was appealing because…

The fact that you bring up protobufs as the primary replacement for JSON speaks volumes. It's like you're worried about a problem that only exists in your own head.

>wasting cycles to manifest structured data in an unstructured textual format

JSON IS a structured textual format you dofus. What you're complaining about is that the message defines its own schema.

>has massive overhead on the source and destination sides

The people that care about the overhead use MessagePack or CBOR instead.

I personally hope that I will never have to touch anything based on protobufs in my entire life. Protobuf is a garbage format that fails at the basics. You need the schema one way or another, so why isn't there a way to negotiate the schema at runtime in protobuf? Easily half or more of the questionable design decisions in protobuffers would go away if the client retrieved the schema at runtime. The compiler based workflow in Protobuf doesn't buy you a significant amount of performance in the average JS or JVM based webserver since you're copying from a JS object or POJO to a native protobuf message anyway. It's inviting an absurd amount of pain for essentially zero to no benefits. What I'm seeing here is a motte-bailey justification for making the world a worse place. The motte being the argument that text based formats are computationally wasteful, which is easily defended. The bailey being the implicit argument that hard coding the schema the way protobuf does is the only way to implement a binary format.

Note that I'm not arguing particularly in favor of MessagePack here or even against protobuf as it exists on the wire. If anything, I'm arguing the opposite. You could have the benefits of JSON and protobuf in one. A solution so good that it makes everything else obsolete.

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

#256

Post by ChrisMarshallNY »

dragonwriter wrote: post #244
ChrisMarshallNY wrote: post #238

Earlier quoted context omitted.

> Even though there are newer XSLT standards, XSLT 1.0 is still dominant. I'm pretty sure that's because implementing XSLT 2.0 needs a proprietary library (Saxon XSLT[0]). It was certainly the case in the oughts, when I was working with XSLT (I still wake up screaming). XSLT 1.0 was pretty much worthless. I found that I needed XSLT 2.0, to get what I wanted. I think they are up to XSLT 3.0. [0] https://en.wikipedia.o…

Are you saying it is specified that you literally cannot implement it other than on top of, or by mimicing bug-for-bug, that library (the way it was impossible to implement WebQSL without a particular version of SQLite) or is Saxon XSLT just the only existing implementation of the spec?

Support required support from libxml/libxsl. That tops out at 1.0. I guess you could implement your own, as it’s an open standard, but I don’t think anyone ever bothered to.

I think the guy behind Saxon may be one of the XSLT authors.

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

#258

Post by [deleted] »

kbolino wrote: post #254
bmacho wrote: post #252

Earlier quoted context omitted.

Yup, they are not enough for an SPA, not without javascript. And if you have javascript to handle history, URL, bookmarks and all that, you can just use divs without frames.

This has nothing to do with SPAs. Take the POSIX specs linked in a sibling comment. Or take the classic Javadocs. I am currently looking at the docs for java.util.ArrayList. Here's a link to it from my browser's URL bar: https://docs.oracle.com/javase/8/docs/api/ But you didn't go to the docs for java.util.ArrayList, you went to the starting page. Ok, fine, I'll link you directly to the ArrayList docs, for which I ha…

[deleted]

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

#259

Post by colejohnson66 »

imtringued wrote: post #255
colejohnson66 wrote: post #209

Earlier quoted context omitted.

A controversial opinion, but JSON is that too. Not as bad as XML was (̶t̶h̶e̶r̶e̶'̶s̶ ̶n̶o̶ ̶"̶J̶S̶L̶T̶"̶)̶, but wasting cycles to manifest structured data in an unstructured textual format has massive overhead on the source and destination sides. It only took off because "JavaScript everywhere" was taking off — performance be damned. Protobufs and other binary formats already existed, but JSON was appealing because…

The fact that you bring up protobufs as the primary replacement for JSON speaks volumes. It's like you're worried about a problem that only exists in your own head. >wasting cycles to manifest structured data in an unstructured textual format JSON IS a structured textual format you dofus. What you're complaining about is that the message defines its own schema. >has massive overhead on the source and destination side…

I didn't say protobufs were a valid replacement - you only think I did. "Protobufs and other binary formats already existed, [..]". I was only using it as an example of a binary format that most programmers have heard of; More people know of protobufs than MessagePack and CBOR.

Please avoid snark.

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

#260

Post by bmacho »

kbolino wrote: post #254
bmacho wrote: post #252

Earlier quoted context omitted.

Yup, they are not enough for an SPA, not without javascript. And if you have javascript to handle history, URL, bookmarks and all that, you can just use divs without frames.

This has nothing to do with SPAs. Take the POSIX specs linked in a sibling comment. Or take the classic Javadocs. I am currently looking at the docs for java.util.ArrayList. Here's a link to it from my browser's URL bar: https://docs.oracle.com/javase/8/docs/api/ But you didn't go to the docs for java.util.ArrayList, you went to the starting page. Ok, fine, I'll link you directly to the ArrayList docs, for which I ha…

This is exactly what I wrote? But let me rephrase it: frames are not enough solely for an SPA, they can't keep state, you need javascript/dynamic webserver for that.

> Ok, fine, I'll link you directly to the ArrayList docs, for which I had to "view frame source" and grab the URL:

You could've just right click on the "frames" link, and copy the URL: https://docs.oracle.com/javase/8/docs/api/index.html?java/ut... . They use javascript to navigate based on the search params in the URL. It's not great, it should update the URL as you navigate, maybe you can send them a PR for that. (And to change state of the boxes on the left too.)

Also browser history handling is really messy and hard to get right, regardless of frames.

> And if I look in my history, there is no entry that corresponds to what I actually saw.

? If you write a javascript +1 button that updates a counter, there won't be a corresponding entry in your history for the actual states of your counter. I don't see how that is a fundamental problem with javascript(?).

Post reply on HN