4 ms·

Another great Rich Hickey talk is Simple Made Easy, very similar message. So many of these auto-project tools are very easy to use, but in no way simple to unde

Another great Rich Hickey talk is Simple Made Easy, very similar message. So many of these auto-project tools are very easy to use, but in no way simple to understand and end up adding complexity in the long-term. A good example is a tool like `create-react-app` (especially if you add TypeScript support). It's super easy to use and creates the project scaffold and enormous JS build system for you, but good luck trying to fix it if something breaks!

skinkestek 5y ago
I don't know what you do but I maintain 3 projects based on create-react-app and have done for 18 months. Together with a couple of senior guys and some younger devs (both guys and gals) I keep them updated, build new features, rewrite stuff to tsx (we got the projects handed down) and with one single exception I never even thought about the build system.
- aeturnum 5y ago
  I don't think they were saying create-react-app is bad or unusually fragile. It's that there are problems in building increasingly complex 'quick start' setups with the goal of making them accessible to people with less experience. The less you know about how the internals work, the less you'll be able to intuit about what you can and can't change. For many people who just want to make "an app" this doesn't matter, but it also means that a lot of quick start setups optimize for particular approaches that are built on top of particular sub-sets of how apps are built. So people leave the experience knowing more about how a particular component library than they do about the language or the requirements of mobile, or whatever. Or, to put it another way: increased complexity also increases the difficulty of investigation and modification. Making it easier to get an app 'somewhere' can make it harder for someone to understand what the app does to get where it's going.
88913527 5y ago
My actual experience with reporting the "something broke" in a large, popular OSS project was 18+ months until resolution. A crafty engineer thought it was a good idea to run their in-house optimization on third-party JS libraries to squeeze a few extra bytes out of the final bundle size (going above + beyond conventional methods like minification). Turns out that the overly aggressive optimization caused runtime exceptions, and they ended up cleaning up the feature. I've never had a good long-term experience with tools that try to be or solve everything for me, and today I avoid them.
jackTheMan 5y ago
it was the same with GWT (google-web-toolkit) it looked nice and many jumped to the bandwagon. But when something didn't work as expected you had to know a lot about debugging javascript (the internal work of javascript) and guess about the generation logic from java and think backwards. After all, you had to know more (then simply js) for debugging! And of course if your boss wanted something custom..
stickfigure 5y ago
I generally agree with your thesis (especially WRT this article) but create-react-app is a terrible example. I converted a fairly large handrolled webpack project to CRA, and it actually fixed a lot of broken things. For most single page apps, create-react-app occupies an abstraction level "sweet spot". Webpack is too low level and changes too quickly.
tshaddox 5y ago
> It's super easy to use and creates the project scaffold and enormous JS build system for you, but good luck trying to fix it if something breaks! I've always found myself experiencing that same feeling, but I've come to realize that this is essentially impossible to avoid by definition. Any tool or system you're using that is built using abstractions must by definition have some limitations at the boundaries of those abstractions, and those limitations can only be circumvented by jumping across that boundary. The only real decisions you can make are which tools to use for a particular job.
potatolicious 5y ago
This is a major beef I have with many modern frameworks - many confuse verbosity with simplicity or ease. Conceptual complexity is of enormous importance to the usability of a tool. I build APIs for a living and have often needed to push back vociferously over things that would make code terser, but the underlying mechanisms harder to understand. That said, I actually think codegens are often the right tool for the job - it removes a lot of boilerplate (at least from the developer needing to write it) but doesn't obfuscate underlying mechanisms - those are free for examination as needed. Of course, the devil's in the details - if the codegen'ed stuff is pure spaghetti that defeats this benefit. The worst, worst sin of all are frameworks that insert "magic" functionality. For example: name a thing in a special way and stuff will automagically happen to it? I can't think of a worse, more opaque way to design a system than rote memorization of incantation that reveal nothing about what's actually happening.
Zababa 5y ago
> A good example is a tool like `create-react-app` (especially if you add TypeScript support). It's super easy to use and creates the project scaffold and enormous JS build system for you, but good luck trying to fix it if something breaks! It's also really really huge. Where I work, we mostly use ASP.NET with a few JavaScript libraries. A team made a new thing in React. The node_modules weight 276 Mb for a 2 Mb app. npm audit says that there are 11 vulnerabilities, but the package.json was updated 2 weeks ago (and this is with npm install, not npm ci). There are in total 1000 libraries. 165 of them are looking for funding, which means they could easily be the target of a malicious agent (take the repo, publish something new on npm obfuscated, extract credentials). I see the value of modern development tools, but this is just insanity, and going way too fast. I used to be a huge fan of lots of small libraries updating often, but now that I'm in an enterprise context, it's hard to say the same. I wonder how people deal with this.
- hackerfromthefu 5y ago
  Yes that's the rational assessment. The joke gets worse! Wait till you have to support this system over the upgrade paths for those 1000 dependencies of varying pedigree and funding, and React has changed their one true way often which effects those libraries many of which jut deprecate and you have to find alternatives.
  - deleted 5y ago
    [deleted]
  - Zababa 5y ago
    > React has changed their one true way Is there even such a thing? I know that there was class components and then function components and then hooks, but outside of that, the insistance on React being a library means that the ecosystem is very fragmented. There's CRA, there's Next, there's Gatsby. There are lots of different ways to do CSS. TypeScript? No TypeScript? I wish there was a frontend framework focused on stability over time.
- chii 5y ago
  > I wonder how people deal with this. they don't, and just stick their head in the sand. I know i do!
