8 ms·

To me this epitomizes what I feel as I'm trying to explore options for different front-end frameworks. In this article I'm 30 screens down (literally 30 page do

by eterm 10y ago

To me this epitomizes what I feel as I'm trying to explore options for different front-end frameworks. In this article I'm 30 screens down (literally 30 page down presses) and it's not even finished setting up the environment and dependencies. Sure, this is something that you only do once, so if it then leads to much better development workflow it makes sense to have a solid investment upfront, but it makes it very hard to compare technologies and make informed decisions given how much up-front "glue" is needed to get a demo application up and running. I'm not blaming react, everything else in the javascript space is just as bad right now. There's at least 4 different ways of loading modules (UMD, AMD, commonJS, es (babel) modules), 2 of which (require(), import .. from) are used within this example. In fact the whole process is so complex part of the process is "clone this package which has pre-configured parts of the process". And all of this to glue together a couple of APIs.

Omnipresent 10y ago
Is Angular2 any better in terms of dependency hell since it provides a full stack front end solution?
sotojuan 10y ago
This is a pet peeve of mine when it comes to React tutorials. Why waste so much time making the user set up a dev environment? Just give him/her a prebuilt and "black boxed" environment and get on with learning React (what they actually want to do). I've seen plenty of people give up because they couldn't get their webpack set up right. Also, for those making courses, consider just using browserify. It's much easier on the newbies. > I'm not blaming react, everything else in the javascript space is just as bad right now. Not Ember! A great example of a blackboxed, prebuilt build system that gets out of the way.
- enraged_camel 10y ago
  >>This is a pet peeve of mine when it comes to React tutorials. Why waste so much time making the user set up a dev environment? Just give him/her a prebuilt and "black boxed" environment and get on with learning React And yet one of the most common criticisms of Rails is that it's too black-box and has too much "magic." So you're damned if you do, damned if you don't.
  - antimatter 10y ago
    Rails is the actual framework. I can see why someone would hate the magic happening under the hood when attempting to get something done in Rails. When it comes to React, we're talking about the dev environment. I would love never having to configure webpack by myself ever again. Something like the rails scaffolding command would be excellent for working on React apps. I believe Ember has ember-cli to do this.
- SethKinast 10y ago
  I think this is somewhat of a deceptive trap that people fall into. It's difficult to trial something like React unless you set up all the tooling around it, so Ember appears easier because it is blackboxed and sets things up for you. However, that means that six months in, when your app has outgrown the constraints of the blackboxed starter, you are trapped. There is absolutely more of a startup cost to something like React and that makes it hard to evaluate its fit for your project, but I would suggest it pays ridiculous dividends to understand the stack you're going to have to maintain for the next X years instead of having it hidden away from you.
  - tomdale 10y ago
    You will find that Ember and Ember CLI are built on top of well-architected primitives; it's not that these things are hidden, it's just that understanding them isn't required to get started.
    - mixonic 10y ago
      Seems like poor punishment to downvote Tom here. At the worst he made a blanket statement without backing it up, which is the exact same as what he was responding to. > I think this is somewhat of a deceptive trap that people fall into. It's difficult to trial something like React unless you set up all the tooling around it, so Ember appears easier because it is blackboxed and sets things up for you. > However, that means that six months in, when your app has outgrown the constraints of the blackboxed starter, you are trapped. I have not seen a single company outgrow Ember-CLI. Imagine for a moment a big company with a huge app- Yahoo or LinkedIn or Twitch. These companies have apps that push the limits of Ember-CLI for sure, and have delved into the internals to add cutting edge features like lazy loading or optimized module loading, however none of them have abandoned it after six months. Ember CLI has a public API for making changes to your build pipeline. Advanced users often reach for direct manipulation of Broccoli trees, another open source documented API with lots of example usage floating around. The "black box" referenced is non-existent. Ember-CLI is more like a car with a good manual. You don't need to understand fuel injection timing to get it out of the garage. And Ember-CLI is fast. Out of the box it has great performance on Windows, Linux and OSX and there is even more room for improvement. Six months down the road, you will not find out it takes five seconds to rebuild your app. It will still be sub-second. > it pays ridiculous dividends to understand the stack you're going to have to maintain for the next X years instead of having it hidden away from you. We share software (proprietary or open) because it spreads the cost of maintenance. As a web developer I have plenty of work already, maintaining my own build pipeline is no more desirable than maintaining my own rendering engine or my own operating system. We always solve problems atop a certain level of abstraction. Ember-CLI is the result of a concerted effort by individuals and the community that started in 2013. The project is clearly a massive success, demonstrated by its overwhelming adoption by Ember users (well over 90%, it isn't that popular because it sucks). It is a disservice to Ember-CLI to blow it off as "not scaling past six months" and to yourself as a developer to disregard Ember-CLI's hard-won lessons about how to build a good common build pipeline. tl;dr please don't presume Ember-CLI is flawed because it "appears easy", making the hard look easy is a worthy goal. [edit]: formatting :-p
