Also, automagic, automagic everywhere. "Let me just intercept your request and send it to a HANDLER, wow." "Let me just have a magical 'getServerSideProps' function that will do magic and generate component props, but it has to live in the page, so the page gets extremely bloated, oooo."
I hate Next. And I realize "hate" is a strong word that takes some earning.
I disagree on the convenience point - it's bloat and not in the sense that people say "IDEs are bloat". It's regressive in going back to an MVC pattern in a framework that's meant to be an SPA and completely violates the "There should be one, and only one, way of doing things" principle in that it adds confusing options that people end up using in practice.
Next.js is pretty convenient, not sure why people find it so inconvenient. With the pages directory, each page is its own page, just like in the PHP days. Why do you think it's an MVC pattern? I don't use Next like that at all, it's just React.
It is jarring at first when you look at your code and say, "Wait, what else do I need to do?" And there's nothing left.
const { count, setCount } = useState(0);
becomes let count = 0;
There is no more useMemo(…) or useEffect(…). They just don't exist. There's no need for them. State management "just works" by using a store variable like $store. No more explicit subscribe and then having to remember to set up an event callback to unsubscribe and avoid a resource leak.Vanilla JS libraries typically work out if the box with it without some bespoke wrapper or adapter for your framework. ("bind:this" is really handy.)
Web development with 99% less BS. Lets you focus on your problem, not on your framework's abstraction leaks.
I myself am more of a clean, standard HTML with PicoCSS kind of dev, but that model doesn't work for everyone. Some might be surprised how much plain old HTML and the ease of development for Svelte components narrows that gap, but I'll be the first to admit the gap absolutely exists.
FWIW: Material UI for Svelte has been around for a while as well.
Just make a descriptive class name and write your CSS styles. That's it. You're done.
Okay, that's a choice.
> I wanted to move to React where I can use actual JS
You… uhh… know that JSX was literally invented as React's own HTML-like DSL, right? And that TypeScript is not "actual JS", right?
Just food for thought: HTML can exist and provide tremendous value on the frontend without JS. JS on the frontend without HTML is… not quite as useful. Be careful about which technology you want to be the central player.
Never mind that TS is a superset of "actual JS," your point doesn't even touch my argument which is that I want type safety, such as when props are missing or invalid types, and so on. Even if TS is not "actual JS," that's a semantic argument and doesn't matter as long as type safety exists. I've even written sites in Rust via Yew, works great and outputs HTML at the end of the day.
> Just food for thought: HTML can exist and provide tremendous value on the frontend without JS. JS on the frontend without HTML is… not quite as useful. Be careful about which technology you want to be the central player.
Not sure what you're talking about with this point, I never said HTML isn't useful.