Hacker News new | ask | show | jobs
by riebschlager 3689 days ago
I want to understand the appeal of React, I really do. But I open a project like this in my editor and my linter starts going nuts from all the markup in the JS. And my built-in biological linter starts getting queasy just looking at it.

Ugh. I just don't get it. Am I just old and curmudgeonly? And what's with the 200+ line package.json. That's a helluva lot of tooling for a simple web app. GET OFF MY LAWN!

6 comments

I don't know what editor or linter you use, but there are increasingly many that support JSX and can give you meaningful feedback about it.

As for your biological linter- you will be surprised at how quickly you are able to get used to it. The key for me was to stop thinking of it as HTML or markup- because it isn't. It's really just a different way to call functions and create objects.

It's far better than handlebars or other template languages because it's an actual regular syntax that you can use a linter with so you know it's going to work as you intended.

What linter are you using? ESLint handles JSX fine as far as I know. And with eslint-plugin-react it actually does some pretty neat validation on it as well.

I will say that I initially disliked the inline markup as well, but it honestly just makes practical sense. When we used Handlebars still, I always had the template open in a split when I was editing a view anyway, why not just keep it all as one contained unit?

I'm using JSHint. I know it's just complaining because of the way I have my .jshintrc set up, but this markup-in-scripts thing is a big mental shift for me. But hey, I'll try anything once.
It's definitely a big mental shift, but it's worth giving it a proper go.

For those of us who have been coding since before there was even JS, it's hard to let go of the Html / JS split but honestly, it's so much nicer when you just grab the React approach and run with it.

>>this markup-in-scripts thing is a big mental shift for me<<

Yes for me too.

While making web applications with JEE and PHP for a decade, every best practice article on creating maintainable web apps told me to keep markup and logic different. That too in different files preferably in different folders like Controllers, Views, etc. Same for not mixing JS and CSS with HTML. And in practice it worked very well for me. So when I saw React's approach of putting JSX straight in JS code, I was thrown off a bit.

Even Angular 1.x felt wrong with adding nonstandard directives in plain HTML. Common wisdom before Angular was only to use standard HTML/XHTML that passes W3 Validator, then use JavaScript to enhance the page.

But then I just made peace with Angular and React way of doing things. If I want to get the benefits of the Angular/React eco system, then I need to use their approach, and still make sure that I produce maintainable code.

The appeal of React is that frontenders realized that the slow part of frontend is DOM manipulation. React keeps a virtual DOM, and only tells the browser to change those elements that actually changed. The big-picture explanation of this is it does this by maintaining data about your components, and it knows the difference between "state" things (that can change) and "properties" (that shouldn't ever change). Components are only rerendered when their data is dirty. Because React manages this for us, it saves us a lot of code and brainpower, while keeping our stuff fast.

I have been told that .NET works in a similar way, but with a key difference of that diffing happening on the server, so it isn't as fast. This is just hearsay, please don't take my word for it, I don't claim to know how .NET works.

What's with that 200+ line package.json? That's like a makefile, with everything already configured for you. Sure, it's a lot of tooling, but you could say the same about most software development tooling. Why is XCode 4 gigs? That's a lot of libraries just to create simple mobile apps. Back in my day, all we needed was a tiny WML XML 200 byte file to display to a cell phone. And yet, here we are, in the future.

.NET doesn't work like that. Why would a server have to diffing? It's outputting a string, no concept of the DOM.

Perhaps you're thinking of components (or "controls" as they're known) in WebForms for .NET? They had a component style architecture but everything about them was difficult to understand and hard to use. Compared that to React where components are cheap and easy to build/compose, to such an extent that almost everything even things which don't actually render their own UI) ends up as components in React.

I don't blame you, the linter/editor integration is not quite mature yet, but thankfully getting better. And I don't believe React is necessarily the right JS view library for all situations, though it's often one of many (many!) viable ones.

At the risk of getting long-winded, I like React, not because it is the best among its peers of JS view-layer libraries, but because it has an effective ecosystem that can give you a fairly consistent development experience in a somewhat narrow set of use cases.

To put it in more concrete terms, I see efforts like React Native as something that can give a single developer or a small team some reach into several different platforms with some reusability of the code base + tools + dev workflow, though none of the implementation will be the best-of-breed for any of the platforms (maybe with the exception of desktop web browser).

I could see many people disagreeing with it, and I could see myself being convinced by them, too. But really, it's something I've had easy enough time learning to use in production and made some parts of development work easier than the ball-of-mud feeling I had in the past using others, so I've found that to be a plus.

But I truly empathize with the red squiggly lines in the editors! :)

Then don't use JSX! Completely optional, and many prefer to skip it.
> Am I just old and curmudgeonly?

Yes

To be fair, when I see "Yet moar tweaks" as a commit message, I start to wonder if I am old and curmudgeonly too.