mkohlmyr 10y ago
Completely agreed. I had the same frustrations when I was looking at things like meteor, angular, etc and I definitely got that vibe when I saw this page. And I am saying that as someone who has already built websites with React. I really don't know that it needs to be (or feel) this complicated If it's a React tutorial it shouldn't require people to navigate through Karma, Webpack and Postcss, not least of all because they may already be comfortable using perfectly serviceable alternatives.
- pauljohncleary 10y ago
  > the same frustrations when I was looking at things like meteor The main strength of Meteor is the speed you can get up and running $ meteor create my-app-name $ meteor npm install $ meteor will set you up with a full stack application, running locally, with zero config
  - zxcvcxz 10y ago
    The thing is with Meteor I feel like I have to learn ALL of meteor to really expand/extend upon what it gives me or use some plugin, it feels like it takes away way too much control for me. With Angular I feel like I have to re-learn web development and do everything the "angular way", and who knows when Angular three comes out and the "Angular way" completely changes. With React, I can learn a small framework that's highly extensible and basically pure javascript. I don't feel like I have to re-learn everything I know about web-dev when using react like I do with Angular. Angular and Meteor try to do too much, this is why react is winning the framework wars.
    - pauljohncleary 10y ago
      Fair point, recent updates to Meteor (1.3) have made it much easier to use with the rest of the JS ecosystem (e.g. using react with meteor is as easy as using the default view library). The reason you have all of this boilerplate setup with react is because it's only one small part of the equation, so you need to use and (ideally) understand a bunch of other libraries and tools to build something, hence these epic tutorials.
teen 10y ago
You could def skip some of these steps though. Postcss seems like solution without a problem imo. Sass seems a bit saner. And you can skip the tests for most projects.
zxcvcxz 10y ago
>I'm 30 screens down (literally 30 page down presses) If this web page were a book it would be about 30 pages. What framework is there that allows you to build full scale web-apps in less time? Certainly not Angular, an Angular tutorial would be at least twice as long and you wouldn't even use half the features of Angular. Meteor? Sure, but meteor isn't a good choice for people who need a lot of control of what's going on under the hood.
swanson 10y ago
I've shared your frustration. The Hello World experience is a huge spectrum ranging from the 30 screens of setup you describe to the one-click Visual Studio installer. The other thing to consider is what you assume from a reader in a tutorial. If you assume they have a full environment setup (or will be following another tutorial), you can put together a much more concise article. Imagine the now-classic Rails Blog in 15 minutes screencast. For those at home -- even if you assume a unix-y environment -- you might have tutorial setup that looks like this: * Install homebrew/update package manager * Install ruby-build * Install rbenv * Install ruby-2.3 * Install git * Create a git repository * Install bundler * Create a Gemfile that includes rails * bundle install * Install rails * Install postgres via homebrew * Setup postgres database * Install javascript runtime (nodejs or ruby-racer) * finally run `rails s` to see the blank hello world page Sometimes there are a lot of steps involved in a full end-to-end guide. And sometimes we forget all the baked in knowledge and setup we had to do for our preferred tools/stacks that we are having to go through again as part of learning a new technology.
- pbreit 10y ago
  But wouldn't it just be: * install rails * run 'rails s'
  - bdcravens 10y ago
    If you've already setup Ruby, which most haven't if they're going through a similar tutorial for Rails.
    - pbreit 10y ago
      Well, Ruby is pre-installed on Mac OS.
      - bdcravens 10y ago
        I've never come across a single Ruby tutorial or talk or anything that suggests using system Ruby. For many good reasons. https://robots.thoughtbot.com/psa-do-not-use-system-ruby https://robots.thoughtbot.com/psa-do-not-use-system-ruby
