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.
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].
> 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.
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].
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:
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.
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?
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
Based on what? Happy to be wrong, but the quote in my reply was Apple's stance on the WebKit vs native iOS apps