I see this as oversimplification. US Tech faces hard regulations too (fintech, healthcare etc...). Also Regulation is not that big of a bump in EU. GDPR simplified rules across 27 different national laws and forced new innovations in privacy.
Also Spotify, SAP, Adyen all started in small markets, as counterexamples.
The main reasons why USA is ahead I think are the historical advantages (internet, personal computer), the network effects created by the historical advantages and the VC ecosystem. Also the culture for risk tolerance.
Regulation may or may not be that much worse in the EU, but if there are 27 different countries, it adds a lot of uncertainty and legal work as you roll out to each one. GDPR wasn't written until tech winners were already called.
The VC system and network grew out of this existing development in America (of course the capital markets have been there since before tech, as I mentioned). The banking and finance system grew in America for the same reason - a large single-regulator market.
Spotify is basically a US company today - They have huge US offices, and their US subscribers are crucial. It's also a perfect example of a business that doesn't follow the high-fixed-cost-low-ongoing-cost model. They have to pay a license fee for every stream, so they can't amortize their costs across users nearly as well.
SAP is another example of a business that doesn't amortize as well across users - their product is very bespoke per company, and negotiated individually.
Humans experience the world as a story, but that is not necessarily the most human way to wrap a life around as you are implying. In some cases there are more powerful frameworks. For example Hitler is wrapped (by most of the world at least) around the damage and pain he caused not around his story.
Stories are mostly fine, but thinking that we should strive for that to being the main perspective is limiting.
> In Vue you can just change a property deep inside the model layer and the view updates
I never used vue for production apps, but my feeling tells me this could be a problem when the app becomes big.
If you change a prop deep inside the model layer the chances of triggering an unintentional view update are higher? By using setters, you're essentially creating a more structured and controlled way of updating your application's state. But I have the react googles on, maybe I am missing something :)
The two binding happens in context of forms and user editable fields only. So, it is actually mirroring real world of a value can be changed from two different sources I.e. HTML and javascript.
Once you are in js land, changes occur in one direction only, I.e. from parent to child. Child cannot update parent directly via two way binding. Child need to emit an event. This brings vue in line with react to issues and semantics.
Ok then the parent is talking about those situations (forms and user editable fields) not about state in general in the library, correct ? If that’s the case, weird comparison.
A lot of People in “colder” countries with higher purchasing power (specially in Europe) still want to move to Barcelona now that they can work remotely. I wonder how this fact affects the prices compared to tourism apartments.
> A lot of People in “colder” countries with higher purchasing power (specially in Europe) still want to move to Barcelona now that they can work remotely.
That's less and less true. And of those who actually moved to Barcelona, some already left (and companies too) when the independentists started being openly hostile to anything non-catalan.
Why someone with the means to do what is called "geographical arbitrage" would pick Barcelona is totally beyond me.
That sounds a lot like all the homeowners in California that have sold their significantly overvalued homes for 7 figures to move to states where real estate is a fraction of the cost. Generally it’s considered to be a factor in home price inflation in those cheaper states.
I honestly don’t understand how’s this different from react server components with nextjs but with less features? It seems like the same thing but with an even clearer border between server/client components and therefore missing all the optimizations (like streaming). Like islands architecture but made out of different technologies, is my understanding correct ? I would appreciate some feedback :)
LiveView has streaming. I would argue that if you're stuck in the React way of thinking about application design then it's not worth trying to sell you on what LiveView is doing. But there are multiple case studies out there showing that it results in far less build times than React for no compromise on user experience.
Yeah I wish this article had covered how this solution compares to React Server Components as it kind of looks like spaghetti of different techs compared to how next.js streamlines the same problem space into one consistent mental model.
It looks like a shorter and more specific syntax for things you can already do with vanilla stuff. In theory more tricky but faster to develop for one person (something like tailwind for JS). I find tailwind makes me develop faster than css but is a bit more tricky to get started on existing tailwind components than in just CSS components.
Maybe something like a distributed DB where each different browser is a DB to sync with the other Browsers/Db’s ? I know this can be achievable with Tauri (a standalone app) and gunjs in a relatively straightforward way
This looks very nice !
How would you compare it with slatejs, tiptap or lexical ? Is this only for layouts but not for content ? (Would it be very hard to include some rich text and make it work like a cms with rich text editing?)
Thanks! It’s possibly I’m misunderstanding, but I believe Puck is a different problem space to the other solutions you’ve mentioned -
Puck enables content teams to produce web pages using existing React components produced by their React developers in a fixed and predictable manor that keeps them within the brand guidelines.
You can’t inject arbitrary blocks and can only interact with components that are defined by your developers.
You can render fully fledged pages or even, in theory, applications.
Regarding content, Puck supports inline editing or pulling in data via an API adaptor (such as from a headless CMS).
I think by "widespread use" he means the reach of the AI System. Dangerous analogy but just to get the idea across: In the same way there is higher tax rates to higher incomes, you should increase regulations in relation to how many people could be potentially affected by the AI system. E.G a Startup with 10 daily users should not be in the same regulation bracket as google. If google deploys an AI it will reach Billions of people compared to 10. This would require a certain level of transparency from companies to get something like an "AI License type" which is pretty reasonable given the dangers of AI (the pragmatic ones not the DOOMsday ones)
But the "reach" is _not_ just a function of how many users the company has, it's also what they do with it. If you have only one user who generates convincing misinformation that they share on social media, the reach may be large even if your user-base is tiny. Or your new voice-cloning model is used by a single user to make a large volume of fake hostage proof-of-life recordings. The problem, and the reason for guardrails (whether regulatory or otherwise), is that you don't know what your users will do with your new tech, even if there's only a small number of them.
I think this gets at what I meant by "widespread use" - if the results of the AI are being put out into the world (outside of, say, a white paper), that's something that should be subject to scrutiny, even if only one person is using the AI to generate those results.