atom-morgan 10y ago
> In this article I'm 30 screens down (literally 30 page down presses) and it's not even finished setting up the environment and dependencies. I'm writing a tutorial right now for testing AngularJS and this is exactly what I'm running into. It's a tutorial but half of my first part is "install this, put this line in this configuration file, install this, add this one here, etc." It's easy to feel like I'm not writing a good tutorial but really that's just the current state of JS development.
- askldfhjkasfhd 10y ago
  I'm way out of my league, but would it be possible to distribute a Docker container with all the boilerplate? Tutorial users could run that at the start, then do the "fun stuff".
lucideer 10y ago
It's literally 93 page-downs to the "Hello world" On the upside, it all seems clear (if somewhat laborious to go through in totality) and I definitely appreciate that the majority of those 93 page-downs were covering setting up testing and a testing strategy + framework. It seems most things of this type are more likely to either say "set up testing" without detail, OR are guides specifically for doing testing without going into great detail about the app being tested.
- moogleii 10y ago
  Huh? The first "hello world" equivalent occurs in the beginning. https://www.fullstackreact.com/articles/react-tutorial-cloning-yelp/#demo-basic-appjs https://www.fullstackreact.com/articles/react-tutorial-cloni...
  - lucideer 10y ago
    That's the first time he prints anything to screen, but the actual first "Hello world" text is at the beginning of the Routing section where he's just finished all initial boilerplate and testing setup and puts in his first route. Which is a little more representative. I think it's a good guide btw.
    - moogleii 10y ago
      I guess it depends what one thinks is representative of a hello world. His first print out of the literal "hello world" may be down that far, but in terms of "classical" hello world "standards" (just based off what hello world apps have traditionally looked like), the section I linked is more analogous in my opinion. It shows react operational and rendering. If the bar is a yelp clone (which is already contrary to what a hello world is), then sure, maybe page 93 is more apt. But...you're building a yelp clone.
      - lucideer 10y ago
        My thinking was the bar would be "first output after boilerplate setup", in this case immediately before beginning to write any yelp-ish logic.
