4 ms·

If any of the frameworks glorified on HN were subject to the same scrutiny as Rails, Github would need a suicide hotline. I've recently had the pleasure of wor

If any of the frameworks glorified on HN were subject to the same scrutiny as Rails, Github would need a suicide hotline. I've recently had the pleasure of working on a new, medium-sized node/react project. Now I was new to a lot of the technology, but I've learned a few and would think I have some experience. It probably took me a week to get webpack running the way I wanted. The documentation is an atrocious mix of stuff that is outdated (older than 6 months) and stuff that's too new (webpack 2.0) without any indication as to the validity. There're six different ways to get hot reloading/replacement to work, with similar problems. The configuration's syntax is heavily influenced by brainfuck with a /\w/[{\[]/s thrown in for good measure. As a soothing measure, webpack doesn't complain about anything but parse errors with the configuration. The version I was using came with 12 different options to render source maps, none of which worked in chrome (since fixed). And that's just the linker. I actually had presets to search for, i. e. ["express.js" from:<date-of-last-stable-release> to:<date-of-following-alpha/beta-release>]. node_modules once managed to consume 4TB of hd space (someone managed to create a circular dependency) and even in regular use gets to the point where I'm looking for the elasticsearch plugin for ls *<x>. If you have checkouts of several versions or projects, each one will have it's own version of left_pad & friends at around 230MB (just checked with a clean install of mxstbr/react-boilerplate) with no way of deduplication. I enjoy playing with new technology (currently elm & swift) but I know that it's time "joyfully wasted" right now and don't try to justify it. There's no amount of type-safety bugs that could cost as much time as a new framework's kinks.

BurningFrog 10y ago
The most used frameworks are always the most complained about. It's an easy mistake to think that means they're the worst.
- rtpg 10y ago
  While that's true, why don't we see this sort of stuff with Django or Flask? Of course we see people complain about these tools, but my impression is that people who end up leaving those communities are rarely because of community issues (more like "I'm going to do some Go instead"-style things) Surely something is different. It's not like Django is unused...
  - goldbrick 10y ago
    Rails is at least an order of magnitude more widespread than Django/Laravel/any of its imitators. If you take a swing at any of the follow-ons, its proponents will invariably say it's just doing what Rails does. Try to imagine a "Why Django sucks" flamepost garnering anywhere near the attention that the same does for Rails... yeah, won't happen.
    - uptownJimmy 10y ago
      Rails is several percentage points more widespread than Django, but far from any order of magnitude.
- gbog 10y ago
  I always disagree with "always". I think Django and Flask in python world are used a lot, and didn't notice a flood of complains about them.
haukur 10y ago
I've been working on React projects lately and also spent a lot of time gluing together all the different libraries and setting up a proper build process via Webpack. I've also worked on Rails projects in the past, and I have to say that I prefer the modularity of being able to structure my projects according to the problem they're trying to solve. For instance, you wouldn't create a single-page app in Rails. Also, with regards to Webpack, even though it's complex, it's extremely powerful, more so than anything else I've found. It includes many ways to optimize asset bundles considerably, by splitting them up into different files, removing unused code, and of course all the usual stuff like minimizing and gzipping the assets. In comparison to Rails it also compiles way faster, by only recompiling the code that you changed. It also includes many development tools, like an auto-reloading server and even updates your webpage without a refresh (HMR). All these are things that just aren't possible in Rails without much, much more effort. Edit: I guess there's a first for everything, but I'm really confused as to why this was downvoted. If something I said is wrong or debatable, I'd be happy to hear it and discuss it.
- matt4077 10y ago
  (didn't downvote, but:) > I prefer the modularity of being able to structure my projects according to the problem they're trying to solve. For instance, you wouldn't create a single-page app in Rails. Those two sentences don't follow logically the way they appear. A project's structure has nothing to do with its functionality, which SPA is. I admit that rails is late to the SPA game, but if the new websockets (ActionCable) and API mode do what the docs say (haven't tried), there's no reason why it wouln't work nicely. For a given rails project, less than 5% of non-template code should change: create an API (one line for most projects) and... well, I can't think of anything else. The rails view architecture is also almost identical to React: a bunch of nested templates. React best-practice is a bit more insistent on modularity (small & more generic components), but a 1:1 mapping of React and rails templates is possible.
  - haukur 10y ago
    What I meant to say was that I felt Rails was too rigid for some purposes, especially creating single-page applications. It's true that Rails wasn't built with that in mind originally, but it seems that it's becoming a bit easier now (I haven't been following Rails lately and had never heard of the "API mode" you mentioned). I also know about a couple of projects using React successfully within Rails apps, but I would personally not do that if I were to start a new project today, even though I love Ruby.
