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

111–120 of 256 posts

Re: The time is right for a DOM templating API

#111

Post by mattmanser »

nine_k wrote: post #84
notpushkin wrote: post #62

Earlier quoted context omitted.

I’m a big fan of XHTML (strictness is good) and feel like XSLT could be a great addition, but I hate the syntax. I’d love to build a Jinja to XSLT compiler one day. I also have a simple playground for XSLT: https://xsltbin.ale.sh/

XSLT's weaknesses are the extension of its strengths. It's the first homoiconic, purely functional language that enjoyed widespread adoption among "normal" developers, not type theory wonks. But XML's syntax sucks, and so inevitably does XSLT's, because XSLT is just XML. Were it s-expressions, the syntax could suck slightly less. It was (is!) a small price to generate XSLT using XSLT, which makes XSLT very powerful a…

I wouldn't say it had widespread adoption. We used XSLT in my day job at the time to do client-side updates, even had a special SQL API that turned sql queries into XML automatically by naming the columns with a special syntax and it was virtually unheard of (2007?).

It was actually great when you got it, but the learning curve was so steep many developers couldn't use it effectively to begin with. For complex pages only certain developers could make changes or fix the bugs. Precisely because it was functional and most developers at the time really only understood imperative.

In fact, I remember the DailyWTF had a WTF about using XSLT as client-side transforms a few years later:

https://thedailywtf.com/articles/Sketchy-Skecherscom

But doing something like that was in fact so much faster than doing it in js, and when you groked it (deliberate throwback), it was so much simpler. I actually wrote a pivot table control in XSLT which completely blew away the performance of the pre-v8 javascript one. Pre-V8 javascript was so slow most developers wouldn't believe you now. A 10,000 iteration loop of even basic operations was often enough to cause IE6 to show a pop-up saying the page wasn't responding.

The pivot table in javascript would crash with just a few hundred lines of data, in XSLT it was instant with even 10,000s.

A really interesting use of XSLT on the web at the time was the WoW character viewer. You could view (and share) your character on Blizzard's website, with all their gear, skills, etc. It was blazingly fast for the time and it was all written in XSLT.

Re: The time is right for a DOM templating API

#112

Post by JimDabell »

troupo wrote: post #96
jlukic wrote: post #73

It’s worth noting this was written by maybe the person with the most experience in the space i can think of—-the primary author of Lit / Polymer working at web components on Google and contributing on many core DOM specs that have become part of the web platform.

> It’s worth noting this was written by by one of the people wrecklessly barging forward with half-baked specs that introduced significantly more problems than they solved, pushed a "solution" that requires 20+ new web specs to barely do all the things user-space is already doing while completely ignoring and gaslighting anyone who wasn't 100% on board with what they were doing. Safari argued that there should be a d…

Web components were such a big disappointment. 200% the complexity for 20% of the functionality. Everything coming out of that area seems to be hideously over-engineered while failing to solve the problems people wanted them to.

My feeling is that they were focused on designing something that is aimed at building form controls, not the kinds of components web developers use in practice. They are designed to make browser vendors’ lives easier, not web developers. That’s often excused with “web components excel at ‘leaf‘ components” when what is actually meant is “web components are bad at everything else”.

I would expect an actually good solution that fits in with the web’s architecture to come from the direction of HTMX, not web components.

> Safari argued that there should be a declarative ways for this 15 years ago

True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course).

Re: The time is right for a DOM templating API

#113

Post by austin-cheney »

aatd86 wrote: post #101

I don't quite understand. The DOM is/needs a functional API. Why bolt another DSL on top? Now you have to find a way for javascript to interact with your template language. While functions are sufficient. That doesn't look like orthogonal language design.

People want this because JSX is all they are capable of.

One reason why things like this have never happened before is because the people who need this are only barely capable of working with HTML. The DOM supports a wide variety of technologies far outside and unrelated to HTML.

Re: The time is right for a DOM templating API

#114

Post by infensus »

llcooliovice wrote: post #86

> There's no fundamental templating knowledge that's portable between stacks, and native DOM creation APIs like innerHTML are unsafe by default. setHTML() is already implemented in Chrome/Edge and Firefox so this point is a bit outdated - there is a safe alternative to innerHTML.

MDN and caniuse say otherwise. I think there might've been an older specification that got implemented, but it's been revised since

Re: The time is right for a DOM templating API

#115

Post by troupo »

jraph wrote: post #102
troupo wrote: post #98

Earlier quoted context omitted.

Not entirely. There's a reason people do Array.from(querySelectorAll) to do more than just `forEach`

So you are saying that Array.from(querySelectorAll) gets you there? What are you missing then? Genuinely asking, I have no clue what's being alluded to without being clearly mentioned in this thread.

