321–330 of 345 posts
Earlier quoted context omitted.
What is that gets reinvented in Postgres sorry I can’t get it? Can u please care to explain?
Not in PG but in its ecosystem. Just look at any "awesome PostgreSQL" listings, like: https://github.com/pg-tr/awesome-postgres https://github.com/dhamaniasad/awesome-postgres
Earlier quoted context omitted.
why the fuck would you want to use it with json. XSLT was held back by licensing, its why everything supports 1.0 and barely anything supports 2.0. If 2.0 was released for free then everything would use 2.0.
Why wouldn’t you just Google instead of repeatedly insisting on things that are wrong? https://www.npmjs.com/package/saxon-js https://github.com/Saxonica/Saxon-HE
for reference: I'm not talking about today, I'm talking about that point in time where (for example) .NET could have adopted XSLT 2.0 but chose not to.
This was tried with Polymer way back in 2014 too, ex. making network requests with - https://github.com/PolymerElements/iron-ajax There was also Adobe Flex of the similar era that exists these days as Apache Royale: https://apache.github.io/royale-docs/features/mxml There was also XAML and inside Microsoft they made NetUI and FlexUI to make Office 2007+ too. It all seems great on paper, but in practice the markup abs…
Also Mozilla did their app in real XML UI with XUL. But even they themself stopped using it after 20 years.
XUL was deeply unpleasant to use and maintain, and I do not miss it at all. We eventually ended up rewriting it as a standard webapp. It made the writers a bit slower, but they adapted eventually.
I'm trying to build something very much like this, except that it's based on standard HTML, web components, and signals - it's called Heximal: https://heximal.dev/ I think HTML with expressions, templates, reactivity, and components is a really great substrate for these very modular, declarative apps and pages. And a lot of the things added on top of HTML could conceivably be standardized.
In my opinion, the best GUI approach is still JUCE. Every UI element is a C++ class with a drawing function. You create new UI elements by composing other elements to create another C++ class, for which the editor will auto-generate the source code. For buttons, you have a large if...else... area in the drawing function to handle different states like hover, pressed, active, disabled, etc. Behind the scenes, a thin d…
React itself was class based in the beginning, and that would have probably been a better model in the long run - it was a lot more code for sure, but less complexity .
By comparison, I feel class component's promoted 'mile high' components where everything was inside of the class, which has many enormous drawbacks, one of the biggest being maintainability.
To this today though, I feel most people don't understand the simple rule of UI is the last mile concern. Developers still cram way too much into components rather than separating layers of concerns
No mention of XSLT? Feels like it would be highly relevant since many folks have not considered transforming or styling XML since those days, and would be interested in understanding the huge leap from that to this. And given Jon Udell has written about XSLT before[0], I'm sure this was an intentional decision. Not sure I understand it though. 0: https://www.xml.com/pub/a/2003/08/13/udell.html
My first exposure to XSLT was sketchers.com: https://thedailywtf.com/articles/Sketchy-Skecherscom Sadly it doesn't seem like they're using it anymore.
This was tried with Polymer way back in 2014 too, ex. making network requests with - https://github.com/PolymerElements/iron-ajax There was also Adobe Flex of the similar era that exists these days as Apache Royale: https://apache.github.io/royale-docs/features/mxml There was also XAML and inside Microsoft they made NetUI and FlexUI to make Office 2007+ too. It all seems great on paper, but in practice the markup abs…
Earlier quoted context omitted.
Why wouldn’t you just Google instead of repeatedly insisting on things that are wrong? https://www.npmjs.com/package/saxon-js https://github.com/Saxonica/Saxon-HE
well then tell me why .NET's XSLT platform is rooted in 1.0 instead of just saying "no". From my understanding licensing was a factor that played into the reasons why .NET natively remains on 1.0. The transition to 2.0 appeared to have specific friction: why? for reference: I'm not talking about today, I'm talking about that point in time where (for example) .NET could have adopted XSLT 2.0 but chose not to.
That said, it is emphatically not true that XSLT 2+ was somehow license-restricted. I worked at a company that used XSLT 2.0 and XQuery for code generation back in 2006, and we used the free edition with Saxon with no issues - paid versions had some optimizations and features like static type checking which we simply didn't need.
For the most part, XSLT 1.0 was "good enough" for most cases when XML was still the primary interchange format, and later JSON took over so there was less incentive for framework providers to spend resources on keeping up-to-date with the standard. Especially since XSLT 2.0 was such a massive leap in many ways, including a different data model that made many existing XSLT 1.0 processors incompatible in ways that required a massive redesign.
Earlier quoted context omitted.
Oh yeah for sure, there should be somewhere on their site that does some kind of comparison to XSLT. Because as you pointed out, anyone who knows their history is going to wonder about it. I’ve personally never written an application using XSLT, but I’ve researched it a bit. In my limited understanding, I believe XSLT was designed for transformations that happen on initial page load, or in a SSR context. For dynamic…
You're basically correct, but this isn't due to a philosophical choice. Simply speaking, XSLT stopped evolving before Ajax really got popular, and it was eventually purged from most browsers altogether on security grounds. So nobody really tried to build XSLT engines that could address modern use-cases. Somewhat ironically, the semantic web was initially supposed to be built on browsers making calls for XML data (the…
Nor did the spec itself stop evolving. The problem is that the browsers have deprecated the technology before XSLT 2+ could be adopted.
Those who do not understand (or remember) XUL are forced to reinvent it. see https://www-archive.mozilla.org/xpfe/xui.html
And you know what? It worked great. WPF with XAML - from 2006 originally! - is still, to this day, by far the easiest way to write a desktop Windows app with adaptive layout etc.