5 ms·

Looks like it is just the asset pipeline, so not anything that is loaded on the frontend. Little bit click baity. A lot of other frameworks do the same thing.

svnpenn 6y ago
> A lot of other frameworks do the same thing. God that is an awful justification. The heading is the opposite of clickbait. 106 MB is not exaggerated, the link provides proof showing that number. I get pretty tired of people handwaving away bloat these days. Its a real problem across programming languages and communities, and it doesnt just go away by pretending it doesnt exist. It goes away by people testing for it, making it a priority for software to be streamlined and pruning bloat where it makes sense.
- gtirloni 6y ago
  It's really clickbait. The "proof" provided includes all sorts of crap that the npm packages ship with. If you want to show how much JS a new Rails project has, show what gets delivered to the frontend not all the trash in node_modules.
- thrwwy90876 6y ago
  It's build tools. This is like complaining that Xcode is many gigabytes.
  - pistoriusp 6y ago
    And, what about OS X, it takes a huge amount of space... and they install things I never use! It's almost as if these things run on code!
    - cxr 6y ago
      These kinds of comments are against HN guidelines FYI.
      - pistoriusp 6y ago
        You're right, I was not in the best light last evening. My apologies to the community.
  - tedunangst 6y ago
    I never had to install a new copy of xcode for every project.
    - pistoriusp 6y ago
      So the problem is not the size, but that you want to have a single cache of all the npm modules?
  - johannes1234321 6y ago
    Xcode is from a single vendor, whom I trust as much as I trust the operating system. With rails and npm I probably trust Rails and see them as license-wise ok, but due to version requirements I might get "newer" versions of a package, which hasn't been veted by Rails devs, might use different license, might do stuff I don't want it might add in even other new deps.
    - isochronous 6y ago
      Then all you have to do is specify the specific version you want in your package.json, rather than a semver range, and you'll never get a version you haven't explicitly approved.
      - johannes1234321 6y ago
        Of each of the dependencies Rails installs.
        schwartzworld 6y ago
        don't use an opinionated framework then?
  - rileytg 6y ago
    I don't upload xcode.app to apple every time i submit an iOS app. I do npm install on every build on heroku.
    - eropple 6y ago
      Then maybe don't use Heroku and use something that can work with a finished build? It's not complicated to set up a build container locally and ship only your final result to a service that can run it.
      - jspash 6y ago
        Just build locally and vendor the asset artefacts. That's how we did it in the "good old days". No containers in containers needed.
        eropple 6y ago
        To be clear, you don't do "containers in containers", you build a container and you copy your assets from the other one. You then have a shippable artifact with all your dependencies, including your runtime, vendored into it. I'm not a k8s guy, but it's a lot nicer than a tarball.
      - deleted 6y ago
        [deleted]
      - rileytg 6y ago
        Heroku provides value in other ways for us. We run on a number of other solutions, most involve shipping a ~100mb image. This can be dramatically reduced in size with a slimmer base image, which we plan on doing eventually. In this case, heroku handles a lot of things we otherwise need to do ourselves: - DB + backups + DR - Network security - Network routing - SSL certs - Easy scaling of resources - Access control to operations (redeploy, restart etc) - Audits of operations etc We can do all these things, and under various compliance frameworks, outside of heroku; its just exhausting and expensive. This project we want to focus on the product so we opt for heroku as it was a few lines of bash we were all familiar with to get up and running nearly prod ready.
