Live data from Hacker News

React Tutorial: Cloning Yelp

fullstackreact.com

211–220 of 258 posts

Re: React Tutorial: Cloning Yelp

#211

Earlier quoted context omitted.

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 upgra…

I'm looking here: 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?

the first line of HTML code in that Fiddle link is: 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.

Re: React Tutorial: Cloning Yelp

#212
post #161

Earlier quoted context omitted.

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 That's just bas…

Brunch looks pretty cool actually.

It's been around for ages (2011), and I still don't think anything else has it beat in terms of 'get developing an app immediately'. It hasn't really got any magic, and yet it mostly just works out-of-the-box without any configuration. Some of the stuff surrounding it is a little out of date (for example, the Sass package is a bit flakey at times, though that can generally be fixed by just blowing away node_modules and `npm i` reinstalling), but it's used as the frontend build system for the Elixir web framework Phoenix, so it's been getting quite a bit of TLC recently.

It also only got proper, inbuilt NPM support near the end of last year (though that can occasionally be flakey), which I guess is one of the major reasons it hasn't had a lot of love vs Webpack, or Grunt/Gulp (w/Browserify) prior to that.

Re: React Tutorial: Cloning Yelp

#213
post #181

Earlier quoted context omitted.

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…

>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 lo…

Grunt is actually not still fine to use. I've been burnt by a lot of plugins coming out for Gulp only and now for webpack only. What the GP says is true: if you start using any of these JS tools prepare to switch them out every 6 months.

Re: React Tutorial: Cloning Yelp

#214

Earlier quoted context omitted.

This is how I start off a React app: $ npm install --save react react-dom $ npm install --save-dev webpack webpack-dev-server babel-core babel-preset-es2015 babel-preset-react react-addons-test-utils /webpack.config.js module.exports = { entry: 'src/index.js', output: 'dist/bundle.js', module: { loaders: [{ test: /\.jsx?$/, exclude: /node_modules/, loader: 'babel', query: { presets: ['es2015', 'react'] } }] } } /src/…

> There is nothing forcing you to use all the extra dependencies This right here is a major problem with a ton of apologists. "You don't need to use X and Y, just start with barebones Z". If you're doing your own side project, sure. Or if you're lucky to be developer #1 in a greenfield project. I can count on one hand the number of times in my career that's happened. Most of the time, you're going to be maintaining s…

The extreme modularization is a huge, huge issue. There is a slight settling: the recommendation for state management shifting almost exclusively to Redux is IMO a very good thing, if only for the fact of how brutally simple it is, with almost zero chance there will be any API changes. Packages such as react-router, with constant API changes, are a nightmare though. Standardisation this year would be good: state management (Redux), a router (a settled react-router), immutability (Immutable), a method of dealing with asynchrony/promises that's well documented and easy for people to just pick up and use, a drop in test framework (personal bugbear is setting up the multifarious bits of test/coverage/complexity tools - Ava + NYC + Plato seems a very good build so far for this, but it's very young). But it's the configuration of build tools which is the killer

React itself is very simple, but then so is jQuery, and having to pick apart the twenty or thirty jQuery plugins + associated spaghetti the last dev dropped into a project is even less fun than the current situation, it just took a lot less of a deep understanding of JS; one of the issues I'm starting to get a lot more of is devs dropping in prebuilt components, which is just jQuery all over again, but in extremis.

Re: React Tutorial: Cloning Yelp

#215
post #194

Earlier quoted context omitted.

Out of curiosity, why did you write the function like this: const MyRootComponent = (props) => { When it's shorter and more obvious what's happening if you write them like this: function MyRootComponent(props) {

"An arrow function expression has a shorter syntax compared to function expressions and lexically binds the this value (does not bind its own this, arguments, super, or new.target). Arrow functions are always anonymous." https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Why do you want it to be anonymous in this context? I get you can drop the `return`, but I don't see how you gain anything (apart from a tiny reduction typing and a small increase in incomprehensibility) by using anonymous functions to define components (I know the pattern is used a lot in the wild, but there seems to be zero reasoning for it; lexical binding isn't really relevant here)

Re: React Tutorial: Cloning Yelp

#216

Earlier quoted context omitted.

What makes you say it failed?

https://www.discovermeteor.com/blog/the-state-of-meteor-part...

Sure- that's the article I was thinking about when I mentioned that it faltered. It still has quite the dedicated base, and with 1.3, has corrected many of the complaints (npm support, etc)

Re: React Tutorial: Cloning Yelp

#217
post #11

This genuinely made me feel ill. The author has done a tremendous service to others - clearly and patiently listing the thousands of steps required to get a basic modern web app up and running. I agree with others that it is often difficult to find all the steps for a process like this in one place. At the same time, this is completely, totally fucking insane.

React was built by Facebook. Facebook has 1 billion users. If you're looking to build a fast, simple, web app look at rails or Phoenix, not React.

Are you trying to say that if you are building a simple web app you should be building a server-side rendered web app using Rails/Phoenix?

Re: React Tutorial: Cloning Yelp

#218
post #180
post #40

Great 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…

> So many things to keep in mind, so many dependencies, so very many points of failure. If just one of these libraries is abandoned, or has a breaking change, your entire development environment is dead. Is this the current state of frontend web dev, or are these guys just overdoing it for the sake of the tutorial? This tutorial is trying to guide you over the initial hump with the tooling by letting you hit the issu…

I am not a front end dev so this is a serious question.

The new shiny seems to be using dependencies straight from git and vendoring them.

Presumably new versions come out because they fix bugs or security issues.

How do you keep your projects up to date? Do you manually check every dependency in your project once in a while? Do you have some automation which alerts you to security issues in a dependency of yours?

If you decide you need to stay on an older version, is someone backporting fixes?

Is there a curated set of packages that are known to work together?

When an update comes in, do you audit it to make sure nothing malicious makes it on to your systems?

Or does one have to wait until this stuff stabilizes and baked it's easy into linux distributions before one gets these nice features? (Which basically isn't easy to do with how fast the landscape is evolving).

I'm curious about solutions to these problems.

Re: React Tutorial: Cloning Yelp

#220
post #181

Earlier quoted context omitted.

>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 lo…

Grunt is actually not still fine to use. I've been burnt by a lot of plugins coming out for Gulp only and now for webpack only. What the GP says is true: if you start using any of these JS tools prepare to switch them out every 6 months.

> What the GP says is true: if you start using any of these JS tools prepare to switch them out every 6 months.

As a full stack JavaScript developer, the tools I used over 6 months ago are also the tools I use today. Only difference is I left Angular for React. But my build tools are still the same. I use Gulp, SASS and Webpack.

You're talking out of your ass if you actually believe something can get to the popularity of Gulp or Webpack and then instantly be "old news" and "not worth using" within 6 months.

Post reply on HN