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

51–60 of 337 posts

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

#51

Post by p0w3n3d »

em-bee wrote: post #49
p0w3n3d wrote: 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…

at the current technology we could cope with server generated old-school web pages because they would have low footprint, work faster and require less memory. unless you have a high latency internet connection: https://news.ycombinator.com/item?id=44326816

however when you have a high latency connection, the "thick client" json-filled webapp will only have its advantages if the most of the business logic happens on the browser. I.e. Google Docs - great and much better than it used to be in 2000s design style. Application that searches the apartments to rent? Not really I would say.

-- edit --

by the way in 2005 I programmed using very funny PHP framework PRADO that was sending every change in the UI to the server. Boy it was slow and server heavy. This was the direction we should have never gone...

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

#52

Post by pjmlp »

I love XSLT, that is what I ported my site to after the CGI phase.

Unfortunately it is not a sentiment that is shared by many, and many developers always had issues understanding the FP approach of its design, looking beyond the XML.

25 years later we have JSON and YAML formats reinventing the wheel, mostly badly, for that we already had nicely available on the XML ecosystem.

Schemas, validation, graphical transformation tools, structured editors, comments, plugins, namespaces,...

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

#53

Post by antonvs »

Hendrikto wrote: post #23

I hate this grug brain writing style. It sounds bad and is hard to read. Please just write normal, full sentences.

Presumably part of the goal is to implicitly claim that what's being described is so simple a caveman could understand it. But writing such a post about XSLT is like satire. Next up, grug brain article about the Coq proof assistant?

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

#56

Post by viraptor »

p0w3n3d wrote: 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…

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 capable it was still a mess. Sure, CSS garden was great and everyone was so impressed with semantic markup while coding tables everywhere. It took ages for anything to actually pass first two ACIDs. I'm not sure frameworks ever really impacted the "consistent looks" side of things - by the time we grew out of jQuery, CSS was the looks thing.

Then again, it was a long time. Maybe it's me misremembering.

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

#57

Post by mike_hearn »

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 functional languages composed together, so you have to learn XPath too, which is only a bit more friendly than regular expressions. The language is dominated by hacks working around the fact that it uses XML as its syntax. And there are (were?) no useful debuggers or other tooling. IIRC you didn't even have any equivalent of printf debugging. If you screwed up in some way you just got the wrong output.

Compared to that React is much better. The syntax is much cleaner and more appropriate, you can mix imperative and FP, you have proper debugging and profiling tools, and it supports incremental re-transform so it's actually useful for an interactive UI whereas XSL:T never was so you needed JS anyway.

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

#58

Post by em-bee »

p0w3n3d wrote: post #51
em-bee wrote: post #49

Earlier quoted context omitted.

at the current technology we could cope with server generated old-school web pages because they would have low footprint, work faster and require less memory. unless you have a high latency internet connection: https://news.ycombinator.com/item?id=44326816

however when you have a high latency connection, the "thick client" json-filled webapp will only have its advantages if the most of the business logic happens on the browser. I.e. Google Docs - great and much better than it used to be in 2000s design style. Application that searches the apartments to rent? Not really I would say. -- edit -- by the way in 2005 I programmed using very funny PHP framework PRADO that was…

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 the occasional updates that the app became usable.

low latency affects any interaction with a site. even hackernews is a pain to read over low latency and would improve if new comments where loaded in the background. the problem creeps up on you faster than you think.

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

#59

Post by windowsworkstoo »

pjmlp wrote: post #52

I love XSLT, that is what I ported my site to after the CGI phase. Unfortunately it is not a sentiment that is shared by many, and many developers always had issues understanding the FP approach of its design, looking beyond the XML. 25 years later we have JSON and YAML formats reinventing the wheel, mostly badly, for that we already had nicely available on the XML ecosystem. Schemas, validation, graphical transforma…

Agree, when MS moved their office file formats to xml, I made plenty of money building extremely customizable templating engines all based on a very small amount of XSLT - it worked great given all the structure and metadata available in xml
Post reply on HN