I have been using Loop(https://github.com/MrKai77/Loop) after trying some of the alternatives listed here and wanted to post that as it was not mentioned. It is something that solves what I was looking for in window management on macos and just putting it out here :).
Like all the comments below, a show HN should have been the norm, but they knew that would not get any clicks and this.
However, I do not understand their pricing. If nordcraft's ppl are here, please tell me how does it work. For open source, you say there is a limit of 20k requests? . But I can always download the code/web-components and deploy anywhere I want right? Then even enterprise can do that? I do not understand it. Also it is Apache License 2.0. I can host it on my own cloud. Are there some restrictions if I do that?
Yes, AI was heavily used to develop the app—I experimented with different models and IDEs to speed things up. A separate blog post might be coming out soon to dive into those details. Overall, I used claude the most and the final IDE was Kiro.
I just downloaded on mac M4 pro mini. I installed the apple silicon version and try to launch it and it fails. No error message or anything. Just the icon keep bouncing on the dock. I assumed it needs some privacy and screen recording and audio permissions and explicitly gave them, however still just jumps on the dock and the app does not open. (OS, mac sequoia 15.5)
I would want to share my pngs or screenshots and generate the mockups rather than using something that I have not designed or my app will have.So suggestion is to take an image and then build a mockup from that maybe.
Nice, I am in the process of building one with a similar concept but in a single HTML/JS file. Sharing with friends and multi-user. Might release it in a week or two as I am getting closer to put final finishing touches. Not sure if I have to go open source or closed and Freemium. Might ask HN later :)
I'm more familiar with htmx than alpine (TIL!), although I've never used either one. I have read the excellent HyperMedia Systems book though, and I was nodding my head the entire time.
I think the main differences between these projects is in their goals and their opinions about JavaScript.
HyperTemplates is a templating system first, and static site generator second. I have built a templating system for building and composing HTML layouts [1] [2], and a tool that combines the templating system with a lightweight, file-based CMS [3] to construct entire websites. HyperTemplates doesn't have any opinions about how to incorporate JavaScript into a website other than it's hyper-focus (see what I did there?) on HTML, which makes it compatible with literally any Javascript tooling you might want to layer on top of it - including the excellent HTMX.
I won't pretend to be an expert on HTMX just from reading their book (and watching a few videos), but I think their website does a good job of explaining that the goal is to extend the capabilities of HTML by exposing some commonly used Javascript functionality as HTML attributes (e.g. AJAX, CSS transitions, websockets, and server sent events). Where HyperTemplates and HTMX might appear the most similar is in that both are designed to work with HTML fragments (e.g. HTML files with a single layout component), but HyperTemplates "includes" those fragments during static site builds, and the default HTMX approach is to fetch them client-side (requiring the appropriate cautions about XSS [4]). I think the best evidence that HyperTemplates and HTMX are more complimentary than competitive is in the fact that the htmx.org website isn't built using only htmx, some static HTML files, and some markdown for content. It uses a static site generator called Zola [5], which uses a templating engine called Tera [6] that is itself not purely HTML. I haven't tried this myself since I have reached for HTML Web Components for my JS needs, but I would guess that using HyperTemplates for low level templating and static site generation with HTMX for further extending HTML functionality would be a fantastic authoring experience.
I'm the least familiar with Alpine, but I like that the author is also named Caleb! Maybe the Calebs are meant to build things for the web? I digress... At first glance the alpine attributes appear very similarly "DOM scripting" oriented, like HyperTemplates, but it describes itself as "jQuery for the modern web" which is directionally a different goal than HyperTemplates. The Alpine Templating documentation [7] highlights that, like HTMX, Alpine's DOM manipulation happens client side as opposed to prerendering the HTML, so it has to warn about XSS vulns [8] as a result. From there Alpine looks like it would appeal to JavaScript junkies – and I'm not using that in the pejorative sense because I love JavaScript! But the Alpine templating examples look like most JS framework examples in that they are full of <div>s and mostly ignore the existence of built-in HTML elements and their implicit meaning; although I'm sure Alpine could be compatible with a more semantic approach. I'm also not understanding how the x-data attribute, Alpine.data() method, and Alpine.store() are meant to work. Is the actual content of a page meant to be embedded in the layout, as shown in most of the examples? I must be missing something obvious RE: the CMS workflow, as I would expect the ability to separate layouts and their contents (church and state). Ultimately I think the emphasis on reactivity (see: State [9], and Events [10]), and the focus of the "Start Here" guide [11] on components and not websites highlights that the goals of Alpine and HyperTemplates are very different. Between these three tools, Alpine feels the most opinionated about JavaScript since it encourages you to embed JSON in HTML attributes and inline some JavaScript in your components/layouts.
This is obviously a biased analysis, but I hope it helps. I'm just about the furthest thing you can find from an expert on HTMX and Alpine, so take my comments with a few lumps of salt (and by consulting the linked docs). But I am grateful for your question since it forced me to write some words about this topic which has been floating around in the back of my mind. I suspect I'll need to turn these notes into a blog post at some point.
Finally, with regards to your question about forms, HyperTemplates lets you create reusable form components (HTML fragments) that you can compose layouts from, and then hydrate form element attributes from template data [12] in Markdown, YAML, or JSON format. And HyperTemplates can template HTML element attributes [13], so it can be used to customize <form> element attributes [14] (including global attributes [15] and data attributes [16]). But HyperTemplates sole focus is on the HTML templating, so it doesn't assert any opinions beyond whats available via the HTML form attributes. This again highlights how HyperTemplates is more complementary to something like HTMX than competitive. Again, the answer is in the goals and the #1 motivation for HTMX is "Why should only <a> & <form> be able to make HTTP requests?", so it naturally has more opinions about forms [17].
