Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things every React.js beginner should know

camjackson.net

Post reply on HN
Print view View original

181–190 of 247 posts

Re: Things every React.js beginner should know

#181

Post by madeofpalk »

woah wrote: post #176
marknutter wrote: post #175

So here we see the culmination of the great Frameworks vs. Libraries divide. Frameworks alleviate the need for the type of articles like the one linked here because they eliminate choice paralysis and imposter syndrome. Everyone is worried about whether or not they're doing things The Right Way™ and so they either blaze ahead and hit the same pitfalls everyone else does (and then write blog posts to warn others) or…

You describe ES6 as some kind of exotic dependency. Actually once you get rid of ES6, the only dependencies in your list are immutable.js which is optional, and redux, which has become the well-known default.

Usually you're using ES6 because you can, because you're highly encouraged to use Babel to transform JSX.

Re: Things every React.js beginner should know

#182

Post by marknutter »

woah wrote: post #176
marknutter wrote: post #175

So here we see the culmination of the great Frameworks vs. Libraries divide. Frameworks alleviate the need for the type of articles like the one linked here because they eliminate choice paralysis and imposter syndrome. Everyone is worried about whether or not they're doing things The Right Way™ and so they either blaze ahead and hit the same pitfalls everyone else does (and then write blog posts to warn others) or…

You describe ES6 as some kind of exotic dependency. Actually once you get rid of ES6, the only dependencies in your list are immutable.js which is optional, and redux, which has become the well-known default.

> You describe ES6 as some kind of exotic dependency.

To the non Silicon Valley / Hacker News crowd, it certainly is. And using ES6 means you need to make a choice about which transpiler to use, which build tool to use, etc.

> Actually once you get rid of ES6, the only dependencies in your list are immutable.js which is optional, and redux, which has become the well-known default.

Well known to who, exactly? Because the "well known default" as of a few months ago was Reflux, and before that it was Flux. Oh, and there's Relay and GraphQL.

When's the "well known default" going to change again? I give it two months before everyone rushes to the next new gotta-have dependency. It's like reading Dr. Suess's The Sneetches.

Re: Things every React.js beginner should know

#183

Post by marknutter »

Retozi wrote: post #179
marknutter wrote: post #175

So here we see the culmination of the great Frameworks vs. Libraries divide. Frameworks alleviate the need for the type of articles like the one linked here because they eliminate choice paralysis and imposter syndrome. Everyone is worried about whether or not they're doing things The Right Way™ and so they either blaze ahead and hit the same pitfalls everyone else does (and then write blog posts to warn others) or…

I agree with your argument. I have seen people say on HN that 1 hour of setup to start a project is too much. If this is the case, React + stuff is really not the right thing for you. However, the React ecosystem is really not that complex. You can write clean, sizable apps with vanilla React. Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does…

> Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does not have all the pluggability whistles like Redux.

Quite easy for whom, exactly?

Re: Things every React.js beginner should know

#184

Post by lmm »

munro wrote: post #155
lmm wrote: post #132

Earlier quoted context omitted.

> You need some sort of logic in your views, no matter what system you use, i. e. loops or formatting dates. No you don't. Look at Wicket for how to do this right: everything is a component, the only thing[1] your templates contain is a) markup (which is 100% valid, using a namespace for the only wicket-specific part) and b) ids that indicate that a given tag will be replaced with a component. Everything else is hand…

When the parent says view, they're not talking about "a) markup", they're talking about the thing the user is looking at. > b) ids that indicate that a given tag will be replaced with a component With that in mind, your disagreement is contradicted by this statement because logic has just been described to update the view. Logic is necessary to generate a view of the data for the user. With JSX, keeping all of this c…

> With that in mind, your disagreement is contradicted by this statement because logic has just been described to update the view. Logic is necessary to generate a view of the data for the user.

There is no logic in the "template". No looping, no branching. Only inert ids. There is logic in determining which component replaces each id, but that logic lies in the code, not the template.

> it sounds like one must imperatively update the UI with Wicket, which is objectively more complex than what React affords, which is stateless UI.

Not so. Wicket clearly separates its state into models, you write UI that depends on a model as a function of that model. It leads to a very declarative/functional style, where the only "magic" is encapsulated and explicitly managed. (You do have to declare which changes update which UI (for performance reasons), but you can make that "always re-render the whole page" if that suits your use case).

Re: Things every React.js beginner should know

#185

Post by ergothus »

marknutter wrote: post #157
ergothus wrote: post #143

Earlier quoted context omitted.

