8 ms·

I'm no Javascript Boilerplate Fatigue apologist, but there are many comments in here that are treating this as a "Learn how to use React" tutorial. This is not

by swanson 10y ago

I'm no Javascript Boilerplate Fatigue apologist, but there are many comments in here that are treating this as a "Learn how to use React" tutorial. This is not what is advertised nor the stated reason this article was written. From the first sentence: "we get a lot of questions about how to build large applications with React and how to integrate external APIs" Large application strucutre, external integrations...not "Hello World" Of course there is no need for multiple environments, or a robust testing setup, or an icon font, or 6 different webpack loaders to learn the basics of React. This is not a tutorial on the basics of React -- this is written from the perspective of a large production level application. And that "overhead" and "insanity" are helpful for real projects that are staffed by more than one person and need to last more than a week. It seems absurd that it might take you 2 hours to setup the environment before you get to hello world. But if you are planning to use this as the foundation of a 6 month long project, 2 hours to get everything setup in a sane way is not an issue. There is absolutely churn in the JS world and some of it does seem unbelievable because things haven't contracted and settled into a steady-state. But don't just levy a blanket "lol fuck javascript tooling" every time you see a complicated setup process; you are doing yourself a disservice by not critically evaluating the choices the author of this post made and determining for yourself if they will benefit your project and/or learning efforts.

MatthewPhillips 10y ago
A large setup cost discourages you from creating many small projects; from creating experiments that may/may not pan out. This is why the browser/text editor flow of development will (eventually) win out. Hopefully people working in these toolchains are at least using some boilerplate projects or generators that cover 90% of cases.
fbonetti 10y ago
The problem with the massive amount of churn is that it just doesn't pay off to learn the new, cool thing when it's going to be obsolete in 3 months or less. I think all programmers, especially ones who read HN, like to learn new things. It's fun to pick up new languages, learn new paradigms, and experiment with different technologies. What's not fun is learning 10 different ways to handle promises, 4 different build tools, several frameworks, and dozens of new libraries over the course of a year just to keep up. By the time you reach a level of mastery over one of these tools, it's already been replaced by something else! I mean it's great that the tools are getting better, but it's really painful to deal with the constant churn. /rant
- pavel_lishin 10y ago
  Especially when even this article points out that webpack is difficult to set up, and basically requires a helper tool.
- danenania 10y ago
  The solution is not trying so hard to keep up. Keep your ears open for the major improvements that rise above the noise, but don't feel like you have to be on the cutting edge. Much of the cutting edge is (almost by definition) misguided or overcomplicated. The sweet spot if your goal is to actually build something is taking whatever architecture is currently hip and throwing out about 2/3 of it in exchange for a simpler approach. Then circle back for the fancier libraries a few months later if and when you have a need for them.
- george_soros 10y ago
  I hear you. Web Assembly just might save us all from this ridiculous JS drive to re-invent things. Pick a language you like to work with on the server side, learn the current best framework for the client side in that language and be happy ever after with enough free time for gardening and feeding goats.
- rtpg 10y ago
  >it just doesn't pay off to learn the new, cool thing when it's going to be obsolete in 3 months or less. Does this actually happen? If you had learned Angular way back, you would still be in a comfortable situation. New stuff coming in, but it's compatible with the old stuff. Same with React. Had you learned react when it was talked about, you would have gotten, what, at least 2 years worth of value by now? And a lot of the build tools are independent of the tech. Grunt is still fine to use, and people release plugins for it all the time. And here's the last thing: You don't have to spend 6 months to learn a thing. If you want to keep up, read about it for 15 minutes? That should be enough most of the time to get the philosophical differences between tools you know. And if it does intrigue you enough, engage with it. This stuff is progress, if we went the other way we'd still be writing jQuery spaghetti code and having state integrity issues up the wazzoo from callback hell. You don't have to ride every train, but you can at least look at them as they go by.