leoalves 10y ago
I also share your frustration. I am learning react. A few weeks ago I wrote a small app and based my work from a starterkit with a few thousand stars on github. I learned a lot from this app and the starterkit. This week I decided to use what I learned at work, writing a small app that will be used only internally. When I cloned the same project at least 15-20% of the project was different. Not just is a pain to set up a project but it's also changing very fast.
mercer 10y ago
I feel the same frustration even though I am still at a point where I generally have a huge tolerance for this kind of stuff. Slowly, however, things seem to be improving. For one, Redux seems to be the preferred 'flux implementation'; that's an improvement over the countless implementations I had to choose from when I started about a year or two ago. Then there are Rich Harris' Buble[1] and Rollup[2], which provide respectively batteries-included ES2015 transpiling and module bundling, and probably a bunch of other projects I'm not aware of that provide some sort of standardization or simplification in this process. It's not happening as fast as I'd like, but it seems to be a move in the right direction. [1]: https://gitlab.com/Rich-Harris/buble https://gitlab.com/Rich-Harris/buble [2]: http://rollupjs.org/ http://rollupjs.org/
dceddia 10y ago
This was the first thing I noticed as well. 40% of the tutorial is setup. It doesn't HAVE to be that painful just to get a working environment going, but it gets painful pretty quickly if you pile on Webpack and PostCSS and a testing setup and everything. For true "Hello World", if all you just want is to play around with React without all the setup, try out quik[0] or react-heatpack[1]. I also wrote up a tutorial[2] using react-heatpack that gets a working Hello World in UNDER 3 page-downs :) [0] https://www.npmjs.com/package/quik https://www.npmjs.com/package/quik [1] https://www.npmjs.com/package/react-heatpack https://www.npmjs.com/package/react-heatpack [2] https://daveceddia.com/test-drive-react/ https://daveceddia.com/test-drive-react/
fbonetti 10y ago
This is why I'm so gung ho about Elm. To create a proper React single page app, you need React, Redux, lodash, react-router, webpack, Immutable.js, babel, npm, redux-thunk, isomorphic-fetch, webpack-hot-middleware, and ton of boilerplate and configuration (which everyone does differently). You can try to assemble this yourself, or choose one of hundreds of starter projects on Github. A comparable Elm app is a lot simpler. It consists of Elm, a router such as elm-transit-router, and maybe webpack if you want to watch and minify your compiled javascript. Especially now with the new 0.17, Elm forces you to use the standard Elm Architecture, so you don't waste any time thinking about how to structure your app and there's very little boilerplate as a result. On top of this, Elm is statically typed, functional, and simply a joy to work with.
- moogleii 10y ago
  I've no doubt Elm is simpler (considering it's more vertically integrated), but to be fair, if webpack is a maybe in Elm, lodash, immutable, isomorphic fetch, and webpack-hot-middleware would definitely be on my maybe list for React. Maybe maybes would include redux-thunk.
  - callahad 10y ago
    Vertical integration plays a part with blessed libraries for rendering, routing, and requests, but it's not just vertical integration: Elm completely obviates Immutable.js, TypeScript, Reselect, Redux-Thunk, and Lodash/Ramda by virtue of fundamental language design choices. The same goes for Haskell, OCaml, and PureScript. In that context, Redux becomes a design pattern, rather than a library. Ultimately, it feels like React's best practices and associated libraries try to bludgeon JavaScript into acting like a functional, immutable language. If that's the right model, I'd rather just use a language that was intentionally designed to be functional and immutable from the start. :)
    - aidos 10y ago
      Can you embed an existing js app (angular) with Elm? Doesn't need to be any real communication between them. Just have the Elm app decide if the angular app is displayed or not. Honest question as I'm embedding angular in react at the moment and there's quite a lot of library fatigue going on.
novembermike 10y ago
If you want to put together an Ikea chair, everything is in the box and the instructions are two pages long. If you want to put together a chair from scratch then you need the wood, hammers, nails, saws, a lathe, sandpaper (in multiple levels of coarseness), glue and a number of other tools. React is a lathe in this example, it's hard to put it in context without the rest of the tools but that doesn't make it complex.
romaniv 10y ago
>I'm not blaming react, everything else in the javascript space is just as bad right now. There's at least 4 different ways of loading modules (UMD, AMD, commonJS, es (babel) modules), 2 of which (require(), import .. from) are used within this example. Personally, I got so frustrated with ever-increasing complexity of tools and growing networks of dependencies that whenever I can I try to package my JS code in self-contained modules/files that depend on nothing -- not even on one another. Needless to say, it's not an approach that's very popular, but it works remarkably well for websites of moderate complexity. One thing I'm sure of: using those modules feels far more satisfying than using a framework.
- softawre 10y ago
  Sounds very anti-DRY, though I get where you are coming from.
  - romaniv 10y ago
    As far as DRY, the worst aspect of no-dependencies approach is dealing with AJAX. The rest of it is actually not that bad. After some experimentation, I separated the functionality into "behaviors", which are fairly reusable across different pages and projects.
sergiotapia 10y ago
Screw this, use Meteor to build React apps. It's super smooth, no BS, and integrates everything that sucks about Javascript development into a cohesive Omakase package.
gedy 10y ago
> I'm not blaming react, No, React is particularly bad here. RactiveJS for example can be used in a minute: http://www.ractivejs.org/60-second-setup http://www.ractivejs.org/60-second-setup
twohearted 10y ago
The real gut punch is many parts of this tutorial will probably be obsolete within six months. Fast forward a couple years and this will look like the equivalent of "Backbonejs tutorial - Step 1: bower install requirejs". Sometimes I feel bad complaining about this. Things are evolving fast for a reason. Everyone is trying to make every part of this process better. The backbone joke above illustrates the point. Would you go back in time and freeze the evolution just to regain sanity for today's devs?
shriphani 10y ago
Concision is an art-form. In clojure I would do: * lein new figwheel hello-world And done. Say lein isn't installed, it is a simple script you download and run once.