hackerboos 10y ago
Documentation of Webpack is getting better. I still use Gulp but at least the Webpack docs aren't just a bunch of 'Coming soon' pages like they used to be - take a look at the comments here: (http://webpack.github.io/docs/usage.html http://webpack.github.io/docs/usage.html)
- haukur 10y ago
  I think using Webpack still requires reading a lot of source code and examples, the docs aren't quite there yet. But it seems they're improving - the last time I checked the page you linked, it was completely empty!
  - gaastonsr 10y ago
    Webpack is the worst about using React. No complains about anything else. Took me a few days to me to get it working and "kind of" understand what it was doing. That really should not be that way.
tacone 10y ago
This. Webpack is usually the biggest source of bugs and questions on any given React boilerplate. Something won't compile, circular dependencies causing the build to fail the first time, some strange bug in CSS inlining, hot reloading not reloading, etc. It's very powerful yet very hard.
aplummer 10y ago
I don't think time spent on swift is wasted, it's a fantastic language with a lot of practical application.
Illniyar 10y ago
AngularJs had/has much worse and more criticism then rails and it's much younger. Webpack, React etc... are not frameworks in the sense that Rails and AngularJs are frameworks, if you started with them and something in them is not like you like, you can use other libraries alongside them easily enough or replace them without huge sunk cost. This isn't true for Rails (Or Django, or AngularJs) which are huge frameworks that touch every part of your development process.
- matt4077 10y ago
  Well, but that's because Angular sucked. I mean, even the developers agreed and wrote something new without thinking of a new name. I wasn't neccessarily defending Rails as being "better than neutral" (although I think it is). I just felt the attitude at HN is negative to a degree that isn't objective any more, and that, to me, seems like it is less informational and more hurtful for a few people I have deep respect for.
WickyNilliams 10y ago
You jumped in the deep end without knowing how to swim. You're starting a new project, with new technologies and you tried to use the most complex stack from day 1. It's a classic mistake people make with React projects. You don't need webpack, you don't need hot reloading etc (at least not to start with), you don't need a boilerplate. Go with browserify at first. It's simple and can be migrated to webpack later. To setup browserify? browserify in.js -o out.js -t babelify And you're done! Add --debug flag for source maps. Want to setup a watcher with caching in dev for speedy builds? `npm install watchify` and swap out browserify. When you need bundle splitting, async module loading, and all the other stuff you can do with webpack, then you can easily migrate from browserify. Don't jump in the deep end without knowing how to swim.
- deleted 10y ago
  [deleted]

BurningFrog 10y ago

The most used frameworks are always the most complained about. It's an easy mistake to think that means they're the worst.

rtpg 10y ago
While that's true, why don't we see this sort of stuff with Django or Flask? Of course we see people complain about these tools, but my impression is that people who end up leaving those communities are rarely because of community issues (more like "I'm going to do some Go instead"-style things) Surely something is different. It's not like Django is unused...
- goldbrick 10y ago
  Rails is at least an order of magnitude more widespread than Django/Laravel/any of its imitators. If you take a swing at any of the follow-ons, its proponents will invariably say it's just doing what Rails does. Try to imagine a "Why Django sucks" flamepost garnering anywhere near the attention that the same does for Rails... yeah, won't happen.
  - uptownJimmy 10y ago
    Rails is several percentage points more widespread than Django, but far from any order of magnitude.
gbog 10y ago
I always disagree with "always". I think Django and Flask in python world are used a lot, and didn't notice a flood of complains about them.

haukur 10y ago

