Hacker News Reader

It isn't so much pre-mature optimization rather than having the next step of the evolution of modern webdev.

Let's go back 6 years in webdev land. jQuery was king, Angular was the up-and-comer. You have a fairly complex jQuery site probably rendering most things from ruby or php. The only way to debug it was with console.log and refreshing the page.

Angular comes around introduces modules and unit-testing, cool! You hook up grunt and protractor, you install angular batarang. Everything is good. But you end up building this huge angular app. You try to debug this edge case when you have this panel open under this tab. You get frustrated that you have to click on the same things over and over again. Livereload can inject css but not js. When you change the html of your angular directive you have to reload the page too.

This is where React comes in. React + Redux + Webpack makes it such that you can apply livereload to _everything_. The css that your component imports, the html it renders, what actions happen when you click a button. Everything. It's not necessarily the new shiny rather than just the next step to making things easier for devs. It gets out of your way so you could focus on styling, structure and business logic.

> It's not necessarily the new shiny rather than just the next step to making things easier for devs

It's more testable, maintainable and reusable, but easier certainly not.

Exactly! Not to mention the reusability benefits of components - rather than passing around JQuery selectors and objects.

The cognitive load of using plain React is unparalleled for me. The effort to setup the tooling is a bit of a hassle though..

And the next logical step for styling IMHO is using tachyons.css, or the port: react-native-style-tachyons.

It frees you from the organsation of a stylesheet and from having to find widths, heights, paddings, margins and font-sizes that work together.

> What exactly is the savings here? I fail to see it.

Huh? Did you read the article? One answer (which as a React user I think is the main one) is right there. To quote them,

> The central idea of React's API is to think of updates as if they cause the entire app to re-render. This allows the developer to reason declaratively, rather than worry about how to efficiently transition the app from any particular state to another (A to B, B to C, C to A, and so on).

If you disagree with this, you should explain why.

It sounds like you worked on a few projects where people reached for a JavaScript framework when it wasn't necessary; I can understand how that can be frustrating. But surely you aren't saying that there isn't any room or merit for front end frameworks at all?

By front end framework standards, react isn't giant at all. And in terms of internal complexity, most people using react don't even have to know about any of the things in the post

I think it may be helpful to consider the possibility that there exist people who are more rational, pragmatic, and intelligent then you or I, who think React is useful for certain types of work. Assigning the motivation of "chasing shiny things" to people liking something you don't will be detrimental to gaining further understanding

It's no longer considered premature optimization when you have 100,000 DOM elements on a page, like Facebook conceivably would. It's not surprising that this project comes from them.

Does a run-of-the-mill JS app require React? No, there are hundreds of alternatives from direct state mutators like jQuery, all the way through full MV* frameworks like Angular, Ember, Backbone, or newer.

React is cool and innovative in its problem domain, but not all users of a technology will use it solely on its merits. This is frankly a risk with any 'popular' technology.

You might want to re-read your comment. Your argumentation is only relevant for grossly over-engineered projects.

React isn't about the number of elements on the page or the performance, it's about making it possible to build the UI in a declarative way. It raises the barrier of entry but immensely improves clarity, testability and maintainability.

If you ever work on a non trivial frontend with people who are well versed in the React stack and functional programming, you're in for a ride full of amazement.

More than once I chose to use React (+ Redux, etc.) for something that could've been solved with a few snippets of jQuery or even just plain javascript.

In many of these cases the app ended up becoming complex enough that I was happy to have prematurely optimized. This has happened often enough that I tend to give React the benefit of the doubt when I'm building an app. (This is also the reason why sometimes I choose to use batteries-included Rails even though Express.js or some lighter framework seems like a perfectly fine choice.)

In other cases using React didn't make things easier, but doing so was convenient because I'd been working with React most of the time anyways (and had some other project to use as a basis or even entire components I could re-use).

