7 ms·

Declarative Enhancement for HTML

123 points by revskill 3y ago

evrimoztamur 3y ago
How does it compare to HTMX? Anybody have experience with both?
- andybak 3y ago
  That was the first thig I wondered too. In case you didn't spot this part: > Some reasons why TwinSpark exists despite HTMx and Unpoly (those are similar in approach): > > It’s really small (8KB .min.gz). > There is no attribute inheritance — keeps surprises away. > Batching - very useful if you want to use HTTP caching effectively, while maintaining some personalisation for your users. > Bundled - a lot of practical stuff packed in, like actions, or non-traditional event triggers, or morphing. > Extensibility - you can easily register new directives the same way those in core are registered.
  - rakoo 3y ago
    This doesn't answer the question "why not bring this inside htmx or unpoly", and now as a developer I need to again check if I need to port over a new framework or not
    - piranha 3y ago
      Two reasons really: I wrote it before htmx appeared, so it already existed and a few projects were using it in production. And second one - I really hate attribute inheritance, and it’s everywhere in htmx…
      - rakoo 3y ago
        The blog post hints at the first point, but I didn't know about the latter, so thanks for the details !
    - andybak 3y ago
      > now as a developer I need to again check if I need to port over a new framework or not Why do you "need to"? Use what works for you. Glance over new stuff and dig deeper if some aspect of it appeals to you. And if the churn stresses you out then don't.
  - dgb23 3y ago
    Most of these also apply to HTMX it seems. I think a bigger difference is that TwinSpark seems to have some integrated DOM manipulation, so it's a bit bigger in scope and less opinionated? HTMX on its own is great as long as you stay within its philosophy of rendering things on the server. But most UIs I write need - as in it's optimal for UX and performance or out of necessity because it's talking to a third party - at least _some_ parts to be fully client side rendered. I personally found that combining HTMX with something like lit-html is kind of the sweet spot for a lot of projects assuming full-stack development. These are very small/light libs that cover a ton of ground with minimal surprises and very good performance per default. The _only_ downside is that you don't get isomorphic rendering code but I happily pay that relatively small cost for having such a simple dependency graph.
    - piranha 3y ago
      Why do you feel the need to use lit-html? Just interested in the use-case.
      - megaman821 3y ago
        I am not the original poster, but I use lit-html to make the interactive elements on the page like tabs and modals. Then I use HTMX to load the contents of those elements when the tab or trigger is clicked.
        piranha 3y ago
        That's one of the reasons TwinSpark got actions, you still need little bits of client-side interactivity.
        megaman821 3y ago
        I find things like actions is great for conditionally showing and hiding form fields or small things like that, but if you want to have accessible tabs and modals it is best to bundle it up in a component. Here is an example of a lit components I use, https://codepen.io/megaman821/pen/GRXmzZb https://codepen.io/megaman821/pen/GRXmzZb and https://codepen.io/megaman821/pen/dydvxBE https://codepen.io/megaman821/pen/dydvxBE
nsonha 3y ago
When do people understand "declarative" is a style not a property of some language? As the language, "declarative" xml and by extension, html has failed in every single platform (the web, android, iOS), which is why in all of those platforms people have been trying for years to write UI in code, but in a more declarative style (React, Swift UI, Jetpack Compose). This is backward.
- chrisco255 3y ago
  Declarative markup always evolves into a badly conceived programming language.
  - Drakim 3y ago
    That's also been my experience, yet I've also gotten a spaghetti of a mess assembling the UI in regular code with loops and whatnots. Are there any other interesting options I could explore?
    - nsonha 3y ago
      an imperative language that is DSL-friendly, such as kotlin and jetpack compose, or just functional languages, like ClojureScript's Reagent. JSX is fine too. It's gotten a lot a bad rap because of React, but looping and conditions have never bothered me, despite people's complains about them.
    - wongarsu 3y ago
      Declarative Code for initial state, with modifications done in regular code. Ideally data bindings for lists etc. (so the declarative part can state "this is a scrollable list view, each item looks like this, the content of these items is stored in variable Y", and any update to Y updates the list)
  - maweki 3y ago
    I think in one direction, i.e. templating, it works fine. Have data, have declarative syntax on how to iterate over data and generate fresh code from that. The bidirectional case is already difficult where your changes in the generated source should backtranslate into changes in the supplied data. But now also declaring interactions in the general case? This endeavour must surely fail, as there are so many possible interactions and so little design space without running into either the inner platform effect, where you're just replicating the host programming language (but with bugs), or Greenspun's tenth rule of programming, where you're accidentally building "an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp". As an aside: I think a sweet spot is providing some UI elements and a framework for composing them, and then having a kind of DSL to low-code-connect them up in the DOM. You can abstract a lot of stuff away from the end user using, you know, code. And then the DSL can be nice for the interactions. But we all know that interactivity is hard and complex and no way of writing it down, be that imperative, declarative, or whatnot, will take that away. Edit: Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.
