Live data from Hacker News

XMLUI

blog.jonudell.net

221–230 of 345 posts

Re: XMLUI

#221

Earlier quoted context omitted.

That’s simply not true. Certainly it can be hard to wrap your head around architecting complex logic in XSLT 1.0, but it's not unlike how you have to change your thinking for functional programming generally. More ergonomic imperative logic and several other features in XSLT 2.0 made it a much more developer friendly language.

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.

Re: XMLUI

#222

XUL! why not just use htmx and the platform?

Because using htmx is asking to get defaced via XSS, or worse. Security is an afterthought for the project, which is evident from the placement of the related documentation.

How is this better?

Re: XMLUI

#223

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…

Can anyone with experience share more about JUICE and accessibility?

Re: XMLUI

#224

Jon has been around for a long time, and I've been a long-time fan. He's a bit of an elder: he's seen a lot of things, and he's worth listening to. > I’m a fan of web components but it’s the React flavor that dominate and they are not accessible to the kind of developer who could productively use Visual Basic components back in the day. I think this is the most important statement in the piece. The rest of the post e…

code currently only works on JS evergreen browsers. i guess like VB only worked with windows and if shipped with the right DLLs.

So, exactly like VB? (From memory it required a msvbvm DLL).

Re: XMLUI

#225

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…

And coldfusion shudder

Re: XMLUI

#226

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…

I have switched to JUCE as a total cross-platform GUI/high-performance general application development environment, having used it for 7 years in the audio realm I have attained that state, whatever it is, where I realize I can just use it for everything and it’ll be perfectly fine. Doesn’t take too much CMake wrangling either, and once you’ve got at least one half-decent, clonable JUCE -> CI pipeline working, the ho…

Is it still not possible to use JUCE for free/open-source without the pesky "Made with JUCE" popup? Or did they remove that?

Re: XMLUI

#227

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.

You might want to check the username of the person you arr responding to.

Re: XMLUI

#228
I've downloaded and printed the whole manual for action script 3 when I was an artist (I've always dabbled in programming), apparently you could create pretty robust web apps with XML. Never had the time to create one myself and as3 was dead soon after that, I think jQuery killed it.

Re: XMLUI

#229
post #228

I've downloaded and printed the whole manual for action script 3 when I was an artist (I've always dabbled in programming), apparently you could create pretty robust web apps with XML. Never had the time to create one myself and as3 was dead soon after that, I think jQuery killed it.

It seems a little strange to accuse jquery. I think what actually "killed it" was modern HTML. Jquery was just an intermediate API that let you target modern browsers and IE without having duplicate/shim code to maintain yourself.

Re: XMLUI

#230
post #228

I've downloaded and printed the whole manual for action script 3 when I was an artist (I've always dabbled in programming), apparently you could create pretty robust web apps with XML. Never had the time to create one myself and as3 was dead soon after that, I think jQuery killed it.

It seems a little strange to accuse jquery. I think what actually "killed it" was modern HTML. Jquery was just an intermediate API that let you target modern browsers and IE without having duplicate/shim code to maintain yourself.

That's why I said "think"
Post reply on HN