231–240 of 345 posts
XAML (at least the tighter-scoped Silverlight incarnation of it) was an absolute joy to use - if you used it correctly. It was an absolute monster if you used it in the most obvious (and incorrect) way. That's probably the reason other than HTML5 that it fell off: good tools steer novices into the pit of success, and XAML really didn't do that at all.
Earlier quoted context omitted.
To gain access to the better toolset you need v2 and v2 costs. Maybe the org doesn't have it, maybe getting a PO for it is annoying, maybe there's friction around getting it installed on a customer site. Perhaps its just a factor which resulted in everyone else sticking on 1.0. But it never took off in the way promised because of it. That it is a fiercely declarative language makes it hard to integrate. Often develop…
You are misinformed about license cost, as I’ve already explained in multiple comments. Hard to integrate in what way? XSLT is a language focused on several things that it’s very good at but it’s not intended to replace Python or be a general purpose language. Yet there are many common data related tasks where a messy and hard to maintain pile of imperative code can be replaced with a simple XSLT.
Not everyone gets to pick and choose how they use XSLT. Place I used to work, the services team used to have a sign:
> [X] Days since last custom report
They hated it and I can't blame them, making a series of soap calls, consuming the most degenerate api ever written and generating a document for the customer was a pain. Bear in mind this was an enterprisey "do everything system", oversold by sales and the services team had to use XSLT to bridge the gap between customer expectation and what the salesman sold them.
What they needed was a host for a general purpose language, what they got was XSLT.
Earlier quoted context omitted.
You are misinformed about license cost, as I’ve already explained in multiple comments. Hard to integrate in what way? XSLT is a language focused on several things that it’s very good at but it’s not intended to replace Python or be a general purpose language. Yet there are many common data related tasks where a messy and hard to maintain pile of imperative code can be replaced with a simple XSLT.
You might want to check the username of the person you arr responding to.
Earlier quoted context omitted.
Most orgs don't transition to 2.0 which is a big part of why XSLT sucks. > but it's not unlike how you have to change your thinking for functional programming generally I'd write lisp any day of the week over XSLT. I don't think XSLT deserves a place alongside other functional languages because its bound so tightly to xml. Sure, one can argue it has its place when processing XML but I'd pick a general purpose languag…
You keep making assertions and generalizations without backing them up with anything concrete while simultaneously moving goalposts. In the cases where you do, you’re just wrong: XSLT is not held back by licensing, it doesn’t “require one liners”, and it has supported JSON since 3.0, which has been around for almost a decade.
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.
Those who do not understand (or remember) XUL are forced to reinvent it. see https://www-archive.mozilla.org/xpfe/xui.html
If XMLUI is a reinvention of XUL, then XUL* is just a reinvention of the many XML-based UI markup languages before it. * Fun fact: XUL was conceived at Netscape. Mozilla adopted it for XPFE.
If you believe XUL was developed for anything other than Mozilla's XPFE, you have been mislead.
Also, would you please provide names for those many pre-XUL XML-based UI languages I'm genuinely curious. Other than the web itself, HTML+JS+CSS, I'm at a loss for what those many XML-based UI markup languages you're referring to could possibly be. As a Mozilla participant at Netscape, and someone with hours of discussion with Hyatt over those early years, and a (very small) contributor to XPFE as early as Dave's XUL menus first draft, I'd be real interested to learn about prior art. Did we somehow miss all of those per-existing examples?
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.
The browser platform with HTML/CSS is fundamently legacy over legacy and broken for most application styles ( not general pages ), and incurs insane development costs for even simple things ( been there done that for close to 17 years ) The current best option IMO is: Open Full Browser window size canvas (with webgl, webgpu backend graphics ) and draw everyhing yourself ( meaning with something else than the browser…
My recollection of XUL was that it was great when it worked, but horrific to debug. It wasn’t also easy to make a living fixing bad VB apps (or going back to Delphi). I’m not saying that components are a bad idea, but the 90s implementations didn’t quite realize the dream.
Earlier quoted context omitted.
I don’t think this is a reinvention of XHTML. It’s definitely closer in spirit to XUL, but seems different enough still that I wouldn’t call it reinvention. What seems particularly novel about this is that it’s taken the compositional approach of modern UI component libraries, and distilled it down to units of composition that can express a lot of behavior and logic declaratively . At least at a glance, that’s an imp…
I'm curious, not talking down: would you be interested in sharing your age and/or years of experience coding, and if you're feeling very generous, the languages youve written code in for more than 2+ years? I'm 37, 17 years full-time-ish, VB6, ObjC, Java, Dart. I'm asking, I guess, because I feel like I've seen these concepts before in pre-iOS ObjC, and Java, and IIRC a good chunk of the late 90s and early 00s was ob…
Perhaps more pertinent to the topic, in my last job I implemented the bulk of an XForms implementation. Pertinent because XForms has a lot of conceptual overlap with what I’ve seen in XMLUI so far.
I think it’s worth clarifying my point above with that context: it isn’t the concept that I find novel, at all. It’s the sheer depth and breadth of declarative expressiveness that I see in the examples. Maybe the best way I can put it is that what seems novel to me is how much novelty it appears to enable, before breaking through the abstraction to give it more capabilities.
The browser platform with HTML/CSS is fundamently legacy over legacy and broken for most application styles ( not general pages ), and incurs insane development costs for even simple things ( been there done that for close to 17 years ) The current best option IMO is: Open Full Browser window size canvas (with webgl, webgpu backend graphics ) and draw everyhing yourself ( meaning with something else than the browser…
> Full Browser window size cancas ... and draw everything yourself This was already tried to some extent with Flash. Many sites were a single Flash module (or multiple). Implementing accessibility then required maintaining an invisible DOM representation of the Flash canvas. I personally don't want to return to the era where login and register buttons were dedicated Flash modules (MegaUpload did this back in ~2009) a…