Live data from Hacker News

An experienced Javascript developer’s account of learning React

medium.com

131–140 of 157 posts

Re: An experienced Javascript developer’s account of learning React

#131
post #108

Earlier quoted context omitted.

Oh, no, I'm sure that's incorrect. Templating libraries can't update documents, they can only overwrite them completely. This either loses state (entered-but-unsaved text, cursor positions, collapse status, etc.), or requires a lot of watchers and extra state information. Those DOM updates is the whole point of React. There are other libraries that work in a similar fashion, but React has more traction thus reusable…

no, the point of the template engine is not to push all the logic into the templates. as you say you still handle the state yourself. the template render just skips the messy output building step, which for many cases is all you need

Ah, I think I see.

React is a templating library. Nothing more, nothing less.

It takes a state ("props"), a template ("component") and renders the DOM tree. That's all it does. (Non-templating uses like react-router are kind of hacks, rather than intended use. YMMV, of course.)

However, it's more complex than previous-generation templating libraries (that had emitted strings, rather than operating on DOM trees), because DOM trees are stateful. This is why React is so huge, when compared to, say, Mustache.

(And, of course, it's really easy to mess things up by putting application logic right in the component class. And, I'd say, sometimes it's really tempting to do so. Mustache/Handlebars doesn't have this only because they're specifically designed to disallow such things.)

Re: An experienced Javascript developer’s account of learning React

#132

im going to just say whats on my chest. it makes me wonder if react devs who thinks react is the greatest thing since sliced bread are somewhat new to web development (less than 2-3 years or so). because im sure those who inherently know, would find that vuejs is just a superior framework (sans native). there will always be new frameworks that comes out and some will be better than the last. and vue to me is leading…

I don't think that years of experience has anything to do with liking vue or react. I know how you feel, because my colleague had similar thoughts on React, he even created something very similar to vue a few years before vue(jade+css+js in one file). While I just use pure virtual-dom (no jsx) and almost nothing else.

The way you put it, some people look for patterns and elegance, while some look for simplicity (no special v-bind or v-if), modularity and deletability. There is nothing more senior about one way or the other, just different personal preferences.

Re: An experienced Javascript developer’s account of learning React

#133
post #76
post #13

Earlier quoted context omitted.

It's valid. className was a frequent annoyance with React. That's one of the nice things about Vue. I can paste HTML snippets and they just work. I can't say it's the reason I switched, but it was some icing on the cake.

What was the reason?

A few reasons. The render() functions were unweildly. The ecosystem of router/state libraries were in constant incompatible flux. Difficult transition animations. Complex server side rendering setup. Probably some other things I can't remember.

Re: An experienced Javascript developer’s account of learning React

#134

I don't think the `className` argument sticks. `class` is reserved so you can't use it. It's annoying but not a difficult concept The other points are valid though. Mobx/Redux seems like a solution for big applications, but what's the alternative for small-to-medium React applications that still need to store state? I agree I had issues following the snippets (and for one snippet I would definitely have to check MDN…

> I don't think the `className` argument sticks. `class` is reserved so you can't use it.

But you can use it. JSX nodes get compiled into React.createElement calls with object literals[1], and {class: "foo"} is a perfectly valid object literal in JS, s there's nothing stopping `` to get compiled into `React.createElement("div", {class: "foo"})`

In fact, other frameworks that support JSX syntax allow the use of `class` instead of `className`[2], so it's not a limitation of JSX per-se, it's just a design decision on part of React (and an annoying one at that).

[1]: As noted in the first code snippet on the React homepage https://facebook.github.io/react/

[2]: E.g., Mithril https://mithril.js.org/jsx.html#jsx-vs-hyperscript

Re: An experienced Javascript developer’s account of learning React

#135
post #29

At our company, we have banned React, Angular and other "overengineered" JS frameworks. Our HTML is rendered from a standard boring Groovy server page, with some vanilla-js for DOM manipulations here and there. We have hired developers that were React fans, which quickly changed opinion that this old-school way for developing web applications is indeed better. It is faster to code, an order of magnitude easier to mai…

I've said it before here, but the best web app I've built was basically Django, with bare minimum js to handle in-page effects.

I've been working on a project which is being ported to React for no reason, just because it's shiny, and it's been worst than expected.

Bundling the entire website into a huge js file doesn't make any sense. In practice, every time you make the slightest change, like adding a div, or changing a class name, your users have to re-download the entire thing.

Webpack takes 1GB of memory and 90 seconds to build it. Firefox Dev Tools eats all my ram if I try to reload the page with it open. And Redux is just bad. So much boilerplate for a dynamic language, with constants and if clauses to decide which action to dispatch. Apparently, it's ok to have presentation logic in a component, but god forbid internal state!

I do believe the reason front-end devs praise it so much is because it allows them to work solely in js, despite the end product being slow and heavy.

I always compare reddit's mobile site, written in react, with Hacker News. The first takes around 7 seconds to load on my cel phone, while the latter loads instantly.

No one but frontend devs care about js. The web hasn't become js centric and I bet it never will. It has become mobile first and all you need for 90% of that is css.

I don't know why fb and google spend money building these frameworks, but maybe because of this:

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

"But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.

Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP.

The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it’s just cover fire so that they can move forward and you can’t..."

Replace Microsoft with Google or Facebook...

Re: An experienced Javascript developer’s account of learning React

#136
post #40

I was very intrigued by the title: Things nobody will tell you about React.js Immediately had high hopes that someone is going to try and give a well researched, novel critique that maybe can spur out some constructive conversation. And then, sadly, the author goes on to write exactly what countless other articles have already covered and discussed to the death for years now. "HTML in JS", "JSX is bad", "Redux is com…

I agree on everything except what you're saying about React Router. I've been working on projects that tracked React Router since it was first announced. Understandably, every pre-1.0 release broke something, 1 to 2 broke things, 2 - 3 was compatible but slower in enough scenarios that it's questionable whether you should upgrade. RR4 just isn't the same library, and due to its reduced scope has thrown a few problems back into the realm of being unsolved.

It's fairer to say that the year during which RR2 and RR3 were the primary releases, was a relatively stable time.

I've generally been pretty tolerant of the amount of library churn within the React ecosystem, I'm the kind of person who will happily keep dependencies up-to-date and upgrade apps to newer/better tools when they emerge (I'd even say I enjoy it more than actual day-to-day coding), but React Router has been a major source of frustration for a long time now. Hopefully, the version 4 API is going to be stable for a while (even though getting efficient data-loading with Relay is now an utter pain).

Re: An experienced Javascript developer’s account of learning React

#137
post #108

Earlier quoted context omitted.

no, the point of the template engine is not to push all the logic into the templates. as you say you still handle the state yourself. the template render just skips the messy output building step, which for many cases is all you need

Ah, I think I see. React is a templating library. Nothing more, nothing less. It takes a state ("props"), a template ("component") and renders the DOM tree. That's all it does. (Non-templating uses like react-router are kind of hacks, rather than intended use. YMMV, of course.) However, it's more complex than previous-generation templating libraries (that had emitted strings, rather than operating on DOM trees), beca…

no disagreement on what react is. yes, I understand react can be used just to template (no one uses it this way). yes, react is powerful. yes, react provides a good mechanism for handling state and events. what i am saying though is that for some apps, you can get by with simpler templating and avoid the conplexity/power react gives you, handling state and events yourself manually. does it sound crazy? if you know it will work for your particular use case, i dont think its crazy, and you avoid a bundle of complexity that react gives you, in essesnce you own the complexity now

Re: An experienced Javascript developer’s account of learning React

#138
post #62
post #53

In general the React approach works best if you are willing to build out a handful of utilities on your own sometimes, rather than always choosing from pre-existing open-source solutions. You don't need React Router. You don't need React-Redux. Heck, you don't always need Redux, you can just throw a state object on the window (or make a state module or whatever you do these days). Here's a React 15 app in a single HT…

I had high hopes there, but I don't see an app, I just see enough boilerplate to put a Hello, world! into the DOM, which could have been done by just writing that into HTML. I can understand what it's doing, but I don't think it's a good example of how you can write an actual app without the parts people are mentioning.

https://www.depop.com/ = React + Relay + React Router (probably not needed, might switch to Next when I upgrade to Relay Modern). Redux is technically in the codebase, but for such a minor feature that I think I'd now be comfortable removing it.

I appreciate the site is relatively simple, but honestly React + Relay + [insert router here], is sufficient to build this out to something of relatively high complexity. Obviously, I have more dependencies than this (JavaScript lol), but they're mainly ones for solving very specific requirements, rather than key architectural libraries.

Re: An experienced Javascript developer’s account of learning React

#139
post #125
post #40

I was very intrigued by the title: Things nobody will tell you about React.js Immediately had high hopes that someone is going to try and give a well researched, novel critique that maybe can spur out some constructive conversation. And then, sadly, the author goes on to write exactly what countless other articles have already covered and discussed to the death for years now. "HTML in JS", "JSX is bad", "Redux is com…

I've had really bad experiences trying to get going with React but I just found this article ranty. I was also expecting something more interesting. No feeling of depth to the analysis, just "I did not like this and now I will complain about it". I'm guessing english is not the authors first language so I won't dwell on it but I found it somewhat hard to follow.

Thanks for your feedback I have tried to fix some grammar and syntax errors. Please ping me in case you find it still confusing

Re: An experienced Javascript developer’s account of learning React

#140

Earlier quoted context omitted.

Out of curiosity, what does everyone despise about Groovy?

It's not the new hotness anymore. Scala came along. The author of Groovey says Scalia is better. It's also semidynamic. So if you don't like that, you won't like that (tautology of the day). Updated for Scalia to Scala.

> The author of Groovey says Scalia is better.

You mean James Strachan? That was 8 years ago. In November last year he said "I still love groovy (jenkins pipelines are so groovy!), java, go, typescript and kotlin. I don't use Scala anymore." [1]

Sounds like he uses Kotlin instead of Scala, and only uses Apache Groovy in Jenkins pipelines. And given that the Groovy collections methods are disabled so they don't actually work in Jenkins, I imagine he uses Java 8 or Kotlin for that purpose.

[1] https://twitter.com/jstrachan/status/784333918078169088

Post reply on HN