This makes sense to me as a motivation for the disclaimer, thanks for that perspective.
I did feel that the yellow warning sign was a bit much. There was also a line about it not being for designers. As somebody with both design and engineering backgrounds, I felt less enthusiastic right away — mostly because I dislike buckets being enforced. It encourages people to put themselves into one over the long run, which in turn has a tendency to stunt their progress. It’s also odd when any educational resource (higher ed in the US being a great example) introduces itself by trying to be inaccessible. It feels counter to the professed goal of the institution / article.
Anyways, I guess I felt the comment above is a valid thing to discuss if it could improve other people’s efforts to write similar pieces.
As an aside: ironically, the article is fascinating from a design perspective. Just not the particular bucket of design the author was thinking of when he wrote that line.
For what it’s worth — I pretty much guarantee you that without this disclaimer, this post will make rounds in certain communities on Twitter as “haha React is so complicated glad I don’t use it”. This is an unfortunate reality that I’ve already ran into before.
Another unintended effect can be contributing to the perception that React is only for people with a strong programming background rather than, say, a11y expertise. I don’t want that either and that’s why I mentioned there are multiple ways to look at React.
Yet another problem is that random things from my posts are sometimes used in interview questions. :-/
I trust a curious reader to ignore the disclaimers and dive in anyway.
But I also wish I didn’t need to put it there and I emptathize with your frustration.
Fascinating. I didn’t know that comments like that were a common dynamic. That sounds like framework holy war nonsense. Sorry to hear that such problems come with working on cool stuff like this.
To me React always evokes the simplicity of the sample docs, which make it seem very inviting (just haven’t found a project to throw it at yet), so I didn’t have that frame of reference going into it. Not frustrated, just felt “if this guy Dan was a friend and had asked me to read this over, one of my notes might be for the intro to be less restrictive”. So I was surprised that people were calling the original commenter an idiot for suggesting such a sentiment, albeit from a different perspective.
Anyways, thank you for writing the article, it’s really an enjoyable read after a day of wrestling a closed source framework and wishing I could understand how that particular architecture was reasoned about.
I did feel that the yellow warning sign was a bit much. There was also a line about it not being for designers. As somebody with both design and engineering backgrounds, I felt less enthusiastic right away — mostly because I dislike buckets being enforced. It encourages people to put themselves into one over the long run, which in turn has a tendency to stunt their progress. It’s also odd when any educational resource (higher ed in the US being a great example) introduces itself by trying to be inaccessible. It feels counter to the professed goal of the institution / article.
Anyways, I guess I felt the comment above is a valid thing to discuss if it could improve other people’s efforts to write similar pieces.
As an aside: ironically, the article is fascinating from a design perspective. Just not the particular bucket of design the author was thinking of when he wrote that line.