I still prefer svelte but it's less mature and universally-known. React is still a pretty good choice if you need something that will more or less work and that anyone can write.
I know svelte/sveltekit and would want to contribute to svelte apps (a good reminder that I should)
But there are some projects that I really really want to contribute to / heck even port to sveltekit like cinny and hedgedoc and the likes and so I almost feel pressured by the system to learn react so that I can finally feel confident enough to understand their repositories as they scare me right now...
Cinny:https://github.com/cinnyapp/cinny Hedgedoc:https://github.com/hedgedoc/hedgedoc
I don’t even want to talk to somebody that defines themselves as a “React” developer. Let alone work with them.
If you know any of these frameworks, and the basics of web development you can work in any of them.
So the hiring part is not an excuse for this.
Isn't it mainly about playing nice with crawlers? SEO and the like?
(that was my understanding but I'm a backend dev).
Honestly except for the marketing page and blogs and stuff, most apps are fine without server rendering. In fact I'd say many that avoid server rendering actually feel better simply because next.js makes it really easy to screw up your performance doing it.
I see this happening in finance data sites. Say a page about Apple, has stock price, etc. when logged in, same stuff but 10x data so they layout and everything is different.
That being said, I'm waiting in the back stage, like many other folks, for tanstack to get production-ready, because of the all the weird crap being pulled by Vercel on NextJS.
Lots of newcomers are struggling and not understanding what are the options and which approach is best for their case.
Business people don’t help as they rightfully don’t care. But they want „do everything” - „pay once” approach so people bolt on static pages ona apps or other way around.
Example: This logistics SPA I was building I realized could just be single pages with some data for most of the stuff (tracking, inventory, etc...) but for admins they wanted a whole dashboard. This was a conditional on some value of the stored session user. So it ended up being kinda a website for parts of it and an SPA admin panel if the user conditionally matched some privileges. Probably should have been separate stacks but they used the same data so early on they made it the same Next app.
I don't think the whole website vs app thing is always as simple as static blog pages vs full fledged JS-heavy app. There is a spectrum and overlap even within a single "application" because of various requirements.
Your last sentence is the most accurate. I don't think its primarily ignorance, its just trying to meet all the requirements while retaining some level of organization in the codebase.
What are the reasons for not doing SSR?
My default is a small page that client then fetches any additional data it needs. If its long load time skeleton UI it. I also have not seen the SEO benefits at all.
So again _why would I_ unless I needed to do stuff on the server to make the client bundle, which I don't.
A lot of these YC companies doing this could literally just be using a fetch because their backend is dead simple REST.
EDIT: if its pure (not reactive to any other variable but other variables may react to it) they will auto memoize I guess to avoid their own reactivity engine doing a bunch of useless shit when no value was actually updated. Correct me here if I am wrong.
You have to opt-in to prop-diffing conditional re-renders (which I wouldn't call a "reactivity engine" either) per component, via React.memo.
And then you also have to opt-in to prop memoization for non-primitives for the prop-diffing not to be useless.
These re-renders might not result in any actual DOM changes since there is an additional vDOM diffing step from the resulting render (which, again, I wouldn't call a "reactivity engine").
https://en.wikipedia.org/wiki/Reactive_programming
https://en.wikipedia.org/wiki/Functional_reactive_programmin...
Which I think React doesn't really fit. React is not about data streams, nor about inferred dependencies.
> Technically you could just getElementById and update it, but react has what I call a whole "reactivity engine" to do it for you.
I would call that "declarative", not "reactive".
https://en.wikipedia.org/wiki/Declarative_programming
The closest thing to reactivity React has are dependency arrays in `useCallback` but I'd say it's a stretch to call that reactive programming.
Compare it with SolidJS's data flow. https://docs.solidjs.com/ Also notice how "reactive" is all over their landing page while React doesn't mention "reactive" at all https://react.dev/
Whereas other frameworks have a full blown reactivity system with signals (basically implicit observables), so your state values are not just regular javascript objects but either proxies or some other object which can be tracked by access in components to update things granularly, eg. setting an elements innerText but automatically.
I think it's worthwhile to compare the 2 - I'm sure one of the major contributors of React's slowness is the crazy amount of objects it generates triggering GCs - desugared jsx code turns into building up the React DOM with React.createElement
There's no reason why they couldn't have just done what Imgui did and each createElement would be a function call, that doesn't need to allocate. Considering the js API is not something most devs use, most folks wouldnt mind if it got replaced.
State management is also another issue - considering React has had a compiler due to jsx since the outset, not using that since the beginning to do a little data flow analysis and figure out which piece of state affects what UI elements is just criminal - an further exacerbates the waste in other parts of framework, by running already wasteful code more often than it needs to.
Tbf, they already fixed the compiler issue with the latest React, but only as a reaction to getting destroyed by Svelte on the performance front.
Just goes to show, that if you don't have competition, there's no guarantee positive change will happen on any time scale no matter the resources you throw at the problem.
I’ve also used Next for new projects in the last year - it just depends on the infra requirements.
Vercel’s position in the ecosystem is one we should question. Maybe it’s not good for innovation to use Next for every new project. The recent controversy with their CEO isn’t helping the situation either.