Hacker News Reader

Comment by levemi | Hacker News Reader

After many Medium posts of uninformed, not very insightful complaints about react and the state of JavaScript I am becoming inclined to just avoid Medium posts about JavaScript in general.

Medium has become the analog to Tumblr posts for opinionated engineers to whine about things that don't really impact development in ways that matter.

Really all this developer had to do was talk about Hyperscript in a positive way and I would have found this post interesting instead of rolling my eyes paragraph after paragraph. Oh poor you and your angle brackets, such a burden! Putting HTML directly into my JavaScript is awesome and I never want to go back to separate template files ever again. It's wonderful and results in great code that works well, is readable, and is easy to test.

View on HN

Seriously. If you like it, use it. If you don't like it, don't use it. If you work with a team, take a vote.

This post spends quite a bit talking about beginners who are learning Javascript, React, and JSX all at once. Of course they aren't going to get it right immediately, if they didn't get tripped up on JSX they'd get tripped up on something else. "Beginners don't get it" might be the weakest argument I've heard so far.

This is a dangerous opinion and one that weighs the present too heavily over the future.

Pick languages/frameworks that will produce easily maintainable code and will survive naturally after your departure from a company. New developers have a learning curve no matter what. The steeper you make that curve, the more danger you put your codebase in and the more likely you are to set them up to fail.

I agree, a better process than voting would be "evaluate the advantages and disadvantages of each practice and determine which results in the highest quality, most maintainable code."

But since when have we been any good at identifying future needs or identifying maintainable code? Just be consistent, try to at least leave SOME documentation for the next guy, and don't be actively malicious.

I think his points about new developers having to learn JS, React, and JSX all at the same time and then context switch between them in ways that aren't entirely clear was pretty spot on. I don't know how you draw that comparison without mentioning the shortcomings of JSX. Also with Hyperscript you're still building your markup directly in your Javascript, just using JS for it instead of JSX, not templates. Not sure if that's what you meant with your "separate template pages" statement.

But optimizing for those with no development experience isn't one of the goals of React. From the "thinking in react" page in the docs,

"React is, in my opinion, the premier way to build big, fast Web apps with JavaScript."

Nowhere in the documentation does it stress that it's easy to learn or ideal for beginners. If you don't know Javascript, writing React applications (or any application, really) is going to be painful. Full stop. JSX adds cognitive load when writing code, but reduces cognitive load when comparing the DOM to the component that created it. Given the amount of time I spent debugging and refactoring, I'm happy to use JSX.

Whether or not React's goal is to cater to beginners doesn't make the argument any less valid. Also React doesn't equal JSX. The React docs also mention how to do things without JSX.

Maybe it's the article's title that has understandably rankled some people by seemingly maligning JSX. However, I think it's a very valid concern to have when ramping up a team that's unfamiliar with JS and React.

It doesn't make it less valid, but "is JSX bad" has been done to death. It's been the subject of Medium posts like OP since I started using it in 2014. If you're "ramping up a team that's unfamiliar with JS and React," maybe you should be deciding whether to hire somebody experienced with JS and React instead of deciding whether or not to use JSX.

Agreed, the title was link bait done to death.

I'm not in the situation of ramping up a team unfamiliar as the author was. But it sounds like he was experienced with JS and React himself. Or are you suggesting he should replace his team with people more familiar with JS+React?

Consistency is valuable for everyone, particularly when refactoring. You can't refactor JSX according to the rules of JS or the rules of HTML - you have to shift gears to refactor according to the rules of JSX (particularly hard since you're probably refactoring the surrounding JS at the same time). If it's possible to retain the code:dom correspondence with an approach that's based on (and follows the same rules as) vanilla JS - and it sounds like this Hyperscript does that - surely that's an improvement.

The context switching argument is BS. That's just like complaining about 'context switching' when you have to use an hash/map/dict/object literal or a comment.

It's either this or "functional JavaScript" posts on my feed. Really, I've seen about ten "guides" about it in the past two weeks.

The author does seem to not consider the case of where you already have HTML and just plop it in and make it dynamic. Luckily JSX is completely optional, and a JSX->hyperscript converter being well possible means the syntactic choice remains only a slight annoyance at most.

> Putting HTML directly into my JavaScript is awesome and I never want to go back to separate template pages ever again.

Note that the author isn't suggesting a return to separate template pages. He is suggesting a system for creating React elements that uses simple functions and JavaScript syntax rather than the custom syntax of JSX.

This has been my view as well. Author comes off across as a 'tumblrina' and sort of obsessing over small annoyance rather than a serious writing on providing insight for real engineers who have better things to do than whine on medium

You could state your disagreement without casting aspersions on the masculinity and competence of the people you disagree with. Given that you yourself are wasting time reading posts on Medium and then whining about them on HN, I have to ask myself whether you are not a real engineer, or whether just maybe real engineers can whine about things sometimes.

Reply on news.ycombinator.com