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.
I agree with the sentiment in a sprint basis. But after 20-30 (hopefully less) sprints some patterns start to emerge out of the metrics and some consistency builds up in the team or teams (because every team is more or less an atomic unit, so it sort of “scales”). Those are imo the real advantages. You could say that there are other methods with which you can gather patterns, build up consistency and scale an organization but I don’t know of any method as straightforward and simple (although very faulty) as agile.
In a startup with 3-4 people is obviously most of the time not a good idea to stick to all agile rituals, but even in a small organization there are things to mimic from agile processes.
Last year I wrote a comparison between Sveltekit and React with focus on Typescript and Graphql. What I didn't like particularly was that for-loops had no type inference [1]. Until this changes there is no reason for me to use Sveltekit in big projects. Typesafety is very important and nothing beats react on that.
Recoil for single page apps. As simple as context but more readable. For another app the url was used as a single source of truth, so kind of a global state. The components just called useQueryParams.
For multi page apps (e.g. with nextjs) I’ve never used a global state manager. Next-auth, useReducer and react query are enough until now.
It probably targets developers that learned web development while learning React. It is at least a good idea for them. I think jsx-email wants to be the jsx version of mjml.
Or anyone who wants a tempting system or anyone who wants to conditionally render html esp in a templating system they already use, integrated with components and libraries they already have defined.
It works around the limitations by introducing custom components that are widely supported by multiple email clients[0]. Currently only 3: Button, Group and Image. It solves at least that and it seems to be scalable to build more components. In my opinion JSX is a great template language, I'm happy to use that abstraction, even though the setup is a bit annoying.