tlrobinson 10y ago
I'm a fan of projects like https://github.com/petehunt/rwb https://github.com/petehunt/rwb It's a little opinionated but aligns well with the decisions I independently made after spending way too much time on "build tool bullshit". That said, it's a little rough around the edges and development is not very active.
alexquez 10y ago
I agree. We've started a project at work that we will maintain for years. We researched the setup for a few weeks and continue to tune it. Once you understand the small components and create a working setup reacct/webpack/babel is much less daunting. This type of article is great when you're trying to ensure you've chosen the most optimal setup for your project yet it isn't for everyone.
Cyph0n 10y ago
I have no problem with the article or its goals, but my issue is why is so much configuration even necessary for a "large" frontend JS application? Why don't we see this kind of configuration hell in other major languages? Look at Python, or Scala, or Go, or even Rust. Do you see projects requiring 10 dependencies just to setup a testing environment? Or having to manually integrate every piece of the build process instead of using pre-made plugins? We don't even have to talk about the extremely low average lifetime of libraries in the JS world; it's like a perpetual popularity contest!
- JustSomeNobody 10y ago
  > We don't even have to talk about the extremely low average lifetime of libraries in the JS world; it's like a perpetual popularity contest! This is the awful truth of programming in general today. Sadly, it's a train not many of us can jump off of because of employ-ability. If popular tool/framework/language/etc is not on your resume, you're not getting called back. If popular tool/framework/language/etc is not being used by anything in your Github, you're not getting called back.
  - Cyph0n 10y ago
    Definitely true in general, but I think it's more noticeable in the JS world. Look at Java + Spring, C# + ASP.NET, Python + Django, Ruby + Rails: these are all examples of popular frameworks that have been around for much longer than any single JS library (except jQuery), and are all still in high demand.
    - tracker1 10y ago
      I believe ASP.Net and Spring predate jQuery.
  - cloudjacker 10y ago
    This is primarily a JS thing. Many nontechnical people that look over your resume don't know that Node Backbone React Angular and the random data visualization libraries are all "Javascript"
