I really like React. I write a lot of it. But I was introducing my gf to react and had her read the documentation, cause that’s how I learned. First, it’s really easy to ignore the beta docs and end up learning class components. She wasn’t happy when I explained to her that what she had just learned is pretty out of date and not at all what the ecosystem uses. Second, there’s no simple explanation of forms! Oh sure it’s buried in the long intro tutorial but I’d love a one page tutorial on forms in react.
Also linting rules got way out of hand. Like a bunch of devs in the mid 10’s really decided to make linting the most annoying bunch of nitpicks around const, parameter naming, and other stuff that has no value. There’s a lint rule about naming the error parameter in catch “error”, not “err” or “e”. Who cares about this shit???
> There’s a lint rule about naming the error parameter in catch “error”, not “err” or “e”. Who cares about this shit???
That is certainly in the less important end of the linting rules spectrum. Nonetheless, conventions like these add up in larger codebases in my experience. The more consistency you have with things that repeat a lot across the code improve readability quite much because the brain is able to do more chunking over time.
Of course this doesn't matter that much when you are learning a language or a framework and only have a couple of files.
I’ve cited the same concept of consistency, and I still believe it to an extent. But I do feel like it’s folk wisdom to an extent and not necessarily backed up by evidence. Like is e vs err vs error so egregious that it really adds to mental overhead?
And sometimes there are explicit reasons to not do certain “best practices”. There was that whole era of making functions as small as possible, which of course meant you needed to jump to five function definitions to get even the slightest idea of what was happening. Or when everybody insisted on const and arrow functions for everything.
As well intentioned as these ideas are, they fall victim to trends and overzealous application. Any piece of advice has a trade-off and a situation where it does not apply. Therefore it’s important to remember that these ideas are fundamentally subjective guesses at how to write good code. Not gospel truth.
Of course that isn’t to say linters are bad. Just that lint rule authors should be very careful to check that they are actually writing rules of value and not just nit picky folk wisdom.
> First, it’s really easy to ignore the beta docs and end up learning class components. She wasn’t happy when I explained to her that what she had just learned is pretty out of date and not at all what the ecosystem uses
I was just about to start learning through the tutorials on React's site. Are they still outdated? If so, what's a good up to date tutorial I can use?
The beta docs are just that, beta. They're being written as a replacement for the current ones but aren't yet stable. So asking "why is that the case", the answer is simply that they're rewriting old docs and aren't done yet.
Also as a newcomer to Next.js, you start off, the tutorial seems great, then midway they announce they are switching to a new system and it's hard to be bothered after that.
NextJS 13 introduced an app directory which is different than file based routing (to some extent). But it's till in beta so you don't have to worry about it right now.
The JavaScript ecosystem seems uniquely poor at this docs inconsistency stuff. It’s almost like someone lowered the bar one day, and then everyone else learned from that low bar and all think that their behaviour makes any sense whatsoever.
I’ve been tinkering with a lot of mainstream JS frameworks and they pretty much all have their version of this problem.
Next has their new App Directory stuff going on with its own beta docs site. It’s been a few weeks since I looked, so I can’t remember the specifics, but the messaging on the new and old docs sites was not good enough for me to immediately grok what was going on. It also made Googling near impossible.
We got our long-awaited next major version of Nuxt not long ago, too. They seemingly decided that they could just change domains, put a little banner up on the old site, and make the problem go away. Again, makes Googling incredibly hard. I found myself having to remember the design and domain of the old and new sites to know if I’d accidentally stumbled on old documentation. I really want to make Nuxt work for me, but this docs experience left a bad taste in my mouth, a very specific “pre-production” taste, which is really unfortunate given Nuxt’s cadence with v3 stability.
React was about as bad as Next. I found myself bouncing between the stable and beta docs consistently. All the messaging around the stability and supported use cases for Suspense is just…way too impenetrable. I’m a seasoned web application developer. I’m confident that the majority of this isn’t a “me” problem.
The only docs experience I’ve had that comes close to addressing the issue appropriately is the Vue documentation. There’s a nice big switch at the top that switches the docs from favouring the old-school vs composition APIs.
Of course, the underlying problem is React and Vue so solidly keeping their foot in both camps. This is just an outcome of that.
I try my absolute hardest to enter the JS ecosystem with the most open of minds, and there are plenty of people working in this space that are certainly much smarter than me. I just get the impression that there are too many people that don’t have experience with other language ecosystems, or that have long since forgotten what they’re like, to the point where they’re blind to these sorts of DX shortcomings. The React Hooks / Composition API hard-left-turn smells JUST enough like Python 2 / 3 et al that I’m pretty confident in my estimate of how it’s all going to go down. History repeats, or whatever.
> First, it’s really easy to ignore the beta docs and end up learning class components. She wasn’t happy when I explained to her that what she had just learned is pretty out of date and not at all what the ecosystem uses.
Yeah, that's an absolutely terrible experience.
Why can't there be a modicum of stability in the ecosystem?
Are class components really considered out of date? I still prefer writing those compared to functional components. Vue is also moving in that direction with their composite API.
I think it’s why I like Svelte, it’s just JavaScript.
Hooks are a very useful abstraction, they are like functions but with a built in of lifecycle state (so not pure but implicitly effectful). I cut down so much code using hooks, I even use them in non JS projects even, such as in Flutter with flutter_hooks, that's how strong of an abstraction they are.
It's not, that's why I like React, I don't have to learn how to do a for loop in a custom HTML DSL again. And before anyone says it, no, JSX is not a DSL, it's just syntax sugar over JS, you can write React fully in createElement if you want.
I wonder if Vercel will take over React at some point as they seem to be capable of GSD very rapidly with a great hit rate. It sometimes feels like any improvements these days in the React ecosystem are because of improvements to Next or improvements to key libraries like react-query/tan-query.
> We all love free open source software. But when VCs get involved, it means they
> expect a huge monetary return. These things just don’t go together.
I am not sure what case study the author is thinking of that they are so hostile to the idea of cash flowing into OSS ?
I would like to see more money flowing toward open source creators and maintainers. It's terrible that companies use the OSS that's built on the backs of people that do not receive remuneration for their efforts.
PS: I really like the design and speed of the author's website. Inspired me to pickup Astro for next project.
With VC backing open source work, at some point there's going to be a big demand to monetize all the users of that software they put all that money into. We haven't seen the result of that yet, but we will, and it's not going to be pretty. The main players that I've seen here are Gatsby, Vercel, Apollo GraphQL, and more – it _will_ happen. Those edge networks they're selling aren't going to have that hockey-stick growth that VCs are looking for, so what next?
PS: Thanks! I have a blog entry about why I ended up choosing Astro as well. I was just playing around with it and it sort of stuck because it was so fast and easy.
> I would like to see more money flowing toward open source creators and maintainers. It's terrible that companies use the OSS that's built on the backs of people that do not receive remuneration for their efforts.
Support them directly, then, if they offer the means to do so. Corporations don't pay the creators of open source software because by definition they don't have to. They also tend not to contribute back to projects, have a habit of abusing licenses and stealing code, and have an outsized influence on the community (see Google/Chromium's de facto control of web standards.)
I want a programmatic bundler/library that lets me write some kind of bundle.ts file to do the things I need, nothing more. I hate the JS ecosystems reliance on DSLs and JSON config files, give me low level tooling.
Or something that goes in the complete opposite direction if it does it well.
This is why I found Parcel really exciting to work with after battling with Webpack for so many years. I haven’t used it at work yet so part of my good luck could be the simplistic nature of what I was using it with, but the project was certainly at the “this is a useful production-grade thing” level, and I know what I’d have to do to get there with Webpack, and it’s far from “nothing”.
I appreciate the desire for low-level tooling, especially given how rocky it’s been for the past decade. I’m very cautiously optimistic about the chances of the ecosystem, esp. browser functionality, soon getting to the point where getting one’s hands dirty with this stuff only makes sense in esoteric cases.
Matter of opinion though. I decided a few months ago to try some different frameworks and libraries etc. I had a project in mind that was more than trivial. I did like sveltekit. I do like vue. But I can't get over how much further and faster I was able to get up and running with react.
With svelte I ran into an issue, I'm sorry it was a few months ago and I forget exactly what it was. I spent hours trying to get around it, and then read online others had the same issue and it just wasn't catered for. Whatever it was, it was frustrating enough that I just gave up.
I tried a bunch of different libraries as well. One nice thing about react is that you get to choose from a variety of interesting state managers on top. Yes, svelte just worked (except when it didn't) but actually the constraints of each state library helped with structure.
I'll look at svelte again next year, but if I was starting a new product right now I'd go for what works, has the best ecosystem and most familiarity with developers - react. The alternatives have some pros but are not yet compelling enough (excepting some more server side driven solutions but that's out of context).
This is why I switched from Vue to React. The library support is just not there compared to React. Never discount network effects in programming (or elsewhere). Even if one might think a solution is worse (and I definitely don't think React is worse than Vue or Svelte, on the contrary I think it's much better), you might simply have to switch for the fact that you can get stuff done a lot faster and in a more production scale environment (better maintained libraries with a larger community instead of only one option whose last commit was 2 years ago) if you go with the most popular language, library, or framework.
Nah, React is quite simple. It doesn't have much complexity to it as a base library. Yes hooks have some gotchas but once you understand their design (that they are functions with a built-in memory of lifecycle state), they're easy to grasp. Svelte and Vue on the other hand, they have multiple ways of doing things and have their own HTML DSL. You couldn't pay me to write another v-for or #if again.
Also, Next does have beta docs on using RSC, not their internal details too much, which would be enough for 90% of the cases of practically using them.
Yup! I've seen both. I'm looking for something a little more than the RFC, a guide for framework authors to implement and / or framework-level hooks for implementing. The RFC and example app is helpful, but something more final would be nice.
You get the developer experience of writing in the component format without necessarily shipping that JS to the client. Basically, PHP but with TypeScript, since I much prefer TypeScript and typed languages in general over PHP.
Also, you can have most of the site be HTML with a little JS on top, like 20 years ago, but again fully typed and you can use the same language throughout the codebase.
Also linting rules got way out of hand. Like a bunch of devs in the mid 10’s really decided to make linting the most annoying bunch of nitpicks around const, parameter naming, and other stuff that has no value. There’s a lint rule about naming the error parameter in catch “error”, not “err” or “e”. Who cares about this shit???