m3h 3y ago
It would be great to have some examples right on the main page as many devs would be interested in how this library compares to the React/Vue/Angular/etc. Currently, the code samples are hidden two levels deep and behind a view source button.
- piranha 3y ago
  Thanks for that message, it was just hard for me to decide on what to put in there :) But your comment forced me to, so I've put something in there, even if it's not really thought through. :)
  - revskill 3y ago
    Could be a todo example with a static json as API ?
    - piranha 3y ago
      There is no way to render JSON as HTML right now, it expects server to return HTML. OTOH that's an interesting thought and it feels like just an addition of one command to whatever there are in actions ( https://twinspark.js.org/api/ts-action/ https://twinspark.js.org/api/ts-action/ ) right now... I need to think about it a bit. :)
      - murkt 3y ago
        An action that renders HTML from JSON will either: — Require additional client-side templates and then it's back straight to hell; — Require really specific JSON structure, basically HTML-in-JSON, which will be ugly as hell and totally meaningless. Meaningless, because then it means I need to adapt my API to this format, and then I can just make it return HTML.
        piranha 3y ago
        Yeah it’s only the first way, since the second is effectively the same as rendering html on the server. As for the first - it could give a way to use legacy apis and static data. Not sure if I want this in the core, but… how hard can it be?
zsoltkacsandi 3y ago
I have been thinking for a while to create a new library/framework that composes the features of Tailwind/DaisyUI and HTMX/Unpoly/Hotwire into a SwiftUI like declarative template language (forcing these features into HTML attributes makes HTML bloated/difficult to write) that eventually generates all the HTML, JS, CSS code in the background. I am tired of MVC frameworks, SPAs, writing CSS, JS, dealing with tooling, setting up IDEs to format the code properly, etc, I just want to create nice webapps, and want my app designed nicely from the first line of code I write.
- _connerc 3y ago
  have you thought about low code platforms?
  - zsoltkacsandi 3y ago
    Why would I? I didn't say that I don't want to write code, but don't want to deal with this frontend madness. Other platforms (Android, Swift, desktop, etc), has been able to solve that the web hasn't been able to do in 30 years.
    - kristiandupont 3y ago
      I on the other hand find that "npm create vite@latest" is orders of magnitude simpler than working with any of the Android or iOS developer environments. I can't speak to "desktop" as I haven't done anything like that in 10 years, but I have a feeling that it would be similar. Could it perhaps be that you are confusing familiarity with simplicity?
      - zsoltkacsandi 3y ago
        Please show me how Vite helps you to work in one language instead of three.
        Rumudiez 3y ago
cyberproblem 3y ago
How does this differ from Alpine? It looks like an AlpineJs 2.
- piranha 3y ago
  It's more like an alternative implementation of htmx. Alpine is more about "let's do components in HTML", and this one is more of an idea "how do not go there, but still have practical results". :)
culopatin 3y ago
Is the name in any way associated with the two spark plug Alfa Romeo engines?
- piranha 3y ago
  Yeah, that was the inspiration. If you know, htmx predecessor was called intercooler.js, so I just continued the automotive theme. :) I had a reference on main page for a long time...
imbnwa 3y ago
Would be interesting to see the HTML spec find a way to pull from the SCXML[0] spec for declaratively modeling nested, parallel state machines, maybe adding pseudo-selectors to CSS for querying it. [0]https://www.w3.org/TR/scxml/ https://www.w3.org/TR/scxml/
cassepipe 3y ago
It reminds me of hyperscript: https://hyperscript.org/ https://hyperscript.org/ I am fine with writing a little js has long as it's colocated with the (augmented) html and css. I think the svelte approach scales better and seems more easily debuggable because it enforces a structure and is more readable. There is enough stuff in my html tags already.
- piranha 3y ago
  Actions are somewhat similar, yeah, even if much more limited. Svelte was too js-heavy, and it requires js backend to be rendered on the server - while we had no js engineers. Plus markup was already done, as we rendered it server-side when using React.
  - cassepipe 3y ago
    Nit: SvelteKit requires a backend on the server (actually it does not you can use it only for the client side rourting and have no SvelteKit backend and talk directly to your own backend) but Svelte does not as it is just a superset of html. Even when using the SvelteKit backend you can disable server side rendering. But sure I trust you that the htmx way was the way to go for your use case/situation
