Live data from Hacker News

XMLUI

blog.jonudell.net

191–200 of 345 posts

Re: XMLUI

#191
post #64

I wrote Qt C++ for 7 years as an open source contributor to KDE. This reminds me of QtWidgets’ .ui files—custom XML files following a specific schema. Later, Qt introduced QML, which I personally found unintuitive, and over time I lost interest in Qt altogether. That said, I still think XML for UI definitions makes sense, and it’s understandable that some larger environments continue to use it.

And wxwidgets and glade files...

Re: XMLUI

#192

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.

I can't fully see the text on mobile, the beginning is cut off and zooming out doesn't help. Just so you know. :)

Re: XMLUI

#193

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.

Your idea sounds interesting but your site is unreadable on mobile (Android+Firefox).

Re: XMLUI

#194
post #90

Earlier quoted context omitted.

That is the spirit.

In the distant future: $ ./myapp.xlsx --port 8080 My App listening on port 8080 Loaded 1337 rows

The future is now with Microsoft Excel Web Services, which is part of SharePoint.

https://learn.microsoft.com/en-us/sharepoint/dev/general-dev...

Re: XMLUI

#195
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 layout engine, lots of options available, Flutter, Avalonia etc... ) and deploy with your favourite programming language through WASM.

In fact a next generation browser should bascially be this, with the legacy browser functionality implemented as a WASM module that draws to this single canvas... The browser would become small and much easiert to secure ( only input, audio and general WASI style apis missing and to secure )

Re: XMLUI

#196
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 abstraction turned out to be worse than code first solutions like JSX even for novices.

Re: XMLUI

#197

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.

Hi, cant read your site? other comments arent loading on my HN app so not sure if other people have same issue. Mobile firefox

Re: XMLUI

#198
post #195

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) and many sites were an 800x600 image using the tag for hitpoints.

Even Flutter has a DOM target because painting to a full violates at the very least the operating system's text rendering, scrolling, and accessibility.

Re: XMLUI

#199
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 explains the technical details, but this explains _why_ this exists. This is a bold statement, but I don't think he's wrong.

Now, is XMLUI the _right_ set of abstractions to help these developers? We'll have to wait an see. But I love to see the attempt!

Re: XMLUI

#200
post #195

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…

Alan Kay in 1997:

> I really would like you to contrast that with what you have to do with HTML on the Internet. Think about it. HTML on the Internet has gone back to the dark ages because it presupposes that there should be a browser that should understand its formats. This has to be one of the worst ideas since MS-DOS. [Laughter] This is really a shame. It's maybe what happens when physicists decide to play with computers, I'm not sure. [Laughter] In fact, we can see what's happend to the Internet now, is that it is gradually getting—There are two wars going on. There's a set of browser wars which are 100 percent irrelevant. They're basically an attempt, either at demonstrating a non-understanding of how to build complex systems, or an even cruder attempt simply to gather territory. I suspect Microsoft is in the latter camp here. You don't need a browser, if you followed what this Staff Sergeant in the Air Force knew how to do in 1961. You just read it in. It should travel with all the things that it needs, and you don't need anything more complex than something like X Windows. Hopefully better. But basically, you want to be able to distribute all of the knowledge of all the things that are there, and in fact, the Internet is starting to move in that direction as people discover ever more complex HTML formats, ever more intractable. This is one of these mistakes that has been recapitulated every generation. It's just simply not the way to do it.

Post reply on HN