4 ms·

> So...don't use CRA? Sure, I can get by fine without that, but then I've got to educate 2 other members of my team, both who can program in numerous languages

by pryce 6y ago

> So...don't use CRA? Sure, I can get by fine without that, but then I've got to educate 2 other members of my team, both who can program in numerous languages but are quite inexperienced with web development, how to correctly set up each project using the React/Redux/Sass/Typescript/Jest. I can do it myself and hand them a project template, but then no-one else will learn how to do it. The reason for CRAs existence is (more than any argument I might make) an implicit acknowledgement that setting up new webapps is a far more painful experience than it should be. > it's kind of a surprise to see the claim that Webpack encourages its use. It was React that recommended CRA, not Webpack recommending CRA, apologies for my misleading description. > Or - a much easier tradeoff - just don't use Sass. I'm already quite familiar with plenty of reasons to not use -or to use- SASS. The point is that as a tech choice it's hardly a minor player, and yet the experience of setting up / migrating a project using easily recognisable tech (React/Redux/Sass/TypeScript) is a long way from a straightforward. In my example, I already had SASS on existing related projects. My team members were already familiar with it. Create-React-App was at the time was also actually already built to include support for SASS - the problem IIRC was that the fork of CRA that added Typescript support was forked from a CRA version before SASS was supported, so (at the time) it was a "one or the other" situation before I forked it and fixed it myself. > Keeping up with that kind of change, and knowing how to recognize and take advantage of the good, is one of the things it's an engineer's job to do. It's also part of our jobs to look at processes and procedures identify areas of inefficiency, and to ask questions about what a better way of doing things would look like. Finally, the trajectory of this discussion is pretty absurd. I'm offering examples of what happens in web development to illustrate that there is a massive difference between treating developer tools like Webpack / CRA as though they're similar to text-editors that you don't have to invest a bunch of time to understand and keep up to date with (a point that if I'm understanding you right, you likely agree with). My comment above's central claim is: that while critiques on size of dependency chain of developer tool like CRA or WebPack might be misguided, they are hardly lightweight cognitively, and the choice to use these tools (or not use them) isn't something to just take lightly because we clarified that our deployed artefacts didn't balloon in size.

throwanem 6y ago
Okay, that's fair. I certainly can't disagree that setting up a new web app in the modern style, from scratch and without prior experience, is cognitively heavyweight, and that reducing that complexity wherever possible is valuable. I would say that CRA's cognitive overhead, in a situation like that, isn't all that different from that of Rails, for example. They're both trying to do a very similar thing, albeit with very different approaches, and they're both very much of the convention-over-configuration school, which attempts to trade off not having to think very much at first about decisions you may not have enough information to make well, with making those decisions costlier later on once you do have enough knowledge to approach them. I have reservations about that entire school of thought, but despite them, my experiences with Rails and with CRA lead me to think that CRA does a generally much better job with those tradeoffs than Rails ever managed.

by pryce 6y ago

throwanem 6y ago

Okay, that's fair. I certainly can't disagree that setting up a new web app in the modern style, from scratch and without prior experience, is cognitively heavyweight, and that reducing that complexity wherever possible is valuable. I would say that CRA's cognitive overhead, in a situation like that, isn't all that different from that of Rails, for example. They're both trying to do a very similar thing, albeit with very different approaches, and they're both very much of the convention-over-configuration school, which attempts to trade off not having to think very much at first about decisions you may not have enough information to make well, with making those decisions costlier later on once you do have enough knowledge to approach them. I have reservations about that entire school of thought, but despite them, my experiences with Rails and with CRA lead me to think that CRA does a generally much better job with those tradeoffs than Rails ever managed.