It does indeed go against years of advice, but only if you look at it from too far out: (Note: I've minimal Angular experience so I won't comment on that. I've spent the last year on React) The real problem is mixing business logic and presentation, not mixing HTML and JS. React is purely presentation & presentational logic (or should be, you can of course implement it poorly) For Presentation, the HTML and JS are al…

> For Presentation, the HTML and JS are always coupled, whether you have them in separate files or not. Absolutely not. Back when we were all just using jQuery, you could run $('.some-class').myWidget() to activate a widget on any element matching the query. There was no need to couple the implementation of the widget with the element to which it was applied. If the widget had some internal element construction to do…

> If the widget had some internal element construction to do then yes, I would agree

...which covers most everything, really. Also, in the React world, if you just need to manipulate the data passed into a component, that's all pure JS. Only the component itself (with a reference to the passed-in data) would be JSX, which is distinctly more friendly to work with than string concatenation. (and I say that as someone that hates having a build step)

> However, there is still value in being able to share the same html template across multiple models. ... > Now you're faced with having to copy/paste the same template over and over in React

I don't think you understand the concept of a React component, or I've misunderstood what you are saying. Make that template once and just use it wherever needed!

I have some complaints with React, but lack of reuse and JSX being worse than the alternatives are NOT among them.

Re: Things every React.js beginner should know

#186

Post by Retozi »

marknutter wrote: post #183
Retozi wrote: post #179

Earlier quoted context omitted.

I agree with your argument. I have seen people say on HN that 1 hour of setup to start a project is too much. If this is the case, React + stuff is really not the right thing for you. However, the React ecosystem is really not that complex. You can write clean, sizable apps with vanilla React. Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does…

> Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does not have all the pluggability whistles like Redux. Quite easy for whom, exactly?

For anyone that has the ability to pull off a project that needs seperate state management.

It's really just a days worth of looking at the original flux, redux and other implementations and figure out what's best for your team and project.

It doesn't take more energy / knowledge than to hack around patterns that don't perfectly fit your projects needs with the "everything included" frameworks.

Re: Things every React.js beginner should know

#187

Post by Lazare »

tptacek wrote: post #101

Someone sell me on Webpack? We use Browserify for no other reason than that someone gave me a boilerplate Gulpfile that relied on it. What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch? Thanks!

Webpack does everything Browserify does, but arguably if you're used to both the configuration is marginally more transparent (although still terrible). Also, arguably, new features tend to land in webpack a LITTLE earlier than browserify, which might be important to you in rare cases.

In short, I've used both, and I'm currently happy with webpack, and I have a decent configuration on my current project with a dev server, good production builds, support for CSS modules, and hot module replacement, all of which I could have in browserify.

Oh, webpack makes it a lot easier to dispense with gulp; my last browserify config was driven by gulp, but my current webpack config is just driven by a few lines of vanilla node.js code, which is kind of nice.

> What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch?

Probably none of them. But if I had two boilerplate configs, one using gulp+browserify and the other webpack, I'd choose webpack because I think it's VERY SLIGHTLY clearer and more maintainable.

Re: Things every React.js beginner should know

#188

Post by Lazare »

mbrock wrote: post #118
tptacek wrote: post #101

Someone sell me on Webpack? We use Browserify for no other reason than that someone gave me a boilerplate Gulpfile that relied on it. What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch? Thanks!

You can run "webpack-dev-server", which uses your Webpack configuration to serve your scripts with its own web server. That means (1) it can do incremental recompilation, which I can't live without since my build takes 20 seconds; and (2) it can block requests while compiling, which is way better than having a background thing (e.g. watchify) recompile your code, since it means you're never interacting with a stale (…

FYI, browserify has support for all the cool tricks you list too now; it's just a question of finding and wiring up all the right plugins.

Eg, lessify, css-modulesify, or csvify will handle the cool require tricks, browserify-hmr does the fancy hot module replacement, watchify has incremental recompiliation support if you manage to configure it just right, etc.

Mind you, I find webpack easier to configure (all the fancy browserify plugins destroy it's simplicity), but the two toolchains have had feature parity for a while.

Re: Things every React.js beginner should know

#189

Post by tptacek »

Lazare wrote: post #187
tptacek wrote: post #101

Someone sell me on Webpack? We use Browserify for no other reason than that someone gave me a boilerplate Gulpfile that relied on it. What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch? Thanks!

Webpack does everything Browserify does, but arguably if you're used to both the configuration is marginally more transparent (although still terrible). Also, arguably, new features tend to land in webpack a LITTLE earlier than browserify, which might be important to you in rare cases. In short, I've used both, and I'm currently happy with webpack, and I have a decent configuration on my current project with a dev se…

Thanks (to everyone who responded!)

I feel like I get it now.

I'd probably look into switching to Webpack on future projects, but I'd rather french-kiss an angry squirrel than spend a half a day wrestling with my app bundling code again, so I'll stick with Browserify for this one. :)

Re: Things every React.js beginner should know

#190

Post by camjackson »

lukesan wrote: post #78

What really bothers me about React (and other frameworks) that without JS you do not see anything. No fallback. No progressive enhancement. Is this really the way to go? Did JS replace HTML/CSS as the backbone of websites/applications ?

As others have mentioned, you can use the same React code to render on the server. I actually have a blog post about that too: https://camjackson.net/post/server-side-rendering-with-react
Post reply on HN