replwoacause 3y ago
Looks awesome, can’t wait to try it out!

123 points by revskill 3y ago

evrimoztamur 3y ago

How does it compare to HTMX? Anybody have experience with both?

andybak 3y ago
That was the first thig I wondered too. In case you didn't spot this part: > Some reasons why TwinSpark exists despite HTMx and Unpoly (those are similar in approach): > > It’s really small (8KB .min.gz). > There is no attribute inheritance — keeps surprises away. > Batching - very useful if you want to use HTTP caching effectively, while maintaining some personalisation for your users. > Bundled - a lot of practical stuff packed in, like actions, or non-traditional event triggers, or morphing. > Extensibility - you can easily register new directives the same way those in core are registered.
- rakoo 3y ago
  This doesn't answer the question "why not bring this inside htmx or unpoly", and now as a developer I need to again check if I need to port over a new framework or not
  - piranha 3y ago
    Two reasons really: I wrote it before htmx appeared, so it already existed and a few projects were using it in production. And second one - I really hate attribute inheritance, and it’s everywhere in htmx…
    - rakoo 3y ago
      The blog post hints at the first point, but I didn't know about the latter, so thanks for the details !
  - andybak 3y ago
    > now as a developer I need to again check if I need to port over a new framework or not Why do you "need to"? Use what works for you. Glance over new stuff and dig deeper if some aspect of it appeals to you. And if the churn stresses you out then don't.
- dgb23 3y ago
  Most of these also apply to HTMX it seems. I think a bigger difference is that TwinSpark seems to have some integrated DOM manipulation, so it's a bit bigger in scope and less opinionated? HTMX on its own is great as long as you stay within its philosophy of rendering things on the server. But most UIs I write need - as in it's optimal for UX and performance or out of necessity because it's talking to a third party - at least _some_ parts to be fully client side rendered. I personally found that combining HTMX with something like lit-html is kind of the sweet spot for a lot of projects assuming full-stack development. These are very small/light libs that cover a ton of ground with minimal surprises and very good performance per default. The _only_ downside is that you don't get isomorphic rendering code but I happily pay that relatively small cost for having such a simple dependency graph.
  - piranha 3y ago
    Why do you feel the need to use lit-html? Just interested in the use-case.
    - megaman821 3y ago
      I am not the original poster, but I use lit-html to make the interactive elements on the page like tabs and modals. Then I use HTMX to load the contents of those elements when the tab or trigger is clicked.
      - piranha 3y ago
        That's one of the reasons TwinSpark got actions, you still need little bits of client-side interactivity.
        megaman821 3y ago
        I find things like actions is great for conditionally showing and hiding form fields or small things like that, but if you want to have accessible tabs and modals it is best to bundle it up in a component. Here is an example of a lit components I use, https://codepen.io/megaman821/pen/GRXmzZb https://codepen.io/megaman821/pen/GRXmzZb and https://codepen.io/megaman821/pen/dydvxBE https://codepen.io/megaman821/pen/dydvxBE

nsonha 3y ago

When do people understand "declarative" is a style not a property of some language? As the language, "declarative" xml and by extension, html has failed in every single platform (the web, android, iOS), which is why in all of those platforms people have been trying for years to write UI in code, but in a more declarative style (React, Swift UI, Jetpack Compose). This is backward.

chrisco255 3y ago
Declarative markup always evolves into a badly conceived programming language.
- Drakim 3y ago
  That's also been my experience, yet I've also gotten a spaghetti of a mess assembling the UI in regular code with loops and whatnots. Are there any other interesting options I could explore?
  - nsonha 3y ago
    an imperative language that is DSL-friendly, such as kotlin and jetpack compose, or just functional languages, like ClojureScript's Reagent. JSX is fine too. It's gotten a lot a bad rap because of React, but looping and conditions have never bothered me, despite people's complains about them.
  - wongarsu 3y ago
    Declarative Code for initial state, with modifications done in regular code. Ideally data bindings for lists etc. (so the declarative part can state "this is a scrollable list view, each item looks like this, the content of these items is stored in variable Y", and any update to Y updates the list)
- maweki 3y ago
  I think in one direction, i.e. templating, it works fine. Have data, have declarative syntax on how to iterate over data and generate fresh code from that. The bidirectional case is already difficult where your changes in the generated source should backtranslate into changes in the supplied data. But now also declaring interactions in the general case? This endeavour must surely fail, as there are so many possible interactions and so little design space without running into either the inner platform effect, where you're just replicating the host programming language (but with bugs), or Greenspun's tenth rule of programming, where you're accidentally building "an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp". As an aside: I think a sweet spot is providing some UI elements and a framework for composing them, and then having a kind of DSL to low-code-connect them up in the DOM. You can abstract a lot of stuff away from the end user using, you know, code. And then the DSL can be nice for the interactions. But we all know that interactivity is hard and complex and no way of writing it down, be that imperative, declarative, or whatnot, will take that away. Edit: Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.

