wagtail.io, a Django/Python CMS, lists NASA as one of its users ... but is not mentioned in the article. The article says the migration was from Drupal to WP. Was that just fake news on wagtail.io?
> wagtail.io, a Django/Python CMS, lists NASA as one of its users
I can't speak about wagtail.io specifically, but a lot of "used by..." sections on websites are based on email signups.
For example, if I run a SaaS and someone @nasa.gov signs up to try it out, I can then list NASA as one of my users, even if they just tested it and never put it into production.
And lose respect from anyone with an inking of common sense. Nobody cares about who you’ve demoed your software to. People care about who is using it. Marketing like this and the people that choose to do it are the absolute worst.
I use a Google Sheet as it can be accessed from anywhere. Even my non-techie business folks can make changes (they feel at home in spreadsheets). I even added a menu button to the gsheet to launch a re-build (it is a static site on Netlify; the build fetches it's config/data from the gsheet).
And now the LavaWash server could be hacked to steal user data that a washing machine would never need, but the implementer chose to store without reasonable protection.
If you are developing a large JS codebase then Typescript is probably a good idea. But the Hypermedia movement, including htmx, is saying don't build large JS codebases! If you send JSON down the wire then you need a large JS codebase to handle it. So don't send JSON down the wire! Send HTML instead, full pages or fragments as appropriate.
That's the whole point. Those "restful API backend services" are not really REST-ful. The essay, "How Did Rest Come To Mean The Opposite of REST"[0], explains this better than I ever could in a HN post. Maybe we should stop growing these Data-APIs (returning JSON) and switch back to Hypermedia-APIs (returning HTML).
it might not be the right REST, the key point though, is that it's json data instead of html, which asks you do client side rendering instead of server side rendering.
htmx might be great for server side rendering, but for client-side-rendering(SPA) which consumes json data from the backend, I doubt htmx is a good fit, and there are lots of json-api-service(instead of html) these days for client to consume.
The code is not done yet but I can explain how we're going to use htmx and Hypermedia APIs for the static site of a national chess federation (it's static to avoid hacking/ddos from disgruntled russians). Every week, new chess ratings are calculated from the reports of in-person / over-the-board tournaments. At build-time (Hugo/Netlify), a static HTML fragment is created for each member and included in the site's static files. At run-time, when a member's info is requested, htmx will fetch the member's HTML fragment and insert it into the appropriate <div>. At run-time, there is no server-side code executing nor database so it's fast, highly available, and almost unhackable.
hyperscript is a separate project. It is not a feature of htmx. htmx handles the hypermedia interactions with the back-end server. For pure in-page interactivity (hiding/showing side-navs, etc), you get to decide how you want to do it: VanillaJS, AlpineJS (my favourite), hyperscript, Web Components (lit.dev, etc), StimulusJS (what you used), a big framework component (Svelte, Vue, React, ...), etc, etc. htmx does not bundle anything into itself to make that decision for you. You may have thought hyperscript is a feature of htmx because sometimes you'll see the two used in examples (both have the same creator).
