Hacker News Reader

Comment by kabes | Hacker News Reader

For me JSX really feels like old-school PHP, we all decided this sucks:

  <?php
  if (condition) {
  ?>
  <div>whatever</div>
  <?php
  }
  ?>

Yet in react everybody seems happy to do the exact same thing in javascript.

View on HN

It's not the exact same thing at all though. Declarative versus imperative. I'm sure someone's going to hem and haw about how they're the "effectively" the same, but they're really not. JSX is a breath of fresh air for front end development.

Straight from the react docs [1]:

  if (isLoggedIn) {
    return <UserGreeting />;
  }

How is that different?

[1] https://reactjs.org/docs/conditional-rendering.html

The difference is that the JSX snippet is translated in plain JavaScript which means you can automatically check for syntax errors, type errors (when using TypeScript or Flow) and semantical errors (by writing simple unit tests), whereas the PHP snippet is just a big mess. JSX also runs on clients, servers and mobile devices which is a big plus to me.

This is fine:

  <?php
  if (condition) {
  ?>
  <div>whatever</div>
  <?php
  {
  ?>

this not:

  if (isLoggedIn) {
    return <UserGreeting />;
  {

Did you read what I wrote?

https://news.ycombinator.com/item?id=16918654

This is the official example of using context from the react doc

  function 
   ThemedButton(props) {
     return (
       <ThemeContext.Consumer>
         {theme => (
           <button
             {...props}
             style=. 
   {{backgroundColor: 
   theme.background}}
          />
        )}
      </ThemeContext.Consumer>
    );
  }

I've been writing JavaScript for 15 years and this looks like gibberish to me. There's at least 3 context switches between JavaScript, JSX and CSS. We're abandoning separation of concerns and creating a monstrosity of programming by punctuation.

Er...why does this suck? What do you replace it with?

It sucks because you can't even parse it, you can't understand what's going on without mentally switching back and forth between markup and programming language even if the two are in the same file. You replace it with a framework that lets you treat HTML fragments as values in your programming language and write plain old code that follows the normal rules of the language, that can be refactored following the normal rules.

Hmm... JSX isn't HTML. I thought we established that.

Moreover, JSX components are plain old Javascript functions and classes. You write plain old code that follows normal rules if the language when you deal with them.

JSX DSL is there for convenience because it's, well, extremely convenient.

There are feeble attempts elsewhere to equate JSX with writing HTML inside PHP tags which fall apart the moment you give JSX more than a give-second cursory glance.

I wasn't talking about JSX one way or the other - just trying to explain what the issue with PHP was and how the industry moved away from it.

Yes. But... JSX is not HTML. And no, the issues PHP had with embedding HTML do not apply to JSX.

JSX is a paper-thin DSL on top of Javascript. JSX components are regular Javascript functions and classes. You work with them the same way you work with any function it class in JS. Unlike PHP where it was actual HTML interspersed with PHP code.

I get that JSX is a DSL that ends up being javascript. But there are a lot of arguments why we don't write HTML directly between the PHP which still apply to JSX, even though it's not HTML. For me as a programmer it doesn't matter what happens under the hood.

Whether I type `return (<button>foo</button)` in react or echo '<button>foo</button>' in php, it's the same thing from my point of view as an application builder.

> there are a lot of arguments why we don't write HTML directly between the PHP which still apply to JSX, even though it's not HTML.

Such as? This is the point in dispute, so you need to actually make specific arguments if you think they apply.

In the webdev world, everything old is new again

Reply on news.ycombinator.com