by eterm 10y ago

Omnipresent 10y ago

Is Angular2 any better in terms of dependency hell since it provides a full stack front end solution?

sotojuan 10y ago

This is a pet peeve of mine when it comes to React tutorials. Why waste so much time making the user set up a dev environment? Just give him/her a prebuilt and "black boxed" environment and get on with learning React (what they actually want to do). I've seen plenty of people give up because they couldn't get their webpack set up right. Also, for those making courses, consider just using browserify. It's much easier on the newbies. > I'm not blaming react, everything else in the javascript space is just as bad right now. Not Ember! A great example of a blackboxed, prebuilt build system that gets out of the way.

enraged_camel 10y ago
>>This is a pet peeve of mine when it comes to React tutorials. Why waste so much time making the user set up a dev environment? Just give him/her a prebuilt and "black boxed" environment and get on with learning React And yet one of the most common criticisms of Rails is that it's too black-box and has too much "magic." So you're damned if you do, damned if you don't.
- antimatter 10y ago
  Rails is the actual framework. I can see why someone would hate the magic happening under the hood when attempting to get something done in Rails. When it comes to React, we're talking about the dev environment. I would love never having to configure webpack by myself ever again. Something like the rails scaffolding command would be excellent for working on React apps. I believe Ember has ember-cli to do this.
SethKinast 10y ago
I think this is somewhat of a deceptive trap that people fall into. It's difficult to trial something like React unless you set up all the tooling around it, so Ember appears easier because it is blackboxed and sets things up for you. However, that means that six months in, when your app has outgrown the constraints of the blackboxed starter, you are trapped. There is absolutely more of a startup cost to something like React and that makes it hard to evaluate its fit for your project, but I would suggest it pays ridiculous dividends to understand the stack you're going to have to maintain for the next X years instead of having it hidden away from you.
- tomdale 10y ago
  You will find that Ember and Ember CLI are built on top of well-architected primitives; it's not that these things are hidden, it's just that understanding them isn't required to get started.
  - mixonic 10y ago
    Seems like poor punishment to downvote Tom here. At the worst he made a blanket statement without backing it up, which is the exact same as what he was responding to. > I think this is somewhat of a deceptive trap that people fall into. It's difficult to trial something like React unless you set up all the tooling around it, so Ember appears easier because it is blackboxed and sets things up for you. > However, that means that six months in, when your app has outgrown the constraints of the blackboxed starter, you are trapped. I have not seen a single company outgrow Ember-CLI. Imagine for a moment a big company with a huge app- Yahoo or LinkedIn or Twitch. These companies have apps that push the limits of Ember-CLI for sure, and have delved into the internals to add cutting edge features like lazy loading or optimized module loading, however none of them have abandoned it after six months. Ember CLI has a public API for making changes to your build pipeline. Advanced users often reach for direct manipulation of Broccoli trees, another open source documented API with lots of example usage floating around. The "black box" referenced is non-existent. Ember-CLI is more like a car with a good manual. You don't need to understand fuel injection timing to get it out of the garage. And Ember-CLI is fast. Out of the box it has great performance on Windows, Linux and OSX and there is even more room for improvement. Six months down the road, you will not find out it takes five seconds to rebuild your app. It will still be sub-second. > it pays ridiculous dividends to understand the stack you're going to have to maintain for the next X years instead of having it hidden away from you. We share software (proprietary or open) because it spreads the cost of maintenance. As a web developer I have plenty of work already, maintaining my own build pipeline is no more desirable than maintaining my own rendering engine or my own operating system. We always solve problems atop a certain level of abstraction. Ember-CLI is the result of a concerted effort by individuals and the community that started in 2013. The project is clearly a massive success, demonstrated by its overwhelming adoption by Ember users (well over 90%, it isn't that popular because it sucks). It is a disservice to Ember-CLI to blow it off as "not scaling past six months" and to yourself as a developer to disregard Ember-CLI's hard-won lessons about how to build a good common build pipeline. tl;dr please don't presume Ember-CLI is flawed because it "appears easy", making the hard look easy is a worthy goal. [edit]: formatting :-p