another-dave 5y ago
I couldn't get my head around that coming back into frontend dev after a break from it — was on a project where we had some bug in the build output that seems like it'd be trivial to fix in a plain Grunt/Gulp set-up but was told "oh we can't fix that, because it's coming from within create-react-app & I don't know if we're ready to eject yet. Once you do, you can't go back"

skinkestek 5y ago

I don't know what you do but I maintain 3 projects based on create-react-app and have done for 18 months. Together with a couple of senior guys and some younger devs (both guys and gals) I keep them updated, build new features, rewrite stuff to tsx (we got the projects handed down) and with one single exception I never even thought about the build system.

aeturnum 5y ago
I don't think they were saying create-react-app is bad or unusually fragile. It's that there are problems in building increasingly complex 'quick start' setups with the goal of making them accessible to people with less experience. The less you know about how the internals work, the less you'll be able to intuit about what you can and can't change. For many people who just want to make "an app" this doesn't matter, but it also means that a lot of quick start setups optimize for particular approaches that are built on top of particular sub-sets of how apps are built. So people leave the experience knowing more about how a particular component library than they do about the language or the requirements of mobile, or whatever. Or, to put it another way: increased complexity also increases the difficulty of investigation and modification. Making it easier to get an app 'somewhere' can make it harder for someone to understand what the app does to get where it's going.

88913527 5y ago

My actual experience with reporting the "something broke" in a large, popular OSS project was 18+ months until resolution. A crafty engineer thought it was a good idea to run their in-house optimization on third-party JS libraries to squeeze a few extra bytes out of the final bundle size (going above + beyond conventional methods like minification). Turns out that the overly aggressive optimization caused runtime exceptions, and they ended up cleaning up the feature. I've never had a good long-term experience with tools that try to be or solve everything for me, and today I avoid them.

jackTheMan 5y ago

it was the same with GWT (google-web-toolkit) it looked nice and many jumped to the bandwagon. But when something didn't work as expected you had to know a lot about debugging javascript (the internal work of javascript) and guess about the generation logic from java and think backwards. After all, you had to know more (then simply js) for debugging! And of course if your boss wanted something custom..

stickfigure 5y ago

I generally agree with your thesis (especially WRT this article) but create-react-app is a terrible example. I converted a fairly large handrolled webpack project to CRA, and it actually fixed a lot of broken things. For most single page apps, create-react-app occupies an abstraction level "sweet spot". Webpack is too low level and changes too quickly.

tshaddox 5y ago

> It's super easy to use and creates the project scaffold and enormous JS build system for you, but good luck trying to fix it if something breaks! I've always found myself experiencing that same feeling, but I've come to realize that this is essentially impossible to avoid by definition. Any tool or system you're using that is built using abstractions must by definition have some limitations at the boundaries of those abstractions, and those limitations can only be circumvented by jumping across that boundary. The only real decisions you can make are which tools to use for a particular job.

potatolicious 5y ago

This is a major beef I have with many modern frameworks - many confuse verbosity with simplicity or ease. Conceptual complexity is of enormous importance to the usability of a tool. I build APIs for a living and have often needed to push back vociferously over things that would make code terser, but the underlying mechanisms harder to understand. That said, I actually think codegens are often the right tool for the job - it removes a lot of boilerplate (at least from the developer needing to write it) but doesn't obfuscate underlying mechanisms - those are free for examination as needed. Of course, the devil's in the details - if the codegen'ed stuff is pure spaghetti that defeats this benefit. The worst, worst sin of all are frameworks that insert "magic" functionality. For example: name a thing in a special way and stuff will automagically happen to it? I can't think of a worse, more opaque way to design a system than rote memorization of incantation that reveal nothing about what's actually happening.

Zababa 5y ago

> A good example is a tool like `create-react-app` (especially if you add TypeScript support). It's super easy to use and creates the project scaffold and enormous JS build system for you, but good luck trying to fix it if something breaks! It's also really really huge. Where I work, we mostly use ASP.NET with a few JavaScript libraries. A team made a new thing in React. The node_modules weight 276 Mb for a 2 Mb app. npm audit says that there are 11 vulnerabilities, but the package.json was updated 2 weeks ago (and this is with npm install, not npm ci). There are in total 1000 libraries. 165 of them are looking for funding, which means they could easily be the target of a malicious agent (take the repo, publish something new on npm obfuscated, extract credentials). I see the value of modern development tools, but this is just insanity, and going way too fast. I used to be a huge fan of lots of small libraries updating often, but now that I'm in an enterprise context, it's hard to say the same. I wonder how people deal with this.

hackerfromthefu 5y ago
Yes that's the rational assessment. The joke gets worse! Wait till you have to support this system over the upgrade paths for those 1000 dependencies of varying pedigree and funding, and React has changed their one true way often which effects those libraries many of which jut deprecate and you have to find alternatives.
- deleted 5y ago
  [deleted]
- Zababa 5y ago
  > React has changed their one true way Is there even such a thing? I know that there was class components and then function components and then hooks, but outside of that, the insistance on React being a library means that the ecosystem is very fragmented. There's CRA, there's Next, there's Gatsby. There are lots of different ways to do CSS. TypeScript? No TypeScript? I wish there was a frontend framework focused on stability over time.
chii 5y ago
> I wonder how people deal with this. they don't, and just stick their head in the sand. I know i do!

another-dave 5y ago

I couldn't get my head around that coming back into frontend dev after a break from it — was on a project where we had some bug in the build output that seems like it'd be trivial to fix in a plain Grunt/Gulp set-up but was told "oh we can't fix that, because it's coming from within create-react-app & I don't know if we're ready to eject yet. Once you do, you can't go back"