hasanhaja

In a similar vein, I've been really enjoying the Go + Datastar combo with Templ.

> even more secure

Based on what? Happy to be wrong, but the quote in my reply was Apple's stance on the WebKit vs native iOS apps

How did you determine the weighting for your scores?

If it's about security and privacy, why push more people away from the Web to native apps that they know is less secure [1][2]?

> WebKit’s sandbox profile on iOS is orders of magnitude more stringent than the sandbox for native iOS apps.

[1] https://assets.publishing.service.gov.uk/media/62277271d3bf7... [2] https://open-web-advocacy.org/apple-dma-review

The problem is that it has to use the WebKit rendering engine, and not that it happens to.

I think it's more insulting to browser vendors that they have to throw away their browser engines to appease the monopolistic tendencies of one company.

They don't need to implement it though. They just need to unban browser vendors from shipping their own engines.

I don't think it does benefit the open web. If consumers can't get value from the web, they'll go where they can find it. That is currently native apps, which is a closed and proprietary ecosystem. This causes the market itself to shrink, which means fewer and fewer people will invest in the web [1].

Here's a good podcast episode with people from the Open Web Advocacy: https://changelog.com/jsparty/316

> I do, frankly, think that mobile Safari couldn't compete that well in an open market, just like desktop Firefox can't.

Couldn't compete isn't a justification to exploit platform control and ban competition. If Apple's so worried that Safari usage will fall off in favor of Chrome, then they can invest in Safari to make it a level playing field to keep their user base.

[1] https://infrequently.org/2023/02/the-market-for-lemons/

I think malicious compliance is a fair interpretation of the situation: https://open-web-advocacy.org/blog/apples-browser-engine-ban...

It's hard to understand the privilege bubble you're in unless you actively try to live like your users. My read of the current trend [1] is that building for your marginal users isn't prioritized culturally in orgs or within engineering. Unseating those ways of working in my experience has been immensely challenging, even when everyone can agree on methodologies to put users first in theory [2].

[1] https://infrequently.org/2025/11/performance-inequality-gap-... [2] https://crukorg.github.io/engineering-guidebook/docs/fronten...

Thank you so much for the write up! I've been avoiding processes for some reason while I've been learning Elixir and this post pushed me to play with it today. And I started in Erlang and then managed to translate it to Elixir successfully!

I ran into this issue and I'm not sure if it's just a me thing.

When sending the message from the Pong REPL, the following didn't work for me:

```erl {ping, 'ping@localhost'} ! {pong, self()}. ```

When I checked, the PID of `self()` is different to the PID of the registered `pong` process. I needed to change it to the following:

```erl {ping, 'ping@localhost'} ! {pong, whereis(pong)}. ```

This sends the correct PID to the Ping process and we have an infinite loop counting up.

Maybe the versioning should be powers of 2

Why have a call-to-action to something they don't want you to do?

It's only there for Pro users and people who want to support the project [1] and not normal use.

[1] https://data-star.dev/essays/greedy_developer

Use the Navigator API directly then? Why do _need_ a declarative version of it?

I'm confused. Datastar is a free open source framework that you can choose to use or not.

It's weird to call them out as indecent and deceitful for not actively marketing features that they really don't think you need. Even when you think you need it, they've actively encouraged people to analyze their problems to identify if it's a real need or a gap in hypermedia fundamentals knowledge.

Also, the top nav has a Pro page that has what you're looking for.

If an enterprise won't want to pay for the product, what makes you think they're more likely pay for support?

If you're implying they'll only pay when they've seen the value of the product, then the non-pro part of the framework is incredibly feature-rich and can easily do that.

This feels incredibly unfair and harsh and is completely unfounded. What's the scam here?

Fair enough! That's up to you

If the core of the framework fits what you need, you could write those additional plugins yourself, rather than relying on the official "pro" ones. My understanding so far is the plugin architecture is intentionally designed for this usecase, so you aren't beholden to the official maintainers to add/tweak features for your specific usecase.

This makes the investment in the tool a lot safer, because you can always swap out pieces that don't fit your usecase, rather than start from scratch with a new framework.

