Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XMLUI

blog.jonudell.net

Post reply on HN
Print view View original

331–340 of 345 posts

Re: XMLUI

#331

Post by int_19h »

gmueckl wrote: post #147
david927 wrote: post #139

Earlier quoted context omitted.

I agree and that was a huge failure. One of the big reasons VB died, people will tell you, was the language. And that's true. But what they don't mention is that the other reason was the components. I'm not sure this is replicating a success story but rather failing to learn from what was not a success story.

I am not sure whether calling WPF a huge failure is justified. It works extremely well when everything is adaptable to its MVC-adjcent MVVM design pattern. In this case it's almost child's play to build rich and conplex GUIs that keep in sync with internal state. Microsoft dropped the ball when they rewrote WPF in incompatible forms for the web (Silverlight) and Windows Phone (WinUI) shortly after releasing WPF itsel…

The irony is that WPF itself never went away, and receives support and even occasional minor new features even to this day on .NET Core.

Much like WinForms, there are still many internal line-of-business apps written in it decades ago that are just happily chugging along, ignoring all the post-Silverlight churn in Microsoft dev story.

Re: XMLUI

#332

Post by Quarrelsome »

int_19h wrote: post #328
Quarrelsome wrote: post #322

Earlier quoted context omitted.

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.

.NET didn't transition to XSLT 2.0 for the simple reason that demand wasn't really there. The way they saw it, LINQ was a better all-around option, with XLINQ specifically being an adequate replacement for XPath, and VB even got a bunch of special syntax to work with XML that made it more concise than XSLT in many cases: https://learn.microsoft.com/en-us/dotnet/visual-basic/progra... That said, it is emphatically not…

Thank you for the correction <3.

Re: XMLUI

#333

Post by cAtte_ »

dotneteer wrote: post #263
cluckindan wrote: post #107

If this doesn’t use a compiler, the ”when” feature looks like it will require 'unsafe-eval' and potentially 'unsafe-inline' to be enabled in content security policy, which will disable browser XSS protections. Not optimal for an easy-to-use component system intended for display of remote data. Edit: I don’t see a CSP on the dogfooded homepage so I would assume this is an issue.

XMLUI does not execute JavaScript with "eval" or anything that would not comply with CSP. It runs interpreted JavaScript asynchronously in a sandbox and does not allow use of "eval" (and another dozen low-level functions, such as setTimeout).

that is insane.

Re: XMLUI

#334

Post by greatgib »

cjbgkagh wrote: post #130
greatgib wrote: post #66

Earlier quoted context omitted.

I stand corrected: The Microsoft era (2007-2014) In Jan 2007 I joined Microsoft as an evangelist. Exactly at the time that Microsoft pushed for the XAML crap... So indeed not reinvented the wheel, just not having giving it up despite the complete failure of it.

I like XAML, the whole point of it is tooling support which was undermined when the tools were so buggy for so long. Now that many of the bugs have been fixed and computers are much faster it’s become a really productive UI paradigm for me. I’ll eventually switch over to Avalonia for better performance and cross platform support.

You do Windows GUI development?

Re: XMLUI

#335

Post by gnramires »

creesch wrote: post #262
gnramires wrote: post #261

