Convert TiddlyWiki widgets to web components

Developers
#1

I see what is possibly the most creative, innovative, and forward-thinking opportunity that the current design of TW5 widgets has granted us. I think they could be converted to web components.

Variables can use bubbling synchronous events, as some existing web-component-based frameworks already do.

Since widgets refresh the DOM by completely replacing children in most cases, the lifecycle is already stricter than what web components are.

All of wikitext converts to a widget tree under the hood anyway. It would not be difficult to move from that to web components and then from there to making use of ui design that is based on web components.

This wasn’t possible with react. But I think it might be possible with web components.

#2

For those like me that are not versed on web components, what is so exciting about that? Which use cases might this allow?

#3

The target browsers / JS spec is ES2017. So specification that old browsers from 2017 support.

image
image1932Ă—867 145 KB

Since no old target browser supports it, we would probably need to polyfill it. – If that’s possible. But if it is poly-filled, there is no difference to the current widget system anymore.

Even with latest browser there seems to be a problem with Safai. There is a “feature” WONTFIX somewhere in the WebKit repo.

#4

The safari thing is not an issue. They don’t support extending builtin components. They do support normal standalone components.

Web components appear to be an ES2015 feature, so that should largely be a non issue.

I’m not closely familiar with web components so I don’t know what specific advantages they bring. I’m only pointing out that the lifecycle is compatible, unlike React, and if there was a solid advantage it probably would not be hard to do.

It would also likely decrease core size.

#5

Custom Elements (Web Components) ARE HTML.
Frameworks and libraries merely CREATE HTML.

:white_check_mark: With Web Components, you can write:

<playing-card is="queen-of-hearts"></playing-card>

…and it just works, rendering an SVG card.
See my <playing-card> Web Component: https://cardmeister.github.io/index.html

It does not matter when you register the <playing-card> element in JavaScript — the browser handles it.

You can even build Web Components without JavaScript altogether, using:

<template shadowrootmode="open">
  ...
</template>

:white_check_mark: With a framework or library, you typically start with something like:

<div class="playing-card" data-card="queen-of-hearts"></div>

…but you still need JavaScript after the DOM is parsed (hello FOUC!) to transform it into the intended SVG card.

:green_circle: Key points

  • Web Components = semantic, declarative HTML
  • Frameworks/Libraries = “div soup” that needs post-processing

All modern browsers support Web Components today.

:point_right: Apple (correctly, following the Liskov principle) blocked Customized Built-In Elements as early as 2013 — showing this is not some new fad. In fact, the browser engines have been using these principles (shadow DOM, encapsulation) internally for complex tags like <video> and <select> for many years.

US mortal developers only got public APIs in 2018.

:white_check_mark: If you’re building a public-facing website in 2025, you can safely drop IE11 support.

  • IE11 usage is under 0.2% globally
  • Essentially gone in Europe, North America, and Australia
  • Slightly higher (but still under 0.5%) in parts of Asia due to legacy apps
  • Most traffic even there is on modern browsers

(A polyfill is needed for Web Components if you still want to support IE11, but you probably shouldn’t.)

5 Likes
#6

Oh wow! That certainly looks like someting TW could use on a very fundamental level (…I said, in spite of very limited knowledge on these matters).

Also a warm welcome to @Danny_Engelman !

#7

Thinking out loud:

Maybe this can be done without any conflicts… kind of like the details construct vs the RevealWidget. Web components could be introduced one at a time, perhaps by different people, and they could be served via some plugin that collects them all… and over time the community might see them as full replacements of the widgets?

…but first we’d need to clarify the exact benefits of the whole idea. What Danny_Engelman says, i.e:

Custom Elements (Web Components) ARE HTML.
Frameworks and libraries merely CREATE HTML.

…implies obvious advantages but are there more? Are there disadvantages?

BTW, I’m reminded of Lea Verous Mavo project and its goal to let people create functional websites without js, using just hmtl and css.

