Before I went European sovereign for my own personal stack I used Cloudflare for hosting static and somewhat dynamic websites and it has become really nice the later years. There is almost no mention of "regions" in Cloudflare. Your content and code runs globally by default. With traditional clouds you need to think about how you distribute your application. At least that is my experience. Maybe they provide global CDN for global distribution of static content. But serverless containers and databases more or less run in a single region by default. And if you wish to distribute stuff it is on you to plan the architecture behind that.
Now stuff like Cloudflare D1, the distributed SQLite based database, have its limitations. Writes are directed to a specific datacenter/region behind the scenes, so some regions might get slower writes. But this is basically something that happens behind the scenes and just works. You need to think about where your primary base of customers live when you create the database, after that you don't think about regions. R2 (S3 compatible storage) just works globally as well.
A lot of what Cloudflare offers now feels like magic in a good way. I realize they don't have everything AWS, Google Cloud and Azure have. But they have enough that you can build serious systems on top of their infrastructure. They are no longer just a CDN/proxy provider. And their offering is seriously cheap.
Currently I don’t use any CDN. I just host everything on Scaleway on VMs and serverless. Works pretty well for my use, but I imagine latency is bad for South Americans. I’ve looked into Bunny and I think that is the closest you get to Cloudflare’s offerings.
One of my best experiences in Prague back around 2010 was when I had no Google Maps, tried navigating with a hotel pamphlet map, and promptly lost my way towards the student culture house I was trying to find.
Ended up asking some locals where I was, and amused they assured me I was way outside the map and had gone east instead of north. I did not want to backtrack so I asked if there was any nice places to get a beer nearby and they pointed me towards a beer garden. Those were some of the nicest Pilsner Urquells and Staropramens I had during my visit. No tourists to be seen, and good vibes all around.
Nowadays I mostly navigate with GPS and rarely just happen on random places like that. I guess we lose some of the discovery when you always know where you are going.
I was hiking one time and did have a guidebook. Things didn't look quite right but I did convince myself I was on the right track. (This was pre-GPS.) Eventually I ended up in someone's backyard. Fortunately there was (obviously) a road there and I figured out I had gone the wrong direction from the trailhead. (I think it was the Appalachian Trail.)
You might already know and used "for some reason" as sarcasm. For those that do not: Zoom did the usual aqui-hire. They needed to show their enterprise customers they were taking e2e encryption seriously, so they bought out the guys who did exactly that kind of encryption with Keybase.
A shame really, because Keybase was kind of unique in the way the facilitated social proof of identity tied to cryptographic keys. A shame though that they never found a really sustainable business model. When they turned to crypto currency towards the end of their independent run I knew it probably wouldn't last.
the UX was so terrible that it was inevitable it won't stick. It was clunky and alien on every productivity platform, I attempted to work in a team leveraging it, and it was painful on windows and macos alike.
I just deleted it as I noticed it was responsible of about 30% of active cpu (and battery drain) usage on my mac, while being logged out due to inactivity. Honestly: I never particularly liked it, and I could not feel the concept especially tempting, just went with the team.
I think HTMX is a great fit for forum software. Forum websites mostly deliver non-interactive content in the form of text and maybe some audio, video, or image content. All of this can be represented as HTML and CSS.
With HTMX you can do partial rendering and live updates via server-sent events. This gets you most of the way to the "client side" feel where things load dynamically based on user actions.
The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.
> Forum websites mostly deliver non-interactive content
I'd say that "Endless Scroll" is a good example of something that is... well maybe not interactive but still breaks the "just an HTML document" page metaphor that plays nice with such things.
Now, personally I find the UI compromises it takes to make endless scrolling happen are abhorrent (like not being able to ctrl-F or export the page content). But other people obviously like them.
Is that the kind of thing you'd be giving up as you move to a platform like HTMX?
It also doesn't actually work correctly - if you scroll too quickly it doesn't load more content. Possibly just a CSS issue on the example because the last row is not visible when scrolled to the bottom of the page due to the footer and its large margin.
Infinite scroll is not a good tool for his use-case. Users will filter and then try to Cmd-F. They will get annoyed if you can’t search. It’s just bad UX. You can use infinite scroll for things like Twitter feed. Product search is just a different kind of UI.
Well I also do not really know the legitimate use case for infinite scroll (other than trying to push gambling/slot-machine tricks onto your userbase).
I get lazy-loading for pages that contain a ton of media of which the user will likely only see a fraction. But some people seem to think infinite scroll is a good idea with text based content as well..
Where you can put comments on problematic lines/blocks of code easily with the git command... (Please continue, I'm really curious of there are better ways than what I'm currently doing)
I first learned about endless scroll in a Ruby on Rails meetup, where the presenter was showing how to craft snippets of HTML with ERB and using a bit of JS to insert them below the existing entries. It's definitely possible.
Maintaining a code path with a snippet for each possible viewing experience, back when REST was all the rage, was a bit obnoxious though.
Yes but then you're doing HTMX not HTML and at that point why not use something that's more flexible. I'm saying this as a person who still maintains a small application done with Intercooler.js and is perfectly happy with it.
If you want basic interactivity, HTMX is fine.
If you want something more (like sortable) I'd reach for lit instead of adding the Sortable.js dependency, something the HTMX docs suggest ( https://htmx.org/examples/sortable/ )
And yes there are also some scenarios that you want to control the whole routing and rendering stuff, then go for Solid, React, Angular, Vue, whatever.
There is no golden rule to all of this but finding out what makes sense is a fun exercise.
I don't necessarily disagree that there comes a point at which you are working more against HTMX than with it. I think rather than measuring that contention point between HTMX and SPA/MPA in terms of interactivity I'd measure it in the amount of client side state and logic needed. If you need a bunch of client side state and logic, for example a digital audio workstation, then a SPA would definitely be the appropriate pattern.
But interactivity in largely content-driven sites doesn't necessarily preclude HTMX. You can do a bunch of fancy interactive stuff with HTMX and some minimal JS. Drag and drop sort is a tiny drop-in JS snippet. Skeleton loaders and spinners are supported out of the box in HTMX as is infinite scroll as others pointed out.
I'm not saying Next.js, Solid Start, Remix, Nuxt or some other hybrid server and client rendered model doesn't work for forum software. Or that even client only rendering can be a valid approach if you accept the trade-offs (no curl-ability). People should use whatever they feel productive building with.
But if your backend is already a non-JavaScript server rendered framework like Django then HTMX makes a ton of sense to add some interactivity.
I personally think that if you are adding a sortable component to a content-driven website, maybe it is moving away from being such a website. Normally a textarea should be enough for most people to order a "list" but if the list items have ids (they are entities), then that'd not suffice, and you may be going in the direction of a web application.
Otherwise, I'd recommend HMTX even if you have a super flexible JS backend.
That said, this is all baseless thinking without seeing any requirements and as I said before, trying to choose the right abstraction is the hard but fun part.
Indeed. In a publishing (Wordpress) like solution maybe you would use HTMX for the user facing parts and React or something similar for the more interactive admin parts. Then you don't need to bother with server side rendering for the admin bits, which at least I think simplifies React a great deal. It's not that the JS fullstack frameworks doesn't handle server side rendering and routing for you, but they feel very much like black box magic to me. Especially the new fangled React Server Components with the whole serialization and streaming model.
Good old server side rendering is simple in Rich Hickey's "Simple Made Easy" way. You can build more complex logic on top of a standard server rendered model, but the base model is mostly dead simple to reason about. I like that. I've built web "apps" in AngularJS, React, Reagent (ClojureScript) and Next. So I'm not coming at this from a grumpy "backender" position. I'm coming at this from having done lots of frontend stuff and finding the frameworks becoming increasingly complex beneath the surface. It feels like they are targeting the "easy" in Rich Hickeys parlance in the sense that you don't have to write a lot of code to make something fancy. But reasoning about the behavior and what actually happens in the framework when something doesn't work is increasingly difficult.
Edit: And maybe this is a "skill issue". If you just learn the framework and library well enough you'll get by much better. But I tend to not want to bind myself to any single framework too much. So simple frameworks that don't churn too much is better for me.
> The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.
That's how interactivity has always worked.
Server-side render everything + ship interactivity via js on top of it.
I feel like most of the web developers forgot that React/Vue/etc solve a specific problem: single-page application.
This is a very narrow and specific problem: navigating from page to page not causing full page reloads.
But the web has changed since SPAs were needed in major ways:
1. the average device and connection is insanely faster than 10-15 years ago. Receiving and rendering content is not the problem it once was in the age of 2g connections and limited hardware mobile devices. Even the very low end phone from few years ago has nowadays 0 problems loading and parsing few hundred kbs of html and js.
2. Web technologies moved at all levels. Server technologies, cloud ones, browser ones. React and company are solving problems that barely belong to the modern web.
In short: today you can have an app-like, spa-like experience even out of fully server-side rendered applications. While also benefitting from shipping much less code to the client.
There's a very minimal amount of websites and applications out there that benefit, and aren't crippled by these rendering libraries: those that vastly leverage offline capabilities of the platform and want to keep working regardless of internet being available. I'm talking the notions and linears.
But bar from those, still working with this React slop is just not good for the user. Even multi billion companies hiring leetcode ninjas can't get acceptable user experience and performance out of those libraries, and it's not a coincidence: they keep forcing the wrong tool for the wrong problem.
They keep living in 2018 and at the end of the day the only excuse for those react/angular+tailwind slop is that there's an entire generation of developers that doesn't know anything else and has long lost any proper engineering skill (if there is any) in finding the right tool for the problem. This is a familiarity issue, not sound technical decisions. It's the "you can't go wrong with oracle/mysql/ibm", but actually you can, and it shows.
What's worse: it's incredibly cheap to experiment different solutions and approaches via LLMs in 2026, but people keep slopping the same monstrosities.
> the average device and connection is insanely faster than 10-15 years ago
Using the same reasoning, I’d come to the opposite conclusion. Devices are much faster than they were 10-15 years ago, but network latency is still roughly the same because physics limits how much it can improve. So reducing network round trips matters more than ever, which favors SPAs over MPAs.
But a lot of the time they can happen in the background where the user doesn't see them, or on a part of the page the user isn't currently interacting with, preventing it from being a stop-the-world interruption.
It’s in the name: an MPA requires a page roundtrip for every navigation, while SPA requires a single page roundtrip. Any subsequent requests are part of the application itself and can be handled without disrupting UX.
An SPA still requires roundtrips, just not to load the DOM root. Most of them do more than one roundtrip per navigation, making them worse than MPA. They also break loading screens.
An MPA can make as many queries/service requests as it needs to to render the result. Most— the vast majority of SPAs I’ve ever written, maintained, or used— do that from the client, making many requests to render the new route.
The UX for an SPA can indeed be excellent, but the average SPA is worse than the average MPA, in my opinion. It’s just much easier to break things in many subtle ways in an SPA.
Is it really your experience that SPA data fetches and refreshes are "handled without disrupting UX"? I think it's the opposite. When a page is rendered on the server it's much less likely to move around under me, forcing accidental misclicks or shifting what I'm reading off-screen at random.
> React/Vue/etc solve a specific problem: single-page application
That's not true. They solve the problem of requiring separate code paths for interactive elements - one for initial render and another for updates.
Previously the server rendered the initial HTML and then client JS updated it after e.g. user clicks a button, but with React/Vue/etc., it's merged into one code path because HTML is derived from the current state.
> Even multi billion companies hiring leetcode ninjas can't get acceptable user experience
Modern UX is bad because many front-end programmers fundamentally just do not care about the UX, it's not about the specific tech they use.
> A Single-Page Application (SPA) is a web application or website that loads a single HTML page and dynamically updates its content as users interact with it, rather than loading entire new pages from the server.
That's the definition, I didn't made it up.
And those libraries solve that.
Your other definition, can be fully implemented server side, Elixir's Phoenix does that. But it's not the only one.
Your prior claim was that they only solve one problem, not about a definition. They solve several problems:
- less data can move over the wire compared to sending a full page every time (this is in your definition, and is definitely not always true, as sometimes REST APIs can return far more data than what's needed to render the screen)
- the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers
- you can write tests for your frontend, e.g. you can unit test components' behaviour and style in isolation
- the frontend can also work, or at least respond usefully to the user, when the network or the backend are not working
That second point is almost never true
" the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers"
In a reasonably complex application, each interface ends up needing its own shape of optimized APIs. Otherwise the clients become very complex munging/reshaping data or making too many API calls, throwing away a lot of data etc.
You said, that React/Vue/etc. solve a specific problem: SPAs - that's not accurate. That's not the problem they solve.
According to what you said, CSS also solves the problem of making an SPA because you could "switch pages" by changing CSS class names on `body`. But if someone asked what CSS is you're not gonna answer "you use CSS to make an SPA", even though _technically_ you can use it to make an SPA.
> Modern UX is bad because many front-end programmers fundamentally just do not care about the UX, it's not about the specific tech they use.
This is untrue and is weird misunderstanding on your part. Most of modern UX and UI is designed to fit the needs of the customer for the frontend team/dev: the product or marketing or sales department. The user of the website is very rarely the customer for the dev.
The point is that there's only one template and DOM is derived from that template. This concept is the same in both Vue, React and other popular component-based UI frameworks.
One nice thing about using React even on the web is that it forces your Backend to be REST right from the start. Although I sincerely thing that is less important now with the explosion of LLMs. I've started thinking about everything as Display + MCP Server. Where a SPA front end is really just pre-defined display.
I'm still considering whether to cancel or simply make do with 32GB memory. I initially ordered 64GB as I'd like to not worry about memory usage all that much. But getting the 32GB option for the original price (before price increase) seems like a reasonable solution to me. I can always upgrade later. I feel more sorry for those now bumped down from 32 to 16 GB. The latter is barely usable as an enthusiast dev PC these days.
It is unfortunate that Framework has sold priced pre-orders for batches they haven't secured supplier contracts for. Or maybe they did, but the supplier decided to void their contract releasing the same product for twice the amount. Hard to know what goes on inside these companies. In any case the AI bubble is doing a number on consumer market hardware.
I want to support Framework's mission, but this is a crappy situation all around. Definitely a mark on Framework's reputation, and also annoying for those who know need to dish out more money or not get the product they were promised at the price-point that was indicated at purchase.
As a former Clojure dev (now just using Clojure in my spare time) I love Babashka. Michiel Borkent really nailed it with sci (Small Clojure Interpreter) and Babashka. Running a custom Clojure interpreter in a GraalVM compiled Clojure app is quite clever.
Now there are of course limitations to what you can do in terms of not supporting Java reflection or the full Clojure compiler. But I've made some nifty small scripts and convenience helpers with it. And the dev experience of making these scripts is so much nicer than trying to write bash scripts. The Clojure edn syntax is super simple, and the REPL connected editor let me rapidly test parts of the code just like with full Clojure apps.
I don't have experience with other lisps, but I can vouch for Clojure being very nice. The community was welcoming and friendly to newcomers when I started learning, I hope it still is. One thing I love about the Clojure ecosystem and community is the effort taken to never break libraries. I've looked at libraries I used some ten years ago, and the API is still compatible with code I wrote back then. There is very little churn. Maybe this is because the language is largely untyped and editors only partially check "types". Having breakages in libraries you consume once every couple of months would get really tiring in Clojure land. I'd imagine the same problems would present themselves in Common Lisp and others.
I love the Clojure community, it is the only one that usually talks about the host platform in a symbiotic way, not as if they would be rewriting everything into their favourite language, like in most guest languages communities.
The PLC governance not having been moved yet is my one main gripe against ATProto/Atmosphere now. There is so much being built on top of this protocol, and I truly believe it has the chance to make the social web more decentralized while keeping everything connected. The PLC being controlled by one major commercial entity allows them to pull the plug so to speak. Say someone is sanctioned by the US, what stops Bluesky from pulling the plug on their DID thereby blocking and censoring this person from the network all together.
Half the point of ATProto is that identities are used across a host of apps, and therein lies a big vulnerability. If identities are not truly independent of centralized infrastructure, then you are vulnerable to losing access to a number of apps at once similar to Google services black hole if your Google account is banned (not to mentioned anywhere you've logged in with SSO).
It would be much better if the PLC was somehow decentralized itself. Barring that it should at least be finally spun out as the independent Swiss organization they've talked about for some time now. The organization could form a board with interested parties to set the future of PLC development if needed.
As for PDS migration, there are good options if you are migrating away from Bluesky. There are lots of GUI tools that work well now like https://pdsmoover.com/moover, Eurosky has https://move.eurosky.tech/, etc. It would be cool though if Bluesky actually linked to the other big PDS-providers on the Bluesky sign-up page to actually promote decentralization. But I guess it is hard to vouch for other services.
I still think the future of ATProto is bright, but there are definitely some obstacles before I'm comfortable with the whole setup. The network needs more decentralization in the PDS-layer, and the PLC needs to spin out in the separate governance organization pronto.
Did they actually create the org yet? I saw the news you are linking that they were going to start the process. But I've seen no follow up news about the organization actually being here and the ownership of the PLC directory having been transferred.
> Say someone is sanctioned by the US, what stops Bluesky from pulling the plug on their DID thereby blocking and censoring this person from the network all together.
How does IANA handle this with domain names? genuine question, i'm not sure. is it enough to have distinct registrars and distinct jurisdictions for some TLDs and so on?
They don't. All domains have US jurisdiction except the ones that are underneath country TLDs.
IANA could stop publishing country TLDs in their root zone file but it would probably split the internet in two, and everyone involved knows that. Several root server operators would refuse the update, and many recursive resolver operators would put them back in.
Indeed. Don't be dissuaded by Hacker News commenters. All the naysayers here doesn't seem to have published their own blog posts about how they built circular LCD clocks with Arduino ESP32 and low level programming or whatever they fancy as "good enough".
Browser based rendering that allows people to easily make new watch faces with JS and SVG is a perfectly reasonable platform for a nifty project like this. I think your watch faces look neat.
> I hope these folks manage to get a bunch of money and can fund the continued development for at least the next decade.
I believe VoidZero has been acquired by Cloudflare [1], so money should not be an issue. Question is if Cloudflare will be willing to continue letting these people work on Vite and Vite+ features that benefit all cloud platforms, not just Cloudflare.
Now stuff like Cloudflare D1, the distributed SQLite based database, have its limitations. Writes are directed to a specific datacenter/region behind the scenes, so some regions might get slower writes. But this is basically something that happens behind the scenes and just works. You need to think about where your primary base of customers live when you create the database, after that you don't think about regions. R2 (S3 compatible storage) just works globally as well.
A lot of what Cloudflare offers now feels like magic in a good way. I realize they don't have everything AWS, Google Cloud and Azure have. But they have enough that you can build serious systems on top of their infrastructure. They are no longer just a CDN/proxy provider. And their offering is seriously cheap.