More tutorials coming up soon: cabin.getstream.io
Is your site associated with this one? If not this comment seems very out of place.
React Tutorial: Cloning Yelp
81–90 of 258 posts
Re: React Tutorial: Cloning Yelp
#82Meanwhile here's how you work with React in a Meteor application.
https://github.com/nanote-io/nanote-web
No need to mess around with plumbing because honestly, who cares about that stuff.
Re: React Tutorial: Cloning Yelp
#83We (Stream) are releasing a React/Redux tutorial series - you build a photo sharing app (Instagram clone), for those you might be interested: http://blog.getstream.io/react-redux-example-app-tutorials-p...
This link has no content - looks to be like a "coming soon, give us your email for updates!" page
Re: React Tutorial: Cloning Yelp
#84I'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…
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.
Re: React Tutorial: Cloning Yelp
#85Am I the only person who just doesn't get the appeal of Webpack over using something like Gulp? It just seems to me like Gulp is so much easier to use and setup.
Webpack isn't like Gulp at all. It's absolutely insane what Webpack can do. It can solve any asset-related problem imaginable. Compile SCSS into CSS into JSON and require it in your Javascript? Convert SVG images into data-URLs that work on all browsers? Manage async dependencies in your JS code without dynamic script tags or global variables? Automatically figure out exactly which assets you need on which page and chunk them all together? All of the above.
Re: React Tutorial: Cloning Yelp
#86I'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…
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!
Re: React Tutorial: Cloning Yelp
#87Great work on the tutorial. I'm sure it took a lot of time to setup, and it seems well written. However I simply won't believe that setting up a simple React app requires so much overhead. Granted, I have no experience with React, and only marginal experience with frontend web dev. As I read the tutorial, this is the list of questions I had: 1. Why do we need so many Babel presets? What do they do? 2. Why do we need…
There are simpler ways; I don't mind webpack, I just find it hideously over complex at times; if a large % of React tutorials preface the part you want to read with long, differing, detailed explanations as to how to set Webpack up, I think there's something wrong. Brunch works well, for example this is simpler:
npm i -g brunch
brunch new myApp -s react
cd myApp
npm start // server starts on port 3333
So normally I'd go nuts and put sass, JS' staging features, a test framework in for dev. And redux, a router, immutability for the app. But only the bit above this paragraph is needed to get started with an app, not a toy, pretend one, an actual app. v0v
npm i --save-dev sass-brunch ava babel-preset-stage-0
npm i --save redux react-router immutable some-other-shiny-react-libraryRe: React Tutorial: Cloning Yelp
#88Earlier quoted context omitted.
That's an unfair comparison. You are building the whole Ruby dev environment from scratch before coming to Rails. Which is not what is happening in the tutorial. Actually, if you have the typical ruby environment setup already (ruby, rubygems, bundler), then its only gem install rails rails new rails s You don't need postgres or any JS runtime to start off.
If you were trying to learn Rails (which this story ostensibly is doing with React) you wouldn't have Ruby installed. (or you'd be using system Ruby, which you generally shouldn't use: https://robots.thoughtbot.com/psa-do-not-use-system-ruby )
> If you were trying to learn Rails (which this story ostensibly is doing with React) you wouldn't have Ruby installed
Why? I went to Rails after I learnt Ruby. By that time, I already had rvm installed to manage Rubies.
I can agree that a lot of users jump to Rails without learning Ruby first, in which case the setup will be 4 commands longer. But that is not the case with React as you can't jump over JavaScript to React directly.
Re: React Tutorial: Cloning Yelp
#89I think most everyone agrees that the amount of work to get all these pieces glued together before you can even start is ridiculous- a problem that Meteor set out to fix years ago. It faltered, of course, by being too opinionated. Now that Meteor fully supports React and npm, though, is there any reason not to use it? Sure does remove some pain points.
Re: React Tutorial: Cloning Yelp
#90I'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…
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 in…
> 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.