I've been working on React projects lately and also spent a lot of time gluing together all the different libraries and setting up a proper build process via Webpack. I've also worked on Rails projects in the past, and I have to say that I prefer the modularity of being able to structure my projects according to the problem they're trying to solve. For instance, you wouldn't create a single-page app in Rails. Also, with regards to Webpack, even though it's complex, it's extremely powerful, more so than anything else I've found. It includes many ways to optimize asset bundles considerably, by splitting them up into different files, removing unused code, and of course all the usual stuff like minimizing and gzipping the assets. In comparison to Rails it also compiles way faster, by only recompiling the code that you changed. It also includes many development tools, like an auto-reloading server and even updates your webpage without a refresh (HMR). All these are things that just aren't possible in Rails without much, much more effort. Edit: I guess there's a first for everything, but I'm really confused as to why this was downvoted. If something I said is wrong or debatable, I'd be happy to hear it and discuss it.

matt4077 10y ago
(didn't downvote, but:) > I prefer the modularity of being able to structure my projects according to the problem they're trying to solve. For instance, you wouldn't create a single-page app in Rails. Those two sentences don't follow logically the way they appear. A project's structure has nothing to do with its functionality, which SPA is. I admit that rails is late to the SPA game, but if the new websockets (ActionCable) and API mode do what the docs say (haven't tried), there's no reason why it wouln't work nicely. For a given rails project, less than 5% of non-template code should change: create an API (one line for most projects) and... well, I can't think of anything else. The rails view architecture is also almost identical to React: a bunch of nested templates. React best-practice is a bit more insistent on modularity (small & more generic components), but a 1:1 mapping of React and rails templates is possible.
- haukur 10y ago
  What I meant to say was that I felt Rails was too rigid for some purposes, especially creating single-page applications. It's true that Rails wasn't built with that in mind originally, but it seems that it's becoming a bit easier now (I haven't been following Rails lately and had never heard of the "API mode" you mentioned). I also know about a couple of projects using React successfully within Rails apps, but I would personally not do that if I were to start a new project today, even though I love Ruby.

hackerboos 10y ago

Documentation of Webpack is getting better. I still use Gulp but at least the Webpack docs aren't just a bunch of 'Coming soon' pages like they used to be - take a look at the comments here: (http://webpack.github.io/docs/usage.html http://webpack.github.io/docs/usage.html)

haukur 10y ago
I think using Webpack still requires reading a lot of source code and examples, the docs aren't quite there yet. But it seems they're improving - the last time I checked the page you linked, it was completely empty!
- gaastonsr 10y ago
  Webpack is the worst about using React. No complains about anything else. Took me a few days to me to get it working and "kind of" understand what it was doing. That really should not be that way.

tacone 10y ago

This. Webpack is usually the biggest source of bugs and questions on any given React boilerplate. Something won't compile, circular dependencies causing the build to fail the first time, some strange bug in CSS inlining, hot reloading not reloading, etc. It's very powerful yet very hard.

aplummer 10y ago

I don't think time spent on swift is wasted, it's a fantastic language with a lot of practical application.

Illniyar 10y ago

AngularJs had/has much worse and more criticism then rails and it's much younger. Webpack, React etc... are not frameworks in the sense that Rails and AngularJs are frameworks, if you started with them and something in them is not like you like, you can use other libraries alongside them easily enough or replace them without huge sunk cost. This isn't true for Rails (Or Django, or AngularJs) which are huge frameworks that touch every part of your development process.

matt4077 10y ago
Well, but that's because Angular sucked. I mean, even the developers agreed and wrote something new without thinking of a new name. I wasn't neccessarily defending Rails as being "better than neutral" (although I think it is). I just felt the attitude at HN is negative to a degree that isn't objective any more, and that, to me, seems like it is less informational and more hurtful for a few people I have deep respect for.

WickyNilliams 10y ago

You jumped in the deep end without knowing how to swim. You're starting a new project, with new technologies and you tried to use the most complex stack from day 1. It's a classic mistake people make with React projects. You don't need webpack, you don't need hot reloading etc (at least not to start with), you don't need a boilerplate. Go with browserify at first. It's simple and can be migrated to webpack later. To setup browserify? browserify in.js -o out.js -t babelify And you're done! Add --debug flag for source maps. Want to setup a watcher with caching in dev for speedy builds? `npm install watchify` and swap out browserify. When you need bundle splitting, async module loading, and all the other stuff you can do with webpack, then you can easily migrate from browserify. Don't jump in the deep end without knowing how to swim.

deleted 10y ago
[deleted]