> 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 since ever thought about it. Even the new APIs are all the same 90s Java-style method calls with awkward conversions and workarounds to do anything useful.

That's why sites like "You don't need jQuery" read like bad parody: https://youmightnotneedjquery.com

E.g. what happens when it's not just one element?

   $(el).addClass(className);

   // vs.

   el.classList.add(className);
Or: why doesn't NodeList expose an array-like object, but provides an extremely anaemic interface that you always need to convert to array? [1]

   $(selector).filter(filterFn);

   // vs.

   [...document.querySelectorAll(selector)].filter(filterFn);
There's a reason most people avoid DOM APIs like the plague.

---

[1] This is the entirety of methods exposed on NodeList https://developer.mozilla.org/en-US/docs/Web/API/NodeList

Instance properties

- length

Instance methods

- entries() // returns an iterator

- forEach()

- item()

- keys()

- values()

Re: The time is right for a DOM templating API

#116

Post by troupo »

JimDabell wrote: post #112
troupo wrote: post #96

Earlier quoted context omitted.

> It’s worth noting this was written by by one of the people wrecklessly barging forward with half-baked specs that introduced significantly more problems than they solved, pushed a "solution" that requires 20+ new web specs to barely do all the things user-space is already doing while completely ignoring and gaslighting anyone who wasn't 100% on board with what they were doing. Safari argued that there should be a d…

Web components were such a big disappointment. 200% the complexity for 20% of the functionality. Everything coming out of that area seems to be hideously over-engineered while failing to solve the problems people wanted them to. My feeling is that they were focused on designing something that is aimed at building form controls, not the kinds of components web developers use in practice. They are designed to make brow…

> True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course).

Safari doesn't have as many engineers (a shame) and definitely doesn't have as many people whose apparent job is just to sit on standards committees and generate specs (like Alex Russel, Justin Fangnani etc.).

They did end up proposing declarative template instantiation in 2017: https://github.com/WICG/webcomponents/blob/gh-pages/proposal... but that mostly went nowhere

Re: The time is right for a DOM templating API

#117

Post by troupo »

shermantanktop wrote: post #25

A basic lesson we've learned over and over is that API/ABIs aren't final. Application needs are never permanently fulfilled by a stable API, with all future problems considered to be app-level issues. This proposal is a good example of how common issues with the platform are solved on top (React etc.) until we recognize them as a problem and then push them down. Polyfills are another example. If a proposal like this…

> A basic lesson we've learned over and over is that API/ABIs aren't final.

On the web they are. Once something is out in the open on the web, there will be people depending on this, in this exact form, forever.

That's why there are still APIs that end up in "smooshgate" because of decisions from 20 years ago: https://developer.chrome.com/blog/smooshgate

Re: The time is right for a DOM templating API

#118

Post by troupo »

aatd86 wrote: post #101

I don't quite understand. The DOM is/needs a functional API. Why bolt another DSL on top? Now you have to find a way for javascript to interact with your template language. While functions are sufficient. That doesn't look like orthogonal language design.

> 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.

Re: The time is right for a DOM templating API

#119

Post by JimDabell »

troupo wrote: post #116
JimDabell wrote: post #112

Earlier quoted context omitted.

Web components were such a big disappointment. 200% the complexity for 20% of the functionality. Everything coming out of that area seems to be hideously over-engineered while failing to solve the problems people wanted them to. My feeling is that they were focused on designing something that is aimed at building form controls, not the kinds of components web developers use in practice. They are designed to make brow…

> True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course). Safari doesn't have as many engineers (a shame) and definitely doesn't have as many people whose apparent job is just to sit on standards committees and generate specs (like Alex Russel, Justin Fangnani etc.). They did end up proposing declarative template instanti…

That looks interesting – certainly a lot simpler and closer to web developers’ needs than what ended up getting standardised.

It really is a shame Apple don’t invest more in WebKit and the web standards process. Although they’ve been doing a lot better over the past few years.

Re: The time is right for a DOM templating API

#120

Post by troupo »

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…

> JSX would be a non-starter without IDEs helping autocomplete, linting/format, syntax coloring, and webpack/babel to do the compilation.

and then you immediately go on to say this:

> tagged templates could reach at least the same level of DX as JSX if the community invested the resources to make that better.

So, tagged templates are also non-starters without IDEs helping autocomplete, linting/format, syntax coloring.

> i'm not saying it's the right solution for a standard, but it would be way better than jsx, since tagged templates are already a standard.

They are strings. There's no magic in tagged templates that somehow make them immediately better for some custom non-standard syntax compared to JSX.

You can't just plop a string containing lit's custom non-standard syntax into an IDE (or a browser) and expect it to just work because "it's tagged templates are standard".

For the purpose of templating in the browser there's literally no difference between standardizing a custom syntax based with JSX or tagged templates.

Post reply on HN