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

211–220 of 345 posts

Re: XMLUI

#211

Post by thrownaway561 »

agnokapathetic wrote: post #31

reminds me of Macromedia MXML (used in Flash, Coldfusion and Flex)! https://github.com/apache/royale-asjs/blob/develop/examples/...

I was thinking the same thing. Programmed ColdFusion for over a decade and loved the language, however I moved onto .NET, the PHP and now Rails. ColdFusion was a wonderful language, but the frameworks weren't there and the market share wasn't there either. Ironically enough, one of my clients still uses it for their application and we actually began talks about moving them over to Rails.

Re: XMLUI

#212

Post by btown »

btown wrote: post #176
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.

Just ship https://github.com/NeilFraser/JS-Interpreter and you’re good to go! /s

As a follow-up: Angular actually did this! https://docs.angularjs.org/guide/expression

> AngularJS does not use JavaScript's eval() to evaluate expressions. Instead AngularJS's $parse service processes these expressions.

Re: XMLUI

#213

Post by nine_k »

1oooqooq wrote: post #209
wiremine wrote: post #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 e…

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

Windows is a narrower platform than evergreen JS-enabled browsers, and the relevance of Windows as a platform is only going to go down. So the choice of the platform is right.

What are some GUI-enabled devices you wish you were able to address, but which cannot run Firefox, Safari, or a Chromium derivative?

Re: XMLUI

#214

Post by yoz-y »

criddell wrote: post #16
yoz-y wrote: post #8

As a programmer I found that all no-or-less-code approaches break up sooner than one would expect. Eventually I chosen to always use the programming language itself for data fetching, looping and leave the templating (lit html in my case) to just passing in the data structures.

I've also seen examples that are pushed way further than I thought possible. I'm thinking about some of the things people do in Excel.

If we somehow manage to solve the two main spreadsheet downsides (imo): testing and change/version control, then spreadsheets would be a terrific programming paradigm.

As it is now I find it very powerful and empowering, but also scary.

Re: XMLUI

#216

Post by willseth »

Quarrelsome wrote: post #177
willseth wrote: post #128

Earlier quoted context omitted.

Not sure what you mean by licensing failure or “one liner”. Browsers are natively limited to XSLT 1.0 not because of licensing, but because they simply didn’t want to implement the newer versions. However Saxon offers free XSLT 3.0 processors for JS, C, Java, and .NET, so there’s not really a limitation to doing modern XSLT development.

Licensing is just another aspect of friction, contributing to everyone sticking on 1.0 and making it annoying for anyone trying to move forward with XSLT. One liner is a lack of procedural logic in its implementation. Its fine for 1-1 mapping but as it gets used in more complicated scenarios it can be hard to developers to architect a solution because there's no space to breathe.

What specific licensing problems are your referring to that supposedly hold back XSLT? It’s an open spec, anyone can implement it, and there a free processors under MPL license.

And what specifically do you mean when you say everything has to be processed as a one liner? I’ve never used an XSLT processor where that was true.

Re: XMLUI

#217

Post by willseth »

Quarrelsome wrote: post #178
lolive wrote: post #122

Earlier quoted context omitted.

Reinventing XML traversal/transformation in JavaScript will lead really fast into abstracting away the recursive tree traversal, then mapping node marchers to functions. Which is 99% what XSLT provides off the shelf.

many developers just want to have some space to do some extra logic and XSLT doesn't really accommodate for that. You have to deal with the input and create the output without pausing for breath. While this is fine in simple use-cases where the mapping is 1-1 but when the mapping gets more complicated then it becomes difficult to maintain.

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.

Re: XMLUI

#218

Post by Quarrelsome »

willseth wrote: post #216
Quarrelsome wrote: post #177

Earlier quoted context omitted.

Licensing is just another aspect of friction, contributing to everyone sticking on 1.0 and making it annoying for anyone trying to move forward with XSLT. One liner is a lack of procedural logic in its implementation. Its fine for 1-1 mapping but as it gets used in more complicated scenarios it can be hard to developers to architect a solution because there's no space to breathe.

What specific licensing problems are your referring to that supposedly hold back XSLT? It’s an open spec, anyone can implement it, and there a free processors under MPL license. And what specifically do you mean when you say everything has to be processed as a one liner? I’ve never used an XSLT processor where that was true.

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 developers are placed within an architecture that gives them limited options and only being able to use XSLT while trying to integrate other network calls or services is non-trivial and a complete headfuck sometimes, compared with more general purpose languages like python or javascript.

Re: XMLUI

#219

Post by Quarrelsome »

willseth wrote: post #217
Quarrelsome wrote: post #178

Earlier quoted context omitted.

many developers just want to have some space to do some extra logic and XSLT doesn't really accommodate for that. You have to deal with the input and create the output without pausing for breath. While this is fine in simple use-cases where the mapping is 1-1 but when the mapping gets more complicated then it becomes difficult to maintain.

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 language and process XML with that over XSLT every time.

Re: XMLUI

#220

Post by willseth »

Quarrelsome wrote: post #218
willseth wrote: post #216

Earlier quoted context omitted.

What specific licensing problems are your referring to that supposedly hold back XSLT? It’s an open spec, anyone can implement it, and there a free processors under MPL license. And what specifically do you mean when you say everything has to be processed as a one liner? I’ve never used an XSLT processor where that was true.

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.

Post reply on HN