mkohlmyr 10y ago

Completely agreed. I had the same frustrations when I was looking at things like meteor, angular, etc and I definitely got that vibe when I saw this page. And I am saying that as someone who has already built websites with React. I really don't know that it needs to be (or feel) this complicated If it's a React tutorial it shouldn't require people to navigate through Karma, Webpack and Postcss, not least of all because they may already be comfortable using perfectly serviceable alternatives.

pauljohncleary 10y ago
> the same frustrations when I was looking at things like meteor The main strength of Meteor is the speed you can get up and running $ meteor create my-app-name $ meteor npm install $ meteor will set you up with a full stack application, running locally, with zero config
- zxcvcxz 10y ago
  The thing is with Meteor I feel like I have to learn ALL of meteor to really expand/extend upon what it gives me or use some plugin, it feels like it takes away way too much control for me. With Angular I feel like I have to re-learn web development and do everything the "angular way", and who knows when Angular three comes out and the "Angular way" completely changes. With React, I can learn a small framework that's highly extensible and basically pure javascript. I don't feel like I have to re-learn everything I know about web-dev when using react like I do with Angular. Angular and Meteor try to do too much, this is why react is winning the framework wars.
  - pauljohncleary 10y ago
    Fair point, recent updates to Meteor (1.3) have made it much easier to use with the rest of the JS ecosystem (e.g. using react with meteor is as easy as using the default view library). The reason you have all of this boilerplate setup with react is because it's only one small part of the equation, so you need to use and (ideally) understand a bunch of other libraries and tools to build something, hence these epic tutorials.

teen 10y ago

You could def skip some of these steps though. Postcss seems like solution without a problem imo. Sass seems a bit saner. And you can skip the tests for most projects.

zxcvcxz 10y ago

>I'm 30 screens down (literally 30 page down presses) If this web page were a book it would be about 30 pages. What framework is there that allows you to build full scale web-apps in less time? Certainly not Angular, an Angular tutorial would be at least twice as long and you wouldn't even use half the features of Angular. Meteor? Sure, but meteor isn't a good choice for people who need a lot of control of what's going on under the hood.

swanson 10y ago

I've shared your frustration. The Hello World experience is a huge spectrum ranging from the 30 screens of setup you describe to the one-click Visual Studio installer. The other thing to consider is what you assume from a reader in a tutorial. If you assume they have a full environment setup (or will be following another tutorial), you can put together a much more concise article. Imagine the now-classic Rails Blog in 15 minutes screencast. For those at home -- even if you assume a unix-y environment -- you might have tutorial setup that looks like this: * Install homebrew/update package manager * Install ruby-build * Install rbenv * Install ruby-2.3 * Install git * Create a git repository * Install bundler * Create a Gemfile that includes rails * bundle install * Install rails * Install postgres via homebrew * Setup postgres database * Install javascript runtime (nodejs or ruby-racer) * finally run `rails s` to see the blank hello world page Sometimes there are a lot of steps involved in a full end-to-end guide. And sometimes we forget all the baked in knowledge and setup we had to do for our preferred tools/stacks that we are having to go through again as part of learning a new technology.

pbreit 10y ago
But wouldn't it just be: * install rails * run 'rails s'
- bdcravens 10y ago
  If you've already setup Ruby, which most haven't if they're going through a similar tutorial for Rails.
  - pbreit 10y ago
    Well, Ruby is pre-installed on Mac OS.
    - bdcravens 10y ago
      I've never come across a single Ruby tutorial or talk or anything that suggests using system Ruby. For many good reasons. https://robots.thoughtbot.com/psa-do-not-use-system-ruby https://robots.thoughtbot.com/psa-do-not-use-system-ruby

