Live data from Hacker News

Am I wrong in hating React JS?

medium.com

31–40 of 40 posts

Re: Am I wrong in hating React JS?

#31
post #23

Is React a fad? Yes. Is it here to stay? Yes. Should I get into it? Depends on what you need. If you are building a web application with complicated UX needs (protip: you probably aren't) and/or the team insists on React, you probably need React. If you want an easy time getting a job in the Bay Area right now, you probably need React. If you want to avoid having your comments downvoted on HN, you probably need React…

> protip: you probably aren't Citation needed. HN has this really strange assumption that everyone who talks about web technology is working on Wordpress sites or implements TodoMVC for a living.

I see exactly the opposite: folks building TodoMVC++ (e.g. the Stripe web UI) using J2EE-tier complexity, when all they really want is to avoid FOUCs.

Re: Am I wrong in hating React JS?

#32

The reasons why you should like react - forces you into an object oriented paradigm with constructors/destructors - mutation from external sources and internal sources results in a single function being run to refresh the output. - inline html/xml is your freind. You can see easily how a ui is structured rather than parsing a 300 line file to see what gets created, destroyed, appended, prepended anD etc - all jsx res…

If anything it forces you into it is functional paradigm (especially if you use flux/redux) with every component beeing a function of state. You mentioned it yourself in second point. To me react does not seem object oriented at all, at least in traditional way.

Re: Am I wrong in hating React JS?

#33
post #27

Is React a fad? Yes. Is it here to stay? Yes. Should I get into it? Depends on what you need. If you are building a web application with complicated UX needs (protip: you probably aren't) and/or the team insists on React, you probably need React. If you want an easy time getting a job in the Bay Area right now, you probably need React. If you want to avoid having your comments downvoted on HN, you probably need React…

Whats the threshold for "complicated UX needs"? I'd think for all but the very most basic bootstrap landing page (IE, if any of the value of your business other than a sales sheet is in your webapp) you'd want to use decent tools.

I have a lot to say on this topic, but suffice to say I think the decent tools being used today are far more complex than is necessary for building most web UIs that I deal with.

Re: Am I wrong in hating React JS?

#34

I'm with you on the embedded HTML in JavaScript files. There's a reason everyone went nuts for MVC, the seperation of UI code (in my opinion) just makes your life as a developer easier.

We're past static view components.

Today UI elements are dynamic things and the code that drives the dynamics should be kept close to the static representation of a given view state.

React actually separates UI code and interaction logic, as it should, by hosting the static part in the render function and the dynamic part in event handlers defined on the component. This is in my opinion a great balance of SoC / cohesion as it allows proper scoping of a UI unit and fosters controlled reuse.

I don't want to sound rude but we've had enough of this MVC fanatism that completely disabled many developer's creativity and took a lot of courage and energy to the React team, among others, to challenge.

Tying view logic (and only view logic) to static UI code is probably the only way to go on the path to proper UI component sharing and reuse. Whether we like it or not, whether we put the code in separate files or use any other artifice we're bound to make these two walk hand in hand. The last bastion being style. Which the React community tried to address, too.

At the risk of saying something obvious, I think we shouldn't reason on principles and habits. Progress can't be, and never is, driven by such forces.

Re: Am I wrong in hating React JS?

#35

You're not wrong in hating React, but it is a fad as much as no one wants to believe it. The reason I believe is because no matter how strong the framework, eventually it will be adopted (to some extent) into the native language (which is a good thing). Think about these frameworks: - jQuery - Coffeescript - Backbone at the time, if I had asked you if those were a fad, you'd think I was crazy. And yet, because of nat…

> at the time, if I had asked you if those were a fad I still wouldn't call jquery a fad, just obsolete

Are you perhaps thinking of JQuery UI? The core JQuery lib is still used. And for basic front end dev it really does offer most of the utility you'll look for in other libs.

1. Get and manipulate dom elements. 2. Register simple event handlers 3. Ajax calls that are simple (frankly all other ajax-ish APIs I've ever seen pretty much copy the design and approach of the JQuery one).

Also a pretty big ecosystem of simple highly focused add-ons. You (still) can get a long way with just JQuery

Re: Am I wrong in hating React JS?

#36
> I hate html in javascript. I hate JSX.

How about hyperscript? Functionally equivalent to JSX but it's pure JS, with no XML syntax.

   header(
     h1(Icon({name: icon}, [title]),
     p(subTitle)
   )
I don't think you can make an argument against building the DOM in JS (instead of using some random DSL to parse HTML template strings) without falling into the fallacy that JS === logic and HTML === presentation. But, you don't seem to be making arguments.

Re: Am I wrong in hating React JS?

#37

To reply to your complaints: > I hate html in javascript. I hate JSX. At least it's just HTML and JavaScript. In my opinion it's better than learning a new messy templating DSL, i.e. {{::item.name}} > I hate the lack of CLI. I hate the ridiculous amount of shit I have to do to simply get a project started. You can use the official Create React App CLI [1]. > I hate the sheer amount of boilerplate code and the verbosi…

You definitely have to learn a DSL - in JSX you have to use className instead of class for the HTML tag property. There are a few other examples of this, but the point is the argument doesn't hold water against Angular's templating language.

The reason why it uses `className` is because we're in javascript land (https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...) So it's not a DSL when you really think about it. It's javascript.

Re: Am I wrong in hating React JS?

#38

To reply to your complaints: > I hate html in javascript. I hate JSX. At least it's just HTML and JavaScript. In my opinion it's better than learning a new messy templating DSL, i.e. {{::item.name}} > I hate the lack of CLI. I hate the ridiculous amount of shit I have to do to simply get a project started. You can use the official Create React App CLI [1]. > I hate the sheer amount of boilerplate code and the verbosi…

You definitely have to learn a DSL - in JSX you have to use className instead of class for the HTML tag property. There are a few other examples of this, but the point is the argument doesn't hold water against Angular's templating language.

className has always been the convention for accessing the class attribute in Javascript.

https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

Re: Am I wrong in hating React JS?

#39
post #38

Earlier quoted context omitted.

You definitely have to learn a DSL - in JSX you have to use className instead of class for the HTML tag property. There are a few other examples of this, but the point is the argument doesn't hold water against Angular's templating language.

className has always been the convention for accessing the class attribute in Javascript. https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

And that's of course because pre ES5 you couldn't use keywords (class) as property names.

Re: Am I wrong in hating React JS?

#40
post #35

Earlier quoted context omitted.

> at the time, if I had asked you if those were a fad I still wouldn't call jquery a fad, just obsolete

Are you perhaps thinking of JQuery UI? The core JQuery lib is still used. And for basic front end dev it really does offer most of the utility you'll look for in other libs. 1. Get and manipulate dom elements. 2. Register simple event handlers 3. Ajax calls that are simple (frankly all other ajax-ish APIs I've ever seen pretty much copy the design and approach of the JQuery one). Also a pretty big ecosystem of simple…

You can, but it pretty much is obsolete at this point.

1. `document.querySelector()` and then just modify the DOM however you want.

2. `node.addEventListener()`

3. `fetch()`

There are still things that jQuery provides that aren't as simple to do with the built in functionality, but in most cases, you can get by just fine without pulling in all of jQuery. And in those cases where you can't, there are more focused libraries available for those specific use-cases.

Post reply on HN