#8

  • Google pushed Web Components for a long time. This eventually lead to a V0 version hardly supported by Mozilla and Apple. V1 is the 2018 version supported by all browser vendors. All this created confusion and a lot of back-lash. Old V0 (Google only) technologies (like host-context) appeared in Blogs, and thus also appear in AI generated code.

  • shadowDOM is hated by many because it is a totally different mind-set than BEM CSS solutions like Tailwind. shadowDOM (scoped CSS styles AND HTML!) is totally optional. shadowDOM and related technologies like SLOTs and shadow Parts (yes! you idiots you CAN style shadowDOM with Global CSS, just RTFM!) is not something you grasp in a couple of hours.

  • The Custom Element API is 50 characters more verbose than using Frameworks. So many developers created their own BaseClasses thinking their version was the best ever. Google created the most known Lit, but there are now 70+ alternatives, adding to the confusion… oh and the main Lit developer left Google…

My advice

  • Start small, pick a UI element and replace it with a Web Component. When you first learned HTML you started with H1 and P and DIV, you did not start with DETAIL/SUMMARY

  • You don’t have to use JavaScript. any tag with a dash-character in the tag-name IS a valid HTMLElement (not! an HTMLUnknownElement) So you can immediatly use semantic-HTML for your CSS styling. Every lesson dumps you into JavaScript on page 1. Don’t pay for those lessons!

  • stick with Vanilla JS code, only when you can truly value a tool… pick a tool. Or do not, I never use a tool. A fool with a tool, is still a fool. Remember how Angular 2 was not an upgrade to Angular 1, but a whole new language?? The Web Components I write today run without changes for as long JavaScript is supported in the Browser. Any tool I use will cause upgrade issues.
    Note: After a month you will start creating your own “Better BaseClasses”, but they will be yours. If I see anyone here publish their BaseClass as better to NPM, I know where to find you.

  • If you totally do not care about your HTML, CSS and JS in the browser, check out Svelte. If you want HTML you can actually read and understand 5 years from now. Use Web Components.

Check out the HTML of my online book: https://civilaization.github.io/ (not about Web Components, taking the piss at Elon)

1 Like
#9

I think the advantage for tiddlywiki comes from being able to directly integrate widgets into the html lifecycle, and possibly even write the widget tree directly into the DOM as html, removing the need for a separate widget tree.

Along with that, there is always display:content if we don’t want a specific widget tag to affect layout.

It’s just an idea. I haven’t tried implementing it yet.

#10

After finally taking a look at the widget code, I realized that most of the code involves either parsing or variables. There is very little of it that is directly dealing with dom nodes. I’m not sure if there would be any real advantage.

#11

And, if I understand correctly, a fair bit has to do with deciding when rerenders are necessary, based on the state of the widget and its children. I don’t think web components could help there either.

#12

I dontunderstand the arguments here and may not understand the advantages of web components but I can’t help but ask does someone have hammer and think everything is a nail?

being quite well versed in tiddlywiki script and features it is already extremely extendable and can freely leverage html, CSS and JS and continues be extended into any gaps we find such as the html features introduced for external interactions.

I worry when I see a discussion like this that too many people in the conversation bring advanced skills to the community in a seperate field but do not yet have a detailed knowledge of tiddlywiki yet, in effect they are trying to change tiddlywiki into a nail for which they have a hammer, when tiddlywiki is already more capable than they know.

if instead people could state what they need or would like to see or do, as a need or requirement, more often than not the community can respond one of the following ways in order of likelihood

  • It can already be done this is how
    • with tiddlywiki native features
    • you can implement that into tiddlywiki because it already supports html, CSS and javascript
  • Someone has already solved this see this edition or plugin
  • the nessasary support is already in tiddlywiki you just need a macro or widget to expose that feature
  • with a little hack or extension to the core you could do that
  • that solution can be integrated into tiddlywiki like we have done many times before such as incorporating projects or libraries out there.
  • if you have gotten this far perhaps there is a gap to fill
  • if no easy way to fill the gap maybe we should discuss architectural solutions.

this discussion seems to be starting at the bottom of the list, not at the top.

with all due respect to you all, Tony

1 Like
#13

This discussion would probably have been better held on GitHub, but there is a wider audience here, and some of them have significant experience with modern web development.

This was not addressing any gap in functionality, nor something that can be done in wikitext. Instead, it was proposing that the core rendering engine might be better if rebuilt on the modern web component framework. While the conclusion was that no, there is no advantage, it was very interesting to contemplate.