jimmytucson 10y ago
Sorry, but even the “Getting Started” guide on React's website requires that you have a "CommonJS module system" installed which, if you don't, means you have to make an intelligent choice between Browserify and webpack, which means you have to do some minimal research into what those are (and probably research "babel-js", while you're at it), install one of them using npm, which may require that you install or upgrade node.js which, if you're on a Mac, may require that you install homebrew, which can sometimes open another, deeper can of worms... And that's just to get your tool chain in place. When you actually get into the tutorial, it starts with "Running a server". Running a server? I submit that writing even basic, toy applications in React requires a trip to dependency hell and back, unless you already use these tools on a regular basis and keep up with the ever-rapidly-changing debate around build scripts, dependency managers, language preprocessors, etcetera, etcetera.
- foota 10y ago
  Any language or environment has it's hoops that you have to jump through in order to use it, in some cases these happen to be installed for you so it's less noticeable.
- deleted 10y ago
  [deleted]
- swanson 10y ago
  I'm looking here: https://facebook.github.io/react/docs/getting-started.html https://facebook.github.io/react/docs/getting-started.html And seeing a JSFiddle link that is fully configured to work and zip file that includes all necessary files. What am I missing?
  - joesb 10y ago
    the first line of HTML code in that Fiddle link is: https://facebook.github.io/react/js/jsfiddle-integration-babel.js https://facebook.github.io/react/js/jsfiddle-integration-bab... What you are missing is that you probably don't want to develop by putting your code in JSFiddle.
  - 10y ago
findjashua 10y ago
react needs something like the ember-cli
szines 10y ago
There is a nice tutorial which is about building huge application in Ember.js. Totally free and easy to follow. Check it out. http://yoember.com http://yoember.com
greenspot 10y ago
Well said. I like programming, I like different languages. Just few days ago I was once again lurking on other languages' sites and forums just to find something new. I realized when looking at other languages that JS has come a far way and now offers so much that I really like JS. I got spoiled and the urge to try, find and need something better has faded. The language itself made huge leaps with ES6 and the ecosystem is just incredible. I see that fast pace as something positive and the 'JS churn' is relative or rather exaggerated. Node itself is very stable and new versions do not break old stuff in general. Grunt and Gulp got replaced by Webpack, React + Redux redefine UI. That's it, these are the typical examples in mind when people talk about 'churn', not really a lot to be worried about. And these changes didn't happen over night but over years, e.g. the first React version was introduced two or three years ago. A counter example to churn: Express is still the to-go web app server for many years (5?), it's doesn't have the most modern foundation and other stuff (e.g. http2 is problematic) . I wish that new web app servers like Koa, Express' successor, would gain more traction but that happens only slowly.

by swanson 10y ago

MatthewPhillips 10y ago

A large setup cost discourages you from creating many small projects; from creating experiments that may/may not pan out. This is why the browser/text editor flow of development will (eventually) win out. Hopefully people working in these toolchains are at least using some boilerplate projects or generators that cover 90% of cases.

fbonetti 10y ago

The problem with the massive amount of churn is that it just doesn't pay off to learn the new, cool thing when it's going to be obsolete in 3 months or less. I think all programmers, especially ones who read HN, like to learn new things. It's fun to pick up new languages, learn new paradigms, and experiment with different technologies. What's not fun is learning 10 different ways to handle promises, 4 different build tools, several frameworks, and dozens of new libraries over the course of a year just to keep up. By the time you reach a level of mastery over one of these tools, it's already been replaced by something else! I mean it's great that the tools are getting better, but it's really painful to deal with the constant churn. /rant

pavel_lishin 10y ago
Especially when even this article points out that webpack is difficult to set up, and basically requires a helper tool.
danenania 10y ago
The solution is not trying so hard to keep up. Keep your ears open for the major improvements that rise above the noise, but don't feel like you have to be on the cutting edge. Much of the cutting edge is (almost by definition) misguided or overcomplicated. The sweet spot if your goal is to actually build something is taking whatever architecture is currently hip and throwing out about 2/3 of it in exchange for a simpler approach. Then circle back for the fancier libraries a few months later if and when you have a need for them.
george_soros 10y ago
I hear you. Web Assembly just might save us all from this ridiculous JS drive to re-invent things. Pick a language you like to work with on the server side, learn the current best framework for the client side in that language and be happy ever after with enough free time for gardening and feeding goats.
rtpg 10y ago
>it just doesn't pay off to learn the new, cool thing when it's going to be obsolete in 3 months or less. Does this actually happen? If you had learned Angular way back, you would still be in a comfortable situation. New stuff coming in, but it's compatible with the old stuff. Same with React. Had you learned react when it was talked about, you would have gotten, what, at least 2 years worth of value by now? And a lot of the build tools are independent of the tech. Grunt is still fine to use, and people release plugins for it all the time. And here's the last thing: You don't have to spend 6 months to learn a thing. If you want to keep up, read about it for 15 minutes? That should be enough most of the time to get the philosophical differences between tools you know. And if it does intrigue you enough, engage with it. This stuff is progress, if we went the other way we'd still be writing jQuery spaghetti code and having state integrity issues up the wazzoo from callback hell. You don't have to ride every train, but you can at least look at them as they go by.

tlrobinson 10y ago

I'm a fan of projects like https://github.com/petehunt/rwb https://github.com/petehunt/rwb It's a little opinionated but aligns well with the decisions I independently made after spending way too much time on "build tool bullshit". That said, it's a little rough around the edges and development is not very active.

alexquez 10y ago

I agree. We've started a project at work that we will maintain for years. We researched the setup for a few weeks and continue to tune it. Once you understand the small components and create a working setup reacct/webpack/babel is much less daunting. This type of article is great when you're trying to ensure you've chosen the most optimal setup for your project yet it isn't for everyone.

Cyph0n 10y ago

I have no problem with the article or its goals, but my issue is why is so much configuration even necessary for a "large" frontend JS application? Why don't we see this kind of configuration hell in other major languages? Look at Python, or Scala, or Go, or even Rust. Do you see projects requiring 10 dependencies just to setup a testing environment? Or having to manually integrate every piece of the build process instead of using pre-made plugins? We don't even have to talk about the extremely low average lifetime of libraries in the JS world; it's like a perpetual popularity contest!

JustSomeNobody 10y ago
> We don't even have to talk about the extremely low average lifetime of libraries in the JS world; it's like a perpetual popularity contest! This is the awful truth of programming in general today. Sadly, it's a train not many of us can jump off of because of employ-ability. If popular tool/framework/language/etc is not on your resume, you're not getting called back. If popular tool/framework/language/etc is not being used by anything in your Github, you're not getting called back.
- Cyph0n 10y ago
  Definitely true in general, but I think it's more noticeable in the JS world. Look at Java + Spring, C# + ASP.NET, Python + Django, Ruby + Rails: these are all examples of popular frameworks that have been around for much longer than any single JS library (except jQuery), and are all still in high demand.
  - tracker1 10y ago
    I believe ASP.Net and Spring predate jQuery.
- cloudjacker 10y ago
  This is primarily a JS thing. Many nontechnical people that look over your resume don't know that Node Backbone React Angular and the random data visualization libraries are all "Javascript"

jimmytucson 10y ago

Sorry, but even the “Getting Started” guide on React's website requires that you have a "CommonJS module system" installed which, if you don't, means you have to make an intelligent choice between Browserify and webpack, which means you have to do some minimal research into what those are (and probably research "babel-js", while you're at it), install one of them using npm, which may require that you install or upgrade node.js which, if you're on a Mac, may require that you install homebrew, which can sometimes open another, deeper can of worms... And that's just to get your tool chain in place. When you actually get into the tutorial, it starts with "Running a server". Running a server? I submit that writing even basic, toy applications in React requires a trip to dependency hell and back, unless you already use these tools on a regular basis and keep up with the ever-rapidly-changing debate around build scripts, dependency managers, language preprocessors, etcetera, etcetera.

foota 10y ago
Any language or environment has it's hoops that you have to jump through in order to use it, in some cases these happen to be installed for you so it's less noticeable.
deleted 10y ago
[deleted]
swanson 10y ago
I'm looking here: https://facebook.github.io/react/docs/getting-started.html https://facebook.github.io/react/docs/getting-started.html And seeing a JSFiddle link that is fully configured to work and zip file that includes all necessary files. What am I missing?
- joesb 10y ago
  the first line of HTML code in that Fiddle link is: https://facebook.github.io/react/js/jsfiddle-integration-babel.js https://facebook.github.io/react/js/jsfiddle-integration-bab... What you are missing is that you probably don't want to develop by putting your code in JSFiddle.
- 10y ago

findjashua 10y ago

react needs something like the ember-cli

szines 10y ago

There is a nice tutorial which is about building huge application in Ember.js. Totally free and easy to follow. Check it out. http://yoember.com http://yoember.com

greenspot 10y ago

Well said. I like programming, I like different languages. Just few days ago I was once again lurking on other languages' sites and forums just to find something new. I realized when looking at other languages that JS has come a far way and now offers so much that I really like JS. I got spoiled and the urge to try, find and need something better has faded. The language itself made huge leaps with ES6 and the ecosystem is just incredible. I see that fast pace as something positive and the 'JS churn' is relative or rather exaggerated. Node itself is very stable and new versions do not break old stuff in general. Grunt and Gulp got replaced by Webpack, React + Redux redefine UI. That's it, these are the typical examples in mind when people talk about 'churn', not really a lot to be worried about. And these changes didn't happen over night but over years, e.g. the first React version was introduced two or three years ago. A counter example to churn: Express is still the to-go web app server for many years (5?), it's doesn't have the most modern foundation and other stuff (e.g. http2 is problematic) . I wish that new web app servers like Koa, Express' successor, would gain more traction but that happens only slowly.