m3h 3y ago

It would be great to have some examples right on the main page as many devs would be interested in how this library compares to the React/Vue/Angular/etc. Currently, the code samples are hidden two levels deep and behind a view source button.

piranha 3y ago
Thanks for that message, it was just hard for me to decide on what to put in there :) But your comment forced me to, so I've put something in there, even if it's not really thought through. :)
- revskill 3y ago
  Could be a todo example with a static json as API ?
  - piranha 3y ago
    There is no way to render JSON as HTML right now, it expects server to return HTML. OTOH that's an interesting thought and it feels like just an addition of one command to whatever there are in actions ( https://twinspark.js.org/api/ts-action/ https://twinspark.js.org/api/ts-action/ ) right now... I need to think about it a bit. :)
    - murkt 3y ago
      An action that renders HTML from JSON will either: — Require additional client-side templates and then it's back straight to hell; — Require really specific JSON structure, basically HTML-in-JSON, which will be ugly as hell and totally meaningless. Meaningless, because then it means I need to adapt my API to this format, and then I can just make it return HTML.
      - piranha 3y ago
        Yeah it’s only the first way, since the second is effectively the same as rendering html on the server. As for the first - it could give a way to use legacy apis and static data. Not sure if I want this in the core, but… how hard can it be?

zsoltkacsandi 3y ago

I have been thinking for a while to create a new library/framework that composes the features of Tailwind/DaisyUI and HTMX/Unpoly/Hotwire into a SwiftUI like declarative template language (forcing these features into HTML attributes makes HTML bloated/difficult to write) that eventually generates all the HTML, JS, CSS code in the background. I am tired of MVC frameworks, SPAs, writing CSS, JS, dealing with tooling, setting up IDEs to format the code properly, etc, I just want to create nice webapps, and want my app designed nicely from the first line of code I write.

_connerc 3y ago
have you thought about low code platforms?
- zsoltkacsandi 3y ago
  Why would I? I didn't say that I don't want to write code, but don't want to deal with this frontend madness. Other platforms (Android, Swift, desktop, etc), has been able to solve that the web hasn't been able to do in 30 years.
  - kristiandupont 3y ago
    I on the other hand find that "npm create vite@latest" is orders of magnitude simpler than working with any of the Android or iOS developer environments. I can't speak to "desktop" as I haven't done anything like that in 10 years, but I have a feeling that it would be similar. Could it perhaps be that you are confusing familiarity with simplicity?
    - zsoltkacsandi 3y ago
      Please show me how Vite helps you to work in one language instead of three.
      - Rumudiez 3y ago

cyberproblem 3y ago

How does this differ from Alpine? It looks like an AlpineJs 2.

piranha 3y ago
It's more like an alternative implementation of htmx. Alpine is more about "let's do components in HTML", and this one is more of an idea "how do not go there, but still have practical results". :)

culopatin 3y ago

Is the name in any way associated with the two spark plug Alfa Romeo engines?

piranha 3y ago
Yeah, that was the inspiration. If you know, htmx predecessor was called intercooler.js, so I just continued the automotive theme. :) I had a reference on main page for a long time...

imbnwa 3y ago

Would be interesting to see the HTML spec find a way to pull from the SCXML[0] spec for declaratively modeling nested, parallel state machines, maybe adding pseudo-selectors to CSS for querying it. [0]https://www.w3.org/TR/scxml/ https://www.w3.org/TR/scxml/

cassepipe 3y ago

It reminds me of hyperscript: https://hyperscript.org/ https://hyperscript.org/ I am fine with writing a little js has long as it's colocated with the (augmented) html and css. I think the svelte approach scales better and seems more easily debuggable because it enforces a structure and is more readable. There is enough stuff in my html tags already.

piranha 3y ago
Actions are somewhat similar, yeah, even if much more limited. Svelte was too js-heavy, and it requires js backend to be rendered on the server - while we had no js engineers. Plus markup was already done, as we rendered it server-side when using React.
- cassepipe 3y ago
  Nit: SvelteKit requires a backend on the server (actually it does not you can use it only for the client side rourting and have no SvelteKit backend and talk directly to your own backend) but Svelte does not as it is just a superset of html. Even when using the SvelteKit backend you can disable server side rendering. But sure I trust you that the htmx way was the way to go for your use case/situation

replwoacause 3y ago

Looks awesome, can’t wait to try it out!