I hate this grug brain writing style. It sounds bad and is hard to read. Please just write normal, full sentences.
Yeah I don't get it. I had to stop reading after a couple of sentences, I just can't deal with that.
XSLT – Native, zero-config build system for the Web
41–50 of 337 posts
Re: XSLT – Native, zero-config build system for the Web
#42I worked with XSLT almost from the beginning of my career and it was a blessing in disguise. Shoutout to Michael Kay.
My first internship was in intel on XSLT 2.0 processor. Michael Key is a legend indeed. IIRC, Saxon was his one-man creation. Crazy!
Re: XSLT – Native, zero-config build system for the Web
#43What 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…
I worked with a site using XSLT in the browser in 2008, but I think support goes back to the early 2000s.
I was _really_ deep into XSLT- I even wrote the XSLT 2 parser for Wikipedia in like 2009, so I'm not sure why I haven't been aware of browser native support for transformations until now. Or maybe I was and I just forgot.
Re: XSLT – Native, zero-config build system for the Web
#44XSLT is cool and was quite mind-expanding for me when it came out - I wouldn't say it's "grug brain" level technology at all. An XML language for manipulating XML - can get quite confusing and "meta". I wouldn't pick it as a tool these days.
Re: XSLT – Native, zero-config build system for the Web
#45I remember that I did the same in 2005-2006, just combine XML with XSL(T) to let the browser transform the XML into HTML.
After that, also combined XML with XSL(T) with PHP.
At that time modern way of working, separate concerns in the frontend.
Around 2008-2009 I stopped with this method, and start using e.g. smarty.
I still like the idea of using all native methods from browsers, that are described at the W3c.
No frameworks or libraries needed, keep it simple and robust.
I think there are just a few that know XSL(T) these days, or need some refresh (like me).
Re: XSLT – Native, zero-config build system for the Web
#46i 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. they tend to suffer from bitrot because they are not bundled with the hosting of the site or the site content.
server side html generators (aka content management systems, etc.) are large and tie me to a particular platform.
frontend frameworks by default require a build step and of course need javascript in the browser. some frameworks can be included without build tools, and that's better, but also overkill for large sites. and of course then you are tied to the framework.
another option is writing custom javascript code to include an html snippet from another file.
or maybe i can try to rig include with xslt. will that shut up the people who want to view my site without javascript?
at some point there was discussion for html include, but it has been dropped. why?
Re: XSLT – Native, zero-config build system for the Web
#47[deleted]
Re: XSLT – Native, zero-config build system for the Web
#48Cant take it seriously with that language, sorry
Re: XSLT – Native, zero-config build system for the Web
#49Ok, 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
Re: XSLT – Native, zero-config build system for the Web
#50Sometimes 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…
I just had to explain to some newbies that SOAP is a protocol with rigid rules; REST is an architectural style with flexibility. The latter means that you have to work and document really well and consumers of the API need tools like Postman etc. to be even able to use the API. With SOAP, you get most of that for free.