dream-html
dom

dream-html | dom | |
---|---|---|
13 | 31 | |
174 | 1,612 | |
4.0% | 0.9% | |
9.2 | 7.3 | |
16 days ago | 6 days ago | |
OCaml | HTML | |
GNU General Public License v3.0 only | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
dream-html
- The Future of Htmx
-
Constructing XML output with dream-html
FOR some time now, I have been maintaining an OCaml library called dream-html. This library is primarily intended to render correctly-constructed HTML, SVG, and MathML. Recently, I added the ability to render well-formed XML markup, which has slightly different rules than HTML. For example, in HTML if you want to write an empty div tag, you do:
-
Hypermedia Systems
htmx is a JavaScript library which interprets a set of HTML attributes and JavaScript events. It doesn't have anything to do with static typing. However, it's fairly easy to add a statically-typed layer on top of it eg https://github.com/yawaramin/dream-html
- Dream-HTML – render HTML, SVG, MathML, Htmx markup from OCaml
-
A Response to "Have Single-Page Apps Ruined the Web?"
There is some truth to this. Imho the next level of htmx is unlocked when you componentize everything like a React app...but with nested routes corresponding to nested components like a Remix app...and using an HTML generation DSL embedded directly in your language, so HTML becomes a first-class citizen of your language's constructs, rather than a templated afterthought. I have a demo of this: https://github.com/yawaramin/dream-html/tree/todoapp/app
-
Second-Guessing the Modern Web
Nowadays I highly recommend HTML embedding libraries directly in the programming language. E.g. ScalaTags https://com-lihaoyi.github.io/scalatags/ or (my own) https://github.com/yawaramin/dream-html
Yes, you give up the ability of designers and frontend-only people to easily work with the HTML templates. But in exchange you get quite a lot.
-
That people produce HTML with string templates is telling us something
I found your article very informative and it matches up quite a bit with my own thinking about HTML generation. In fact it looks like we independently arrived at pretty much the same conclusions. A lot of the issues you raise are the impetus behind the way I designed my HTML-generation DSL: https://github.com/yawaramin/dream-html
-
What's the most htmx-ish language for the server side?
I am developing an HTML generation library on top of Dream, to have great support in the language including htmx support: https://yawaramin.github.io/dream-html/dream-html/Dream_html/index.html
- dream-html: Generate HTML markup from your Dream backend server
-
My Thoughts on OCaml
Look at this code which prints out an HTML tag: https://github.com/yawaramin/dream-html/blob/main/lib/dream_...
Initially you might think generating HTML tags from data structures in code should be a simple matter. But there are complexities--some tags are defined as having no child tags, others do. Some tags are purely character data (unstructured text), not structured data. Some are just comments. We need a way to compose multiple tags together into a single 'virtual' tag for flexible HTML generation. All these conditions can be pretty hard to keep track of--unless your compiler does exhaustiveness checking. Then the compiler will tell you if you missed any cases.
In the example above I didn't make any manual effort to cover all the cases, I simple listed out the cases I wanted to handle in order. The compiler made sure that I didn't miss any.
dom
- Entendendo renderização no browser: DOM
-
A Response to "Have Single-Page Apps Ruined the Web?"
in plain htmx, you can target an area that doesn't disrupt a playing video (e.g. the comments box appending to the comments) or you can use a morphing algorithm that disrupts the DOM less.
i have my own morphing algorithm (and a corresponding htmx plugin that allows you to use it) called idiomorph:
https://github.com/bigskysoftware/idiomorph/
i've also been working with the chrome team to get a feature added they are calling "atomic moves":
https://github.com/whatwg/dom/issues/1255
this would allow us to move elements around in the DOM without losing things like play state or focus or whatever
very excited for this last idea, I think it will be a huge boon for the web in general, not just for htmx
-
HTML Attributes vs. DOM Properties
What I said in my previous comment is observably true. Try making a demo where it isn't.
> A DOM node is a living mutable thing, but the JavaScript object representing that node is not.
The JavaScript object is mutable. The first example in the article shows this.
> That is also why a node list is not an array.
Modern APIs on the web return platform arrays (eg JavaScript arrays). https://webidl.spec.whatwg.org/#js-sequence - here's where the WebIDL spec specifies how to convert a sequence to a JavaScript array.
I'm fully aware of NodeList. There's a reason the spec calls them "old-style" https://dom.spec.whatwg.org/#old-style-collections
> I can understand how this is confusing if you have never operated without a framework, but otherwise it’s really straightforward
Sighhhhhh. I've been a web developer for over 20 years, and spent a decade on the Chrome team working on web platform features. Most of my career has been on the low-level parts of the platform.
Could it be possible that people are disagreeing with you, not because they're stupid, but because you're in the wrong? Please try to be open minded. Try creating some demos that test your opinions.
-
Using XPath in 2023
Domenic Denicola (the man who ruined promises) probably will as well.
https://github.com/whatwg/dom/issues/67
-
Which browser do you recommend, one for personal security-focused use and one for work?
I'm pretty sure it is, since I get "TypeError: nodes[i].parentNode.href is undefined" and "TypeError: $mainmenu.parent(...).get(...) is undefined" errors on both Pale Moon and LibreWolf. Which is part of Shadow/DOM, and originated from google (https://hacks.mozilla.org/2015/06/the-state-of-web-components/). Not sure when this particular thing was introduced, since it's a "living standard"/experimental feature (https://dom.spec.whatwg.org/).
-
That people produce HTML with string templates is telling us something
JSX chose to align names to the DOM spec [0]. Same for htmlFor and friends.
[0] https://dom.spec.whatwg.org/#ref-for-dom-element-classname%E...
-
Notback BETA - A new PHP frontend framework
You can see why I say this here: https://dom.spec.whatwg.org
-
Understanding the Benefits of "Quirky" Web Languages
The product logos in this article's cover image include different languages and technologies some of which are still relevant for web development today: HTML, CSS, JavaScript / ES / TypeScript (and the DOM), SVG, PDF, PHP, SQL (mySQL, MariaDB), mongoDB, Node.js (the most successful server-side implementation of JavaScript so far).
-
Declarative Shadow DOM
Thanks for the shout-out! I think I mention this in the talk, but note that YMMV. I designed that benchmark as a kind of "worst-case scenario" where shadow DOM / scoped styles really show a benefit. Depending on your CSS rules, DOM size, and amount of thrashing, the perf benefit could be small to large.
Also, it's still possible to shoot yourself in the foot, especially if you have a large/complex stylesheet repeated across multiple shadow roots. (Not because of the repetition – that's optimized in browsers [1] – but rather because of the number of DOM nodes affected.)
That said, I still think the perf benefits of shadow DOM have been undersung. And Declarative Shadow DOM makes it way more useful.
[1]: https://github.com/whatwg/dom/issues/831#issuecomment-585489...
-
HTML DOM ️loves Javascript! 💕 #TLA 😘
We luh-luh-luv you! They gestated and nurtured the spec. They fought over bike sheds! All for us!!
What are some alternatives?
htmlgo - A library for writing type-safe HTML in Golang
extension-manager - A utility for browsing and installing GNOME Shell Extensions.
litestar - Production-ready, Light, Flexible and Extensible ASGI API framework | Effortlessly Build Performant APIs
brutal - 🏢 An operating system inspired by brutalist design that combines the ideals of UNIX from the 1970s with modern technology and engineering
literal-html - Simple and unsafe HTML/XML templates for TypeScript, using tagged template literals
hyperHTML - A Fast & Light Virtual DOM Alternative
template - A simple framework for webapps
epiphany - Read-only mirror of https://gitlab.gnome.org/GNOME/epiphany
rum - Simple, decomplected, isomorphic HTML UI library for Clojure and ClojureScript
webcomponents - Web Components specifications
typedef
WHATWG HTML Standard - HTML Standard