In an enterprise setting, I don't believe the cost alone will be the factor that drives the decision. It'd be weighing up the value of the framework (e.g., UI framework/programming language agnostic stack, simpler architectures, delivery speed, performance, cost of using the framework on users) against the license cost.

> Getting enterprise adoption of a front end framework is almost impossible outside of React, let alone paying for a niche one, and the "contact us" approach is a non-starter.

Two questions on this:

1. Why do you think it's impossible to get org buy-in? 2. Why do those same orgs pick frameworks like Next.js, whose full benefits can only be realized with sophisticated and paid infrastructure?

> They aren't. This is not good API design

Why isn't it a good API design?

> Snide vaguely dismissive remarks don't make such remarks true.

Agreed! I don't believe I was doing anything of the sort.

> Who's us?

People on this thread.

Which feature are you referring to?

I can see what you're saying.

But again, the API design woes are subjective and I think it's perfectly fine to iterate on getting this to a nicer state.

"Wrong" to me suggests a gap in the understanding of fundamentals or of how things work. If the ideas of Datastar are fine to all of us, and our issues with it are ergnomics, then that can be a more focused discussion.

Simple features? Making those imperative APIs declarative is not very simple for me, but you're welcome to not use those features and write them yourself.

A couple of things on the Phoenix point:

- Requires the adoption of Elixir and Datastar is backend agnostic - Adopting Phoenix feels more suited to greenfield projects, but Datastar is suited for that and brownfield ones. - Websockets vs Server Sent Events has been really interesting and nuanced

I don't think that's a fair read of their intentions given how they talk about it everywhere [1]. Pro isn't there to paywall great features, but there to support the development of complex and annoying ones. The example of `data-on-signal-patch` that moved from pro to core speaks to how they're thinking about the project.

[1] Time-stamped it for convenience: https://youtu.be/eMIB4Bkl08U?si=IfTslvZoGXVbou0w&t=1270

Isn't that the whole point of hypermedia frameworks like Datastar and HTMX? It's to extend the declarativeness of HTML.

If you don't like the syntax, that's your preference. But I'm curious to hear why this is "wrong". Since that's a more objective thing, we can discuss it

The type-safety concern would be to do with your templating tool, right? It doesn't have anything to do with Datastar

What's your concern with the paid features?

https://news.ycombinator.com/item?id=45537335

Wanted to include that this is so the development and maintenance of Datastar as a project is sustainable. And that they are a registered 501(c)(3) nonprofit organization.

https://data-star.dev/star_federation#nonprofit-organization

I've been having fun exploring this actually: https://news.ycombinator.com/item?id=45333494

I've found it to be a fun way to build apps.

I've only started playing with local first recently to learn the Service Worker API and IndexedDB, and I'm looking forward to learning about CRDTs more. Here's a little todo app that I built:

[1] GitHub: https://github.com/hasanhaja/tasks-app/ [2] Deployed site: https://tasks.hasanhaja.com/

Syntactical preferences are subjective though and are prone to familiarity bias. I started my webdev career with React so I'm really familiar with JSX and like it, but that alone isn't enough to make engineering decisions.

I think semantics could be a more objective way to assess the DX of frameworks because you can have/add a syntactic layer on top that suits your preferences [1]. Semantics would be things like rules of hooks, footguns of `useEffect`, component level reactivity rather than fine-grained reactivity, etc. The high level outcome of this would be being able to answer the following question:

"How likely is it that this framework will put me in the pit of success with minimal overhead?"

[1] https://vuejs.org/guide/extras/render-function.html#jsx-tsx

Great article! The thing I find most frustrating in the "winning by momentum not merit" place we're in, is that the merits aren't just technical. Frameworks like Svelte are simpler to understand and keep in your head, which I think leads to reduced maintenance and scaling burden because you don't have to think about it the React-way to be able to do so.

Similar to the "Framework Evaluation Checklist" section, we wrote a "Choice Framework" where I work to think through your constraints by putting the users at the center of it:

https://crukorg.github.io/engineering-guidebook/docs/fronten...