I think you are mistaken. I remember landing upon that website some time before 2023 and being greatly impressed by that very 3D parallax effect. To my knowledge there were no AI tools available in 2022 capable of producing effects like that. There are barely now.
To my understanding it was made possible by another project of the same author [0] - check the date. Also check this [1] - dated 2003.
Is it so hard to accept that humans are more capable of doing intricate and impressive work than any LLM will ever be?
My apologies if this is a joke I’m not understanding, but as far as I can tell with the wayback machine, this animation predates not just coding/generative AI, but the Attention paper and the founding of OpenAI too.
It's like beating a dead horse. React is the literal worst of all the modern JavaScript frameworks and yet that's what everybody insists on using. Vue is light years ahead of it (and will be even further ahead when the new Vapor mode is released in 3.6). Svelte is ahead. Solid is ahead. Heck, even Marko is ahead.
Reacts added some poor abstractions over the last decade. Looking at you hooks and effects.
But its far from the worst.
It was the first framework to put together JSX, a functional way of defining components and simplifying state. This was a monumental improvement. As a result they earned mass adoption.
As a result its the framework that now has a community moat that is not going to crumble until someone else can break ground in the way they did.
Sure, some of these could be considered "better" but they're all better due to incremental improvements for Frontend Engineering.
None of which are substantial enough to unseat the king
I never "learned" react because the "create react app" would literally never install for me in the early days. There were literally so many dependencies I never got it to build as a novice, I tried svelte everything worked and I got to spend that time building.
I can only speak for Svelte, in Svelte 3/4 it was so dead simple that I built my first basic webapp with 0 javascript, css or html experience in 3 days.
By week 2 I was trying out different UI libraries and css frameworks, that part was super rough though, back then lots of compat issues.
Use Vite. It was a misstep by the React team to continue to recommend create-react-app long after it was deprecated, but Vite is what's commonly used today.
Vue should be a bit faster due to signals (updating state doesn't cause whole components to rerender), or at least require a bit less work to optimize (not as much need for useMemo, useEffect, etc. if everything uses signals). Other than that, it's mostly up to personal preference. SFC, directives, etc. are all just developer ergonomics, and people tend to prefer whatever they're most used to.
Also, vue interops better with webcomponents and non-framework code than React in my experience. Most non-React libraries need a React wrapper to work in a React project.
It can be made better if you write it using non standard patterns - but the community is so dogmatic you'll get laughed out of the room.
All of my personal react projects use the MVC/MVVM architecture and are so much easier to work with
export class AppViewModel {
@rx accessor message = new TextField()
}
export function App() {
const vm = useViewModel(AppViewModel)
return <div>
<p>{vm.message.value}</p>
<input
onChange={vm.message.fromEvent}
value={vm.message.value} />
<div>
}
Makes it vue/angular/svelte-like, but unlike Vue/Angular/Svelte, you pick the version of TypeScript, the tools and don't need brittle plugins for your IDE to work with it.
- Allows you to use async/await and generators (useful for pagination/infinite scroll)
- You can test the view model independently of the rendering logic
- Dramatically reduces the code that lives directly in the component (it's only TSX)
- Allows for better abstractions and state management (services)
- Clear path to leveraging threads in front end applications
- Simple "visual" components (like <Input />, <Button />) don't need view models, just orchestrating components.
In practice, when writing traditional React, I focus too much on rendering cycles and the nuances of managing component state while spending much less time on making the application look good and feel performant/nice to use.
Having a component be pretty much exclusively TSX gives me a clear separation of "view" and "what the view needs" - so I just think of the html structure and css. I tend to create much better looking and nicer applications this way.
> It's way more skipping around in the codebase to find the parts you actually care about
Not really. You cnt+click to an implementation. Say you have "await someApi.getItems()" - you just click and go directly there. Traditional React apps need to thunk with redux or have a bunch of custom hooks that quickly become a source of confusion.
As a Svelte developer working with React at $DAYJOB I must say it is the most horrific kludge of terrible abstractions I’ve ever had to suffer through in my life. The sheer number of hoops you have to jump through to do literally anything is comically absurd, and even the nicest way of doing things is a dumpster fire of bad programming patterns. The worst part is, React devs are blind to just how much of their day is spent solving problems that are created solely by React itself, unrelated to any business logic or actual value.
One day my dream is to delete 75% of the code, sprinkle some svelte into the business logic, and be left with a strictly superior, more performant version of the platform.
I could see this being useful for client and patient onboarding in the services and medial sectors respectively. For example:
A potential client providing information for a law-firm regarding their grievance.
A patient filling out the medical questionnaire prior to their first visit to a medical practice.
Rather than having a fully deterministic form, you'd be providing them with forms that adapt to their specific issue. The data can then be intelligently stored both as JSON and a more generic record in an RDBMS.
That can be achieved with 100% infallability with a form framework like FormKit. Why risk it, especially in a high-stakes situation like health? Pretty sure it would actually be against some kind of regulation to do that specifically in the healthcare field.
It depends on whether your API provider is HIPAA compliant and what sort of disclosures are provided. If you're running inference in house then it's not an issue provided you're following all the other guidelines.
With FormKit you'd still be using a predefined deterministic flow where all the conditionals are accounted for in advance. FormKit wouldn't be able to generate a truly non-deterministic UI that changes based upon how the user answers. If you're wanting to sue your neighbor for their tree falling onto your house, an AI powered UI for a law firm could be giving you form fields on what type of tree it was, how old the tree was, hot tall the tree was, how close it was to the property line, and what room in your house the tree landed in... All generated from how the user responded to an initial "what's your grievance?" question.
I'm not advocating for or against this type of approach - I'm just pointing out a few potential use-cases for it since that's what you asked for.
Nah man, I'm glad for you that you live in country X where you do Y instead, but at the same time as an European I'm pretty satisfied regulating big shitty companies
seems like they have pretty clear goals in mind. if they were changing distributions haphazardly id otherwise agree, but to me it reads that they're refining their taste.
The moment I read something in which the author is accusing someone of "spreading misinformation," I'm naturally inclined to take the accuser less seriously. Reckless use of that term is the real pattern of behavior.
> No safety disclaimers unless there is a genuine life-safety or legal risk.
> No "Note that...", "Keep in mind that...", "It's worth mentioning..." soft warnings.
> Do not create new files unless strictly necessary.
Nah bruh. Those are some terrible rules. You don't want to be doing that.