atom-morgan 10y ago

> In this article I'm 30 screens down (literally 30 page down presses) and it's not even finished setting up the environment and dependencies. I'm writing a tutorial right now for testing AngularJS and this is exactly what I'm running into. It's a tutorial but half of my first part is "install this, put this line in this configuration file, install this, add this one here, etc." It's easy to feel like I'm not writing a good tutorial but really that's just the current state of JS development.

askldfhjkasfhd 10y ago
I'm way out of my league, but would it be possible to distribute a Docker container with all the boilerplate? Tutorial users could run that at the start, then do the "fun stuff".

lucideer 10y ago

It's literally 93 page-downs to the "Hello world" On the upside, it all seems clear (if somewhat laborious to go through in totality) and I definitely appreciate that the majority of those 93 page-downs were covering setting up testing and a testing strategy + framework. It seems most things of this type are more likely to either say "set up testing" without detail, OR are guides specifically for doing testing without going into great detail about the app being tested.

moogleii 10y ago
Huh? The first "hello world" equivalent occurs in the beginning. https://www.fullstackreact.com/articles/react-tutorial-cloning-yelp/#demo-basic-appjs https://www.fullstackreact.com/articles/react-tutorial-cloni...
- lucideer 10y ago
  That's the first time he prints anything to screen, but the actual first "Hello world" text is at the beginning of the Routing section where he's just finished all initial boilerplate and testing setup and puts in his first route. Which is a little more representative. I think it's a good guide btw.
  - moogleii 10y ago
    I guess it depends what one thinks is representative of a hello world. His first print out of the literal "hello world" may be down that far, but in terms of "classical" hello world "standards" (just based off what hello world apps have traditionally looked like), the section I linked is more analogous in my opinion. It shows react operational and rendering. If the bar is a yelp clone (which is already contrary to what a hello world is), then sure, maybe page 93 is more apt. But...you're building a yelp clone.
    - lucideer 10y ago
      My thinking was the bar would be "first output after boilerplate setup", in this case immediately before beginning to write any yelp-ish logic.

leoalves 10y ago

I also share your frustration. I am learning react. A few weeks ago I wrote a small app and based my work from a starterkit with a few thousand stars on github. I learned a lot from this app and the starterkit. This week I decided to use what I learned at work, writing a small app that will be used only internally. When I cloned the same project at least 15-20% of the project was different. Not just is a pain to set up a project but it's also changing very fast.

mercer 10y ago

I feel the same frustration even though I am still at a point where I generally have a huge tolerance for this kind of stuff. Slowly, however, things seem to be improving. For one, Redux seems to be the preferred 'flux implementation'; that's an improvement over the countless implementations I had to choose from when I started about a year or two ago. Then there are Rich Harris' Buble[1] and Rollup[2], which provide respectively batteries-included ES2015 transpiling and module bundling, and probably a bunch of other projects I'm not aware of that provide some sort of standardization or simplification in this process. It's not happening as fast as I'd like, but it seems to be a move in the right direction. [1]: https://gitlab.com/Rich-Harris/buble https://gitlab.com/Rich-Harris/buble [2]: http://rollupjs.org/ http://rollupjs.org/

dceddia 10y ago

This was the first thing I noticed as well. 40% of the tutorial is setup. It doesn't HAVE to be that painful just to get a working environment going, but it gets painful pretty quickly if you pile on Webpack and PostCSS and a testing setup and everything. For true "Hello World", if all you just want is to play around with React without all the setup, try out quik[0] or react-heatpack[1]. I also wrote up a tutorial[2] using react-heatpack that gets a working Hello World in UNDER 3 page-downs :) [0] https://www.npmjs.com/package/quik https://www.npmjs.com/package/quik [1] https://www.npmjs.com/package/react-heatpack https://www.npmjs.com/package/react-heatpack [2] https://daveceddia.com/test-drive-react/ https://daveceddia.com/test-drive-react/

fbonetti 10y ago

