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

The time is right for a DOM templating API

justinfagnani.com

Post reply on HN
Print view View original

141–150 of 256 posts

Re: The time is right for a DOM templating API

#141

Post by echelon »

wahern wrote: post #39
taeric wrote: post #34

Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost certainly more of a visual thing than it is a symbolic one. Is why dreamweaver and such was so successful back in the day. And why so many designers learn with tools like photoshop. Also hard not to feel like this is reaching hard to try and recreate xslt. :( It is…

> Also hard not to feel like this is reaching hard to try and recreate xslt. I was never a fan of XML, but XSLT was (is!) a killer redeeming feature of the ecosystem. And it's still widely supported in browsers! It was such a shame that XML caught on where it sucked--configuration, IPC, etc--but languished where it shined, as a markup language with an amazing transformation capability in XSLT. I think where XSLT fell…

XSLT was cool.

XML needs another syntax that isn't so verbose. Sort of like how OWL has XML, Manchester, Functional, and Turtle syntaxes for the same data structures.

XSLT needs a Turtle-style syntax.

XML in general (the data structure, not the syntax) needs a Turtle-style syntax.

Re: The time is right for a DOM templating API

#142

Post by unlog »

troupo wrote: post #97
mock-possum wrote: post #71

Earlier quoted context omitted.

Lit my beloved God I love lithtml’s tagged template literals so much more than react’s JSX or Vue’s 3-in-one thing. It’s just html, in strings, in JavaScript. Lit is just a way to make custom elements easier. Man it’s gonna suck when I have to move on from my current gig and get my hands dirty with react again.

> It’s just html, in strings, in JavaScript. It's not. It's a custom HTML- like syntax with lots of custom and weird rules.

Yep, `lit` is contaminating the browser API with their ideas just because their group of people writes the code for the browsers. They should be competing from the outside. Instead of pushing this kind of apis that only fit their mental models.

Re: The time is right for a DOM templating API

#143

Post by taeric »

moritzwarhier wrote: post #105
taeric wrote: post #34

Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost certainly more of a visual thing than it is a symbolic one. Is why dreamweaver and such was so successful back in the day. And why so many designers learn with tools like photoshop. Also hard not to feel like this is reaching hard to try and recreate xslt. :( It is…

> Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost certainly more of a visual thing than it is a symbolic one. How do you come to this conclusion? It seems to me that what you mean is a general gripe with HTML+CSS, not with how it's generated. And why do you bring up absolute positioning? I hear this take on HN a…

I've been in the opposite, where people will go through lengths to try and make it so that the defaultish dom layout makes things "fall into place" so that they had a very specific layout of elements. When a fairly simple set of elements with somewhat minimal styling would get what you wanted surprisingly easy. Provided you did a lot of up front calculation on your own.

Basically, my assertion used to be to draw out what you have in mind on grid paper. Then start creating the elements. I don't see how that flow could land you with the 100ish divs that you wind up with on something like a single blue sky post.

Is it a panacea? No. Of course not. Can a constraint language help? I think so.

I'll add that the flex layouts seem like an improvement over what used to be there. Even if I find it rather amusing that we seem to have settled back on tables for layout. :D (I suppose it is more like some of the layout managers from Java days, truthfully.)

But, fundamentally, the problem appears to be that the drop to symbolic text is just not something that everyone does the same way. As such, it is very easy to get into a lot of trouble with the number of cooks in the kitchen, as it were.

Re: The time is right for a DOM templating API

#144

Post by taeric »

chii wrote: post #106
taeric wrote: post #34

Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost certainly more of a visual thing than it is a symbolic one. Is why dreamweaver and such was so successful back in the day. And why so many designers learn with tools like photoshop. Also hard not to feel like this is reaching hard to try and recreate xslt. :( It is…

> People will go through obscene lengths to recreate what judicious use of absolute positioning can achieve fairly well the web has the requirement that the 'document' look good no matter what device size/dimension, orientation, and/or capability. In regular apps (say, a windows app), you don't have this requirement. In mobile apps, there's a standardized set of sizes. Only on web do we have both!

Not really? People impose the idea that they can make this work. Yet no sites looked good on the Nintendo DS browser, and people were largely ok with that. Few sites look genuinely good on phones. People are largely ok with that.

Re: The time is right for a DOM templating API

#145

Post by taeric »

jdkoeck wrote: post #135
taeric wrote: post #34

Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost certainly more of a visual thing than it is a symbolic one. Is why dreamweaver and such was so successful back in the day. And why so many designers learn with tools like photoshop. Also hard not to feel like this is reaching hard to try and recreate xslt. :( It is…

> Hard not to laugh out loud at "We know what good syntax for templating looks like." First of all, it's not very nice to laugh in the face of someone advocating for progress on the web platform, which benefits everyone. Second of all, yes we do now know what good syntax for templating is, it's basically jsx (and I'm saying this as someone who's really not a fan of React). It took the whole web by storm, it's been ad…

I'm laughing because it just hits so hard. Started playing some role playing with friends again recently and we were looking for a template for the character sheets. You know what they have? A PDF. That is their template. Why? Because they design things that way.

And it is funny, because I can already feel the ideas that would go into templating this symbolically. Characters have 6 and 20 numeric attributes. But, I can already guess most would consider it a fault to manually place either of those on the page. Yes, the sheet has a limitation on how big your name can be. No, you can't really avoid that.

JSX is what happens when you no longer have a design and a dev team. It is great at that, even. But if you have a workflow where a designer makes a template and sends it over to a dev, it no longer really helps. You are much better off making something that can pick at artifacts that are handed off.

Instead, we seem to be aiming for an idea that will have to replace learning of everyone involved.

Re: The time is right for a DOM templating API

#146

Post by localvoid »

leeoniya wrote: post #110
localvoid wrote: post #76

Earlier quoted context omitted.

Just want to add that even though ivi is using tagged templates, I am strongly against using tagged templates to describe UIs as a Web Standard. One of the most useful features that could make a lot of incremental computation problems easier is "value types"[1], but unfortunately it seems that isn't going to happen anytime soon. The biggest constraint when developing an efficient UI framework with good DX is JavaScri…

> The biggest constraint when developing an efficient UI framework with good DX is JavaScript. for perf, s/JavaScript/DOM, i think. good DX comes from ecosystem and amount of time invested in making good tooling. JSX would be a non-starter without IDEs helping autocomplete, linting/format, syntax coloring, and webpack/babel to do the compilation. tagged templates could reach at least the same level of DX as JSX if th…

I would prefer a more expressive language like Kotlin[1] that makes it easier to work with many different domains instead of JSX hacks :)

1. https://developer.android.com/develop/ui/compose/kotlin

Re: The time is right for a DOM templating API

#147

Post by lelanthran »

Gualdrapo wrote: post #8
quantadev wrote: post #6

Templates are great until they need to be dynamic. Then you're right back to the current situation where frameworks like React are just the better way. In fact, you could call JSX a "Dynamic Templating System" and that's a reasonable summary of what it is (in addition to other things of course). There might be some ways that React itself could, internally, notice the special cases and special times where it _could_ b…

"If I could wave my magic wand..." at least 2 of 3 of the changes I'd made about the way frontend web is developed, would be about ` `s: 1. Making it possible to do something like and being able to load them from an external source 2. Making them "dynamic" 3 (and the most controversial one) that all CSS, HTML and Javascript (if you don't hate it) could be written natively like QML - one syntax to rule them all.

> 1. Making it possible to do something like and being able to load them from an external source

I've done that, requires no build step/npm/whatever. It was posted on HN for discussion a week ago: https://github.com/lelanthran/ZjsComponent

Re: The time is right for a DOM templating API

#148

Post by troupo »

aatd86 wrote: post #129
troupo wrote: post #118

Earlier quoted context omitted.

> I don't quite understand. The DOM is/needs a functional API. Why bolt another DSL on top? There are no parts of DOM APIs that are functional. It's all 90s-era Java OOP-style.

functional in the sense that it uses method calls on objects and javascript has higher order functions. It is a spectrum. I know DOM nodes are objects that use inheritance but I also know javascript is not deemed a "traditional" functional PL of course.

Javascript being a decent functional language does not make DOM API functional.

DOM API is 90-s era OOP

Re: The time is right for a DOM templating API

#149

Post by troupo »

jraph wrote: post #137
troupo wrote: post #115

Earlier quoted context omitted.

> So you are saying that Array.from(querySelectorAll) gets you there? What are you missing then? Array.from adds friction. The need to wrap querySelector in null checks adds friction. The fact that they are not composable in any way, shape, or form, with any DOM methods (and that DOM methods are not composable) adds friction. jQuery was the fore-runner of fluid interface design. Nothing in the DOM before, then, or si…

I agree that DOM lists not being real arrays is a pita. I can understand why for getElementBy* methods which return live lists, but it's less clear for those methods returning fixed lists. But to me, these are minor inconveniences and habits. A thin wrapper can get you there easily if you care enough. I personally dislike this array/element confusion that jQuery adds.

> A thin wrapper can get you there easily if you care enough

But that's more and more friction. A wrapper here, a wrapper there, and if here, a try/catch there. At one point you are reinventing significant chunks of jQuery

Re: The time is right for a DOM templating API

#150

Post by agumonkey »

HelloNurse wrote: post #130
agumonkey wrote: post #94

Earlier quoted context omitted.

The node pattern matching was ok, but as far as i can recall, there could be multiple matching patterns scattered in lots of places (a 180deg turn compared to most FP pattern matching that aim for exhaustiveness ?)

Exhaustiveness is only relevant for the compiler-managed pattern matching of a traditional FP type system, where you need to write an implementation (patterns that will be used at matching usage sites) for everything that your types promise. XSLT pattern matching is the plain kind: here is a pattern, look for it in the input and process every match. If some part of the input document is ignored, it's just not useful;…

I get it, but it's hard to track
Post reply on HN