4 ms·

Why would create react app add more run-time dependencies? Isn't that just Babel and stuff used for building? Also, with TypeScript, Babel becomes completely u

Why would create react app add more run-time dependencies? Isn't that just Babel and stuff used for building? Also, with TypeScript, Babel becomes completely unnecessary. I haven't used it in any of my React projects for years. Many templates still include it by default to match the JS version, but if you create the project from scratch without any scaffolding, there is no reason to do so.

mythz 6y ago
> Why would create react app add more run-time dependencies? Isn't that just Babel and stuff used for building? You can see all the dependencies it installs by running: $ npx create-react-app my-app > Also, with TypeScript, Babel becomes completely unnecessary. Right, as per my comment it's also my preferred approach: > My preference these days is to avoid npm/yarn all together and just use TypeScript watch In general I prefer Vue over React, but I prefer to use vanilla TypeScript & UMD deps to develop with either. > Many templates still include it by default to match the JS version It's what the React team is recommending to start with [1]: > Create React App is a comfortable environment for learning React, and is the best way to start building a new single-page application in React. [1] https://reactjs.org/docs/create-a-new-react-app.html#create-react-app https://reactjs.org/docs/create-a-new-react-app.html#create-...
- realharo 6y ago
  I just ran that. It took a long time, and the progress bar showed fetching 1381 packages. Definitely https://i.redd.it/i428f2ki0ho01.jpg https://i.redd.it/i428f2ki0ho01.jpg. However, the resulting `package.json` only shows 3 dependencies: react, react-dom and react-scripts. After `yarn build`, it added 3 more things from `@testing-library` (https://testing-library.com/ https://testing-library.com/), I assume those things won't make it into the production bundle. react and react-dom only depend on a tiny number of things, you can check that with any dependency visualizer. 6 or 7 in total for the whole tree, and most of those are tiny things that they just split off from react itself (e.g. prop-types). react-scripts is the huge beast that causes the dependency tree to explode. It is a `create-react-app`-specific package that contains all its build logic. So that seems to confirm the hypothesis that there actually aren't many runtime dependencies in the basic template, but who knows what it does behind the scenes. Also the LICENSE.txt file it generated for the biggest output .js file only includes entries for react, react-dom and object-assign. No idea about React Native.
  - mythz 6y ago
    Right, each time a new project is created it contributes to global warming. The entire dependency matrix is what impacts normal development workflow, e.g. everytime I tried to update an old Webpack SPA project there would be always something that was broken that I'd have to hunt down & fix. > No idea about React Native. The OP suggests it's worse. But I no longer use React Native as I kept running into bugs & UI issues that were never fixed. I ended up reporting a few with complete repro's but didn't look like they were ever looked at, instead after a few months they decided to triage their 1000s of open issues, to get back to zero issue inbox. IMO React Native is architecturally flawed to run into so many issues when creating normal Apps after years of development, maybe if there were more developer resources on the team it would be more manageable. But I believe Flutter has a much better architecture [1] which feels much more integrated & polished that results in a more responsive app that works as advertised. [1] https://dart.dev/platforms https://dart.dev/platforms
    - realharo 6y ago
      Flutter itself seems nice, but Dart as a language is a pretty big downgrade from TypeScript. For mobile right now, the easiest, most headache-free solution may actually be to forget about cross-platform and just do separate Android and iOS native apps. You won't need to do things like hunt for a bunch of 3rd party libraries whenever you need to use Bluetooth or something. Once SwiftUI and Jetpack Compose mature, that process should be much more pleasant as well.
      - mythz 6y ago
        > Flutter itself seems nice, but Dart as a language is a pretty big downgrade from TypeScript. It definitely isn't, Dart is an advanced clean, strongly typed classical language without JS's warts that's just as clean & productive with a clean complete & well-defined standard library, native support for modules, consistent async/await in all libraries, etc. I love TypeScript, but it's major productivity advantage over Dart is in JS's dynamism, something that's a lot more restrictive in Dart because it needs to support AOT, which is what allows it to compile to native code & advanced linking + tree-shaking, resulting in its better performance. So there are areas where you need to use code-gen, but having wasted an eternity trying to diagnose runtime issues in C#/Xamarin in libraries that use reflection, I'd much rather use an AOT language that only provides language features that natively supports AOT then running into frequent on-device issues that only occur at runtime. > For mobile right now, the easiest, most headache-free solution may actually be to forget about cross-platform and just do separate Android and iOS native apps. Nope, Flutter's Reactive UI & live-reload is far more productive then developing using native iOS or Java/Kotlin tools (which can also be used in Android Studio). SwiftUI is close if you just need to develop for iOS, but I find Dart/Flutter to be a lot more productive than using Swift & Xcode's woefully poor tooling support.