This is why I'm so gung ho about Elm. To create a proper React single page app, you need React, Redux, lodash, react-router, webpack, Immutable.js, babel, npm, redux-thunk, isomorphic-fetch, webpack-hot-middleware, and ton of boilerplate and configuration (which everyone does differently). You can try to assemble this yourself, or choose one of hundreds of starter projects on Github. A comparable Elm app is a lot simpler. It consists of Elm, a router such as elm-transit-router, and maybe webpack if you want to watch and minify your compiled javascript. Especially now with the new 0.17, Elm forces you to use the standard Elm Architecture, so you don't waste any time thinking about how to structure your app and there's very little boilerplate as a result. On top of this, Elm is statically typed, functional, and simply a joy to work with.

moogleii 10y ago
I've no doubt Elm is simpler (considering it's more vertically integrated), but to be fair, if webpack is a maybe in Elm, lodash, immutable, isomorphic fetch, and webpack-hot-middleware would definitely be on my maybe list for React. Maybe maybes would include redux-thunk.
- callahad 10y ago
  Vertical integration plays a part with blessed libraries for rendering, routing, and requests, but it's not just vertical integration: Elm completely obviates Immutable.js, TypeScript, Reselect, Redux-Thunk, and Lodash/Ramda by virtue of fundamental language design choices. The same goes for Haskell, OCaml, and PureScript. In that context, Redux becomes a design pattern, rather than a library. Ultimately, it feels like React's best practices and associated libraries try to bludgeon JavaScript into acting like a functional, immutable language. If that's the right model, I'd rather just use a language that was intentionally designed to be functional and immutable from the start. :)
  - aidos 10y ago
    Can you embed an existing js app (angular) with Elm? Doesn't need to be any real communication between them. Just have the Elm app decide if the angular app is displayed or not. Honest question as I'm embedding angular in react at the moment and there's quite a lot of library fatigue going on.

novembermike 10y ago

If you want to put together an Ikea chair, everything is in the box and the instructions are two pages long. If you want to put together a chair from scratch then you need the wood, hammers, nails, saws, a lathe, sandpaper (in multiple levels of coarseness), glue and a number of other tools. React is a lathe in this example, it's hard to put it in context without the rest of the tools but that doesn't make it complex.

romaniv 10y ago

>I'm not blaming react, everything else in the javascript space is just as bad right now. There's at least 4 different ways of loading modules (UMD, AMD, commonJS, es (babel) modules), 2 of which (require(), import .. from) are used within this example. Personally, I got so frustrated with ever-increasing complexity of tools and growing networks of dependencies that whenever I can I try to package my JS code in self-contained modules/files that depend on nothing -- not even on one another. Needless to say, it's not an approach that's very popular, but it works remarkably well for websites of moderate complexity. One thing I'm sure of: using those modules feels far more satisfying than using a framework.

softawre 10y ago
Sounds very anti-DRY, though I get where you are coming from.
- romaniv 10y ago
  As far as DRY, the worst aspect of no-dependencies approach is dealing with AJAX. The rest of it is actually not that bad. After some experimentation, I separated the functionality into "behaviors", which are fairly reusable across different pages and projects.

sergiotapia 10y ago

Screw this, use Meteor to build React apps. It's super smooth, no BS, and integrates everything that sucks about Javascript development into a cohesive Omakase package.

gedy 10y ago

> I'm not blaming react, No, React is particularly bad here. RactiveJS for example can be used in a minute: http://www.ractivejs.org/60-second-setup http://www.ractivejs.org/60-second-setup

twohearted 10y ago

The real gut punch is many parts of this tutorial will probably be obsolete within six months. Fast forward a couple years and this will look like the equivalent of "Backbonejs tutorial - Step 1: bower install requirejs". Sometimes I feel bad complaining about this. Things are evolving fast for a reason. Everyone is trying to make every part of this process better. The backbone joke above illustrates the point. Would you go back in time and freeze the evolution just to regain sanity for today's devs?

shriphani 10y ago

Concision is an art-form. In clojure I would do: * lein new figwheel hello-world And done. Say lein isn't installed, it is a simple script you download and run once.