- mithr 6y ago
  You sort of missed the point. The point isn't "there's 106mb of code that will make it into production, but it's ok because other frameworks do it" -- the point is "looking at the size of the node_modules directory is not remotely representative of the final size of the bundled code that will make it to production, and this is in fact the way many modern frameworks work." Two concrete examples: first, node_modules contains any development modules, which won't make it into the final code at all. Second, most of these packages are installed into the node_modules directory with typing support, full un-minified code, etc etc. When bundling the app for deployment, much of that goes away.
  - johannes1234321 6y ago
    Still it's 106MB which has to be audited, checked for license, ...
    - mithr 6y ago
      I don't think anyone's forcing you to use the rails CLI's "new" command to start a new rails project, if you're concerned about all of that and just don't want to deal with it... the docs explicitly say that this is a convenience method for getting started quickly with everything they think a modern developer would want. If you don't want that, that's a perfectly fine choice -- just start a new project from scratch, instead.
  - rileytg 6y ago
    The issue for me is nuanced. While it doesn't go to end users in production, it still ends up in my heroku buildpack. This sharp increase (33% of my allowed buildpack) was alarming. Having been a rails and react developer for a very long time, i'm generally aware of the value added by all these files. I bring up these concerns almost to say "have we added too much? is it time to think about trimming back?".
- wzy 6y ago
  How is it bloat if 160MB of JavaScript will never be in the production version of the app? I mean, the Basecamp team just published Hey.com with less the 50KB of JavaScript and their dev build of Rails for that project must've exceeded 160MB in `node_modules`.
  - deleted 6y ago
    [deleted]
treis 6y ago
Rails 6 has become significantly more JavaScript intensive and has bought into the ecosystem. IMHO, it's a mistake and they were better off staying in their niche. Server side rendering + Turbolinks is a very compelling story and much simpler to get into than what Rails 6 is now.
- sosborn 6y ago
  JS in rails is entirely opt-in.
  - WJW 6y ago
    Opt-in means the default is without JS and you can enable it if you want. As shown in the gist, the situation is actually that by default all the JS is installed and you have to explicitly opt-out to prevent it from being installed.
    - sosborn 6y ago
      When you create a new rails project, the tooling for JS is set up, but none of that gets used (Turbolinks the only exception) unless you write or include JS code. The tooling does not affect the user experience one bit.
  - cocktailpeanuts 6y ago
    No. That's what it used to be in the old days, but not anymore. I've been away from rails for a couple of years and recently came back to build a side project. The latest rails version shoves all kinds of JS stuff down your throat, you have to literally opt out. The whole point of rails is "convention over configuration", and they have adopted the bloated NPM + Webpack ecosystem as their "convention".

svnpenn 6y ago

> A lot of other frameworks do the same thing. God that is an awful justification. The heading is the opposite of clickbait. 106 MB is not exaggerated, the link provides proof showing that number. I get pretty tired of people handwaving away bloat these days. Its a real problem across programming languages and communities, and it doesnt just go away by pretending it doesnt exist. It goes away by people testing for it, making it a priority for software to be streamlined and pruning bloat where it makes sense.

gtirloni 6y ago
It's really clickbait. The "proof" provided includes all sorts of crap that the npm packages ship with. If you want to show how much JS a new Rails project has, show what gets delivered to the frontend not all the trash in node_modules.
thrwwy90876 6y ago
It's build tools. This is like complaining that Xcode is many gigabytes.
- pistoriusp 6y ago
  And, what about OS X, it takes a huge amount of space... and they install things I never use! It's almost as if these things run on code!
  - cxr 6y ago
    These kinds of comments are against HN guidelines FYI.
    - pistoriusp 6y ago
      You're right, I was not in the best light last evening. My apologies to the community.
- tedunangst 6y ago
  I never had to install a new copy of xcode for every project.
  - pistoriusp 6y ago
    So the problem is not the size, but that you want to have a single cache of all the npm modules?
- johannes1234321 6y ago
  Xcode is from a single vendor, whom I trust as much as I trust the operating system. With rails and npm I probably trust Rails and see them as license-wise ok, but due to version requirements I might get "newer" versions of a package, which hasn't been veted by Rails devs, might use different license, might do stuff I don't want it might add in even other new deps.
  - isochronous 6y ago
    Then all you have to do is specify the specific version you want in your package.json, rather than a semver range, and you'll never get a version you haven't explicitly approved.
    - johannes1234321 6y ago
      Of each of the dependencies Rails installs.
      - schwartzworld 6y ago
        don't use an opinionated framework then?