mythz 6y ago

> Why would create react app add more run-time dependencies? Isn't that just Babel and stuff used for building? You can see all the dependencies it installs by running: $ npx create-react-app my-app > Also, with TypeScript, Babel becomes completely unnecessary. Right, as per my comment it's also my preferred approach: > My preference these days is to avoid npm/yarn all together and just use TypeScript watch In general I prefer Vue over React, but I prefer to use vanilla TypeScript & UMD deps to develop with either. > Many templates still include it by default to match the JS version It's what the React team is recommending to start with [1]: > Create React App is a comfortable environment for learning React, and is the best way to start building a new single-page application in React. [1] https://reactjs.org/docs/create-a-new-react-app.html#create-react-app https://reactjs.org/docs/create-a-new-react-app.html#create-...

realharo 6y ago
I just ran that. It took a long time, and the progress bar showed fetching 1381 packages. Definitely https://i.redd.it/i428f2ki0ho01.jpg https://i.redd.it/i428f2ki0ho01.jpg. However, the resulting `package.json` only shows 3 dependencies: react, react-dom and react-scripts. After `yarn build`, it added 3 more things from `@testing-library` (https://testing-library.com/ https://testing-library.com/), I assume those things won't make it into the production bundle. react and react-dom only depend on a tiny number of things, you can check that with any dependency visualizer. 6 or 7 in total for the whole tree, and most of those are tiny things that they just split off from react itself (e.g. prop-types). react-scripts is the huge beast that causes the dependency tree to explode. It is a `create-react-app`-specific package that contains all its build logic. So that seems to confirm the hypothesis that there actually aren't many runtime dependencies in the basic template, but who knows what it does behind the scenes. Also the LICENSE.txt file it generated for the biggest output .js file only includes entries for react, react-dom and object-assign. No idea about React Native.
- mythz 6y ago
  Right, each time a new project is created it contributes to global warming. The entire dependency matrix is what impacts normal development workflow, e.g. everytime I tried to update an old Webpack SPA project there would be always something that was broken that I'd have to hunt down & fix. > No idea about React Native. The OP suggests it's worse. But I no longer use React Native as I kept running into bugs & UI issues that were never fixed. I ended up reporting a few with complete repro's but didn't look like they were ever looked at, instead after a few months they decided to triage their 1000s of open issues, to get back to zero issue inbox. IMO React Native is architecturally flawed to run into so many issues when creating normal Apps after years of development, maybe if there were more developer resources on the team it would be more manageable. But I believe Flutter has a much better architecture [1] which feels much more integrated & polished that results in a more responsive app that works as advertised. [1] https://dart.dev/platforms https://dart.dev/platforms
  - realharo 6y ago
    Flutter itself seems nice, but Dart as a language is a pretty big downgrade from TypeScript. For mobile right now, the easiest, most headache-free solution may actually be to forget about cross-platform and just do separate Android and iOS native apps. You won't need to do things like hunt for a bunch of 3rd party libraries whenever you need to use Bluetooth or something. Once SwiftUI and Jetpack Compose mature, that process should be much more pleasant as well.
    - mythz 6y ago
      > Flutter itself seems nice, but Dart as a language is a pretty big downgrade from TypeScript. It definitely isn't, Dart is an advanced clean, strongly typed classical language without JS's warts that's just as clean & productive with a clean complete & well-defined standard library, native support for modules, consistent async/await in all libraries, etc. I love TypeScript, but it's major productivity advantage over Dart is in JS's dynamism, something that's a lot more restrictive in Dart because it needs to support AOT, which is what allows it to compile to native code & advanced linking + tree-shaking, resulting in its better performance. So there are areas where you need to use code-gen, but having wasted an eternity trying to diagnose runtime issues in C#/Xamarin in libraries that use reflection, I'd much rather use an AOT language that only provides language features that natively supports AOT then running into frequent on-device issues that only occur at runtime. > For mobile right now, the easiest, most headache-free solution may actually be to forget about cross-platform and just do separate Android and iOS native apps. Nope, Flutter's Reactive UI & live-reload is far more productive then developing using native iOS or Java/Kotlin tools (which can also be used in Android Studio). SwiftUI is close if you just need to develop for iOS, but I find Dart/Flutter to be a lot more productive than using Swift & Xcode's woefully poor tooling support.