All that said, I do err on the side of shiny sometimes, and spend much more time (and Kb's) using React for something where it wasn't necessary. So I see your point.

The best thing about React / Relay / GraphQL is the emergence of the idea of using a graph query language. Will GraphQL be the ultimate winner? I don't know. But I suspect this approach will catch on, since the problems with RESTful interfaces are well known, and painful enough to force a change. And yet, once we start using GraphQL, the other technologies get dragged along with it. We want pagination so we use Relay. We want immutability on the fronted, so we use React. It's a powerful combination, though I can imagine the ideas being copied by other frameworks, who perhaps offer a cleaner implementation (my biggest grip with GraphQL is the verbose mutations).

http://www.smashcompany.com/technology/graphql-is-the-best-t...

It's a tightrope. Their are plenty of arguments to be made for having a large build system that makes development easier/more conventional. Their are also arguments to be made for minimalism and sticking to the fundamentals of the web with plain html/css/js.

What we can all agree on is that its good to at least have the CHOICE of development environments, build systems, and ecosystems. And I personally always fall back on: "this complexity is why I get paid more then most people".

>And I personally always fall back on: "this complexity is why I get paid more then most people".

This is pretty cringeworthy. If your tools are introducing enough incidental complexity that it needs to be reflected in your compensation, i'd argue your tools are failing your company badly.

You should be paid more to reflect a higher level of technical or domain expertise relative to other engineers, not to account for your ability to glue together a mish-mash of poorly documented and half-baked technologies.

I don't write tools that are unnecessarily complex in order to make more money.. I get paid to use tools that are necessarily complex, and use them properly. How you interpreted my post to relate entirely to the former is beyond me.

Just built our first major react/redux site. Moderate complexity, I'd say. React runs pretty fast, but on page load we take 2.5s to compile all the JavaScript.

Are you sure compilation is the bottleneck? 2.5s seems way too much by an order of magnitude.

Have you looked into compiling during your build step instead of at runtime?

In a large application my rule of thumb is 1/3 compile, 1/3 React internals (which includes DOM updates) and 1/3 product code. 2.5 seconds is a lot, but not surprising if an application is being shipped as a multi-megabyte bundle.

Compiling as a build step doesn't get you very far when you are forced to ship source code to JS engines.

I guess I may be a bit confused on what he meant by compilation

Since JS is JIT compiled, I assumed perhaps he was delivering his scripts in raw JSX+ES6 and transpiling at runtime via babel's browser.js (as shown by react's Getting Started guide) [1].

If he meant time spent parsing the JS then I'd be a bit suspicious about the 2.5s both because of the extraordinary length and also I find it hard to believe someone who would know how to measure parse time would mistake the term with compilation.

[1]: https://facebook.github.io/react/docs/getting-started.html

I have worked on several react native projects. The more I do the more I'm convinced you are correct

Could you elaborate on that? My experience with React has been that most of the 'shiny time-waste' problems don't arise from, say, React + Redux, but from the itch to use all the 'cool stuff' that people are talking about.

I've wasted so much time configuring apps to get hot module reloading to work, adding all sorts of redux middleware, using react-router as it transitioned to a completely new react-router, working with higher order components, using some immutable library, etc.

Many of these things were not necessary for the stuff I was building. In fact, in a bunch of cases I could've just used React and nothing else. I suspect if I'd done that, it wouldn't have felt as much like premature optimization.

Thankfully most of these projects were personal, and learning a lot about the React ecosystem has been fun. Still, lots of premature optimization.

I'm very curious to hear where you ran into issues.

I wouldn't say that React is particularly huge compared to other frameworks. Certainly when if first came out it was actually quite small. I haven't checked lately, but I think it is still considerably smaller than things like jQuery.

But you answer your own question in the second paragraph. Why use React? Because you want to use a non-standard functional style of Javascript. For me, it's a pretty big advantage, but if you don't like functional style programming and can't deal with persistent, immutable data structures, then I think you would be wise to avoid React.

To a certain extent I can sympathise with your feeling. Almost every time there is an article linked here on HN I see people getting into trouble with React. Usually the solution they reach for first is to strap on more plugins (with Flux, etc). Often the structure imposed by those plugins help them be more disciplined, improving their code, but at the cost of added complexity.

React itself is very simple. The trick is in understanding how to use it. Things like componentDidMount are useful for very strange corner cases, but it is pretty common to see people use it in every single component they write. If you pull componentWillReceiveProps, etc out of the box, then it should be a gigantic clue that you have done something very, very wrong. Mostly there are warnings in the documentation about this. Mostly people ignore/don't read them ;-).

JSX is really a non-issue for me. Personally, I don't understand why anyone would want it. You can write exactly the same code without JSX and it looks pretty much exactly the same (except with lots of insane, silly parentheses -- but, we're here for the functional, right?). Whatever. Normally I have to browserify my code anyway. Adding another step to the build is not exactly rocket science. I'm also usually using either coffeescript or ES6 through babel, so I've got a compile step either way. The times where I insist on no JSX is when I'm doing ES5 work and want to run unit tests in Node without the compile step. But that's pretty rare.

Having said all that, I'll take the opportunity to offer you some advice. I don't know if you are in the mood to receive it, so it might be fruitless. You said:

> Whatever happened to pragmatism? Has that just lost by the wayside of the new shiny?

One of the things about smart/talented developers is that they are used to growing up thinking that they know the right answer. I was certainly of that mould. As I've gotten older, though, I've realised that this way of thinking is self-referential and ultimately limits your growth.

In this case, I think you've decided apriori that the way you are comfortable doing development is already the best -- or at least so much better than what you see elsewhere that it doesn't matter if it's the best. When you see people struggling (and failing) with something new and unfamiliar, the natural inclination is to assume that it is no good.

Did you know that back in the day, many programmers thought that MFC was an exceptionally good idea? Anybody forced to use that anachronism now would probably quit on the spot. Things do get better over time and new frameworks and techniques can improve our lives as programmers. While it is pragmatic to stick with what you know, you have to balance that with learning new ideas that make you a better programmer.

Humility has always been something I struggle with, so perhaps I am the wrong person to say anything. However, when you see someone making the same mistake that you made over and over again, it behoves one to speak out, doesn't it?