- rileytg 6y ago
  I don't upload xcode.app to apple every time i submit an iOS app. I do npm install on every build on heroku.
  - eropple 6y ago
    Then maybe don't use Heroku and use something that can work with a finished build? It's not complicated to set up a build container locally and ship only your final result to a service that can run it.
    - jspash 6y ago
      Just build locally and vendor the asset artefacts. That's how we did it in the "good old days". No containers in containers needed.
      - eropple 6y ago
        To be clear, you don't do "containers in containers", you build a container and you copy your assets from the other one. You then have a shippable artifact with all your dependencies, including your runtime, vendored into it. I'm not a k8s guy, but it's a lot nicer than a tarball.
    - deleted 6y ago
      [deleted]
    - rileytg 6y ago
      Heroku provides value in other ways for us. We run on a number of other solutions, most involve shipping a ~100mb image. This can be dramatically reduced in size with a slimmer base image, which we plan on doing eventually. In this case, heroku handles a lot of things we otherwise need to do ourselves: - DB + backups + DR - Network security - Network routing - SSL certs - Easy scaling of resources - Access control to operations (redeploy, restart etc) - Audits of operations etc We can do all these things, and under various compliance frameworks, outside of heroku; its just exhausting and expensive. This project we want to focus on the product so we opt for heroku as it was a few lines of bash we were all familiar with to get up and running nearly prod ready.
mithr 6y ago
You sort of missed the point. The point isn't "there's 106mb of code that will make it into production, but it's ok because other frameworks do it" -- the point is "looking at the size of the node_modules directory is not remotely representative of the final size of the bundled code that will make it to production, and this is in fact the way many modern frameworks work." Two concrete examples: first, node_modules contains any development modules, which won't make it into the final code at all. Second, most of these packages are installed into the node_modules directory with typing support, full un-minified code, etc etc. When bundling the app for deployment, much of that goes away.
- johannes1234321 6y ago
  Still it's 106MB which has to be audited, checked for license, ...
  - mithr 6y ago
    I don't think anyone's forcing you to use the rails CLI's "new" command to start a new rails project, if you're concerned about all of that and just don't want to deal with it... the docs explicitly say that this is a convenience method for getting started quickly with everything they think a modern developer would want. If you don't want that, that's a perfectly fine choice -- just start a new project from scratch, instead.
- rileytg 6y ago
  The issue for me is nuanced. While it doesn't go to end users in production, it still ends up in my heroku buildpack. This sharp increase (33% of my allowed buildpack) was alarming. Having been a rails and react developer for a very long time, i'm generally aware of the value added by all these files. I bring up these concerns almost to say "have we added too much? is it time to think about trimming back?".
wzy 6y ago
How is it bloat if 160MB of JavaScript will never be in the production version of the app? I mean, the Basecamp team just published Hey.com with less the 50KB of JavaScript and their dev build of Rails for that project must've exceeded 160MB in `node_modules`.
- deleted 6y ago
  [deleted]

treis 6y ago

Rails 6 has become significantly more JavaScript intensive and has bought into the ecosystem. IMHO, it's a mistake and they were better off staying in their niche. Server side rendering + Turbolinks is a very compelling story and much simpler to get into than what Rails 6 is now.

sosborn 6y ago
JS in rails is entirely opt-in.
- WJW 6y ago
  Opt-in means the default is without JS and you can enable it if you want. As shown in the gist, the situation is actually that by default all the JS is installed and you have to explicitly opt-out to prevent it from being installed.
  - sosborn 6y ago
    When you create a new rails project, the tooling for JS is set up, but none of that gets used (Turbolinks the only exception) unless you write or include JS code. The tooling does not affect the user experience one bit.
- cocktailpeanuts 6y ago
  No. That's what it used to be in the old days, but not anymore. I've been away from rails for a couple of years and recently came back to build a side project. The latest rails version shoves all kinds of JS stuff down your throat, you have to literally opt out. The whole point of rails is "convention over configuration", and they have adopted the bloated NPM + Webpack ecosystem as their "convention".