I confess I have failed multiple times to build simple web pages (like a blog and homepage, admittedly after not too much effort), while I've made multiple fairly complex javascript animations using canvas and p5.js library. And I've made a few websites as a kid! (I'm not sure using free WYSIWYG or HTML directly). So appreciate a lot new developments in the really-easy-to-use open source and text tools that also enab…

To be frank, this would likely not help you. A simple web page is effectively simpler XML as the HTML elements that are already there are quite enough. I might be completely off the mark here (edit while writing the comment, considering you mention static HTML I probably am, going to leave the comment anyway for others to see), but considering you seem to think that you need React (or any javascript for that matter)…

Yea, I am indeed quite deficient in HTML knowledge and webpages in general. I'll look into PHP, thanks. Overall I have standards (that might be unachievable?) that I think tools should aim to be extremely simple if at all possible (at least there should be niche tools that achieve this, I mean), and what I've seen from web development doesn't quite meet those goals :P

I really like OpenSCAD for instance, which despite being a little difficult to do complex stuff with, is quite easy to learn (and you can indeed do complex things with a little methodology). Like, everything about the web seems a little obtuse to me. One day I'll learn a little more to hopefully make more educated comments :)

Re: XMLUI

#336

Post by aa-jv »

conradfr wrote: post #300
aa-jv wrote: post #290

Earlier quoted context omitted.

JUCE 8's WebView is an abomination that tarnishes an otherwise amazing framework. Yes, coming from the web, JUCE' Flexbox and paint()/resize() semantics are going to be 'weird' - but thats the point. You have the power to decide when/how to update your GUI, frame by frame - and for high performance GUI's, this is vital. These days it has to be said: you can get a LOT of your JUCE GUI work done for you by an LLM with…

Maybe but I actually got a ton of hallucination about the JUCE API with LLMs, as in they sometimes would just not produce workable code at all and invent functions repeatedly (endless infamous "you're right!"). My project is not a typical audio plugin so it's also why I was not benefiting as much about the graphic API as others may do. But I'm not sure how the WebView is an abomination, it's actually a quite small AP…

The WebView is not great for realtime UI's and encourages all the mistakes of the Web, in a realtime environment.

Sure, its optional, I suppose that is a benefit.

Re: XMLUI

#337

Post by [deleted] »

RebeccaTheDev wrote: post #323
nedt wrote: post #280

Earlier quoted context omitted.

Also Mozilla did their app in real XML UI with XUL. But even they themself stopped using it after 20 years.

At my last job, when I first started there (this was circa around 2006), we actually used a Firefox browser plugin with a custom XUL interface to enable our writers to write content faster. It has a very complex UI, as complex as anything that could be found in the browser itself. Thousands of lines of XML and JS. XUL was deeply unpleasant to use and maintain, and I do not miss it at all. We eventually ended up rewri…

[deleted]

Re: XMLUI

#339

Post by toyg »

int_19h wrote: post #329
toyg wrote: post #137

Earlier quoted context omitted.

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…

I don't think it was ever "purged" - I mean, which modern browser doesn't handle XSLT 1.0? Nor did the spec itself stop evolving. The problem is that the browsers have deprecated the technology before XSLT 2+ could be adopted.

> which modern browser doesn't handle XSLT 1.0?

I know it depends of the definition of "modern browser", but I'm fairly sure that MSIE and pre-chrome Edge had lost support for it at some point, since MSXML stopped being shipped with them.

I honestly don't know what the current state of the art is, but Firefox doesn't do native XSLT anymore afaik (yes, you can do it in JS, but it's an extra step).

Re: XMLUI

#340

Post by cjbgkagh »

greatgib wrote: post #334
cjbgkagh wrote: post #130

Earlier quoted context omitted.

I like XAML, the whole point of it is tooling support which was undermined when the tools were so buggy for so long. Now that many of the bugs have been fixed and computers are much faster it’s become a really productive UI paradigm for me. I’ll eventually switch over to Avalonia for better performance and cross platform support.

You do Windows GUI development?

Yes, among many other things. Applied Researcher so full stack and constant greenfield.

I also worked at DevDiv MS during the Foundation series era so I know why many of the issues with WPF are there, basically political infighting and penny pinching. It didn’t help that Gates quit and Balmer took over. Patterns and Practices didn’t properly understand WPF so they gave bad official advice on how to solve problems, it didn’t help that this was near peak Object Oriented mania and language features like generics were still new so there was a lot of unnecessary boilerplate. Code generation did help with this. WPF has a very high skill threshold for making custom controls that are not just compositions of existing controls, open sourcing WPF has helped a lot with this.

WPF is a flawed implementation of a really good idea, and if you can work around the flaws like I do then it’s actually really great. I totally understand why other people don’t like it.

I know it’ll sounds like I’m a snobbish hipster but the vast majority of people never get to the skill level required to properly use these tools. And while React starts out easier it doesn’t stay that way.

Post reply on HN