Hacker News Reader

Comment by phat4life | Hacker News Reader

Personally, I prefer more web-component like frameworks. Vue.js is more usable, and easier to understand than React, but stuff like React Native is why React.js is worth learning.

I strongly dislike the JSX syntax as well. Its messy, and difficult to read. I would like my to write my components as dom nodes, like with Vue.js, Riot. The way that react.js handles css, is also messy. I would rather just defined a <style> tag like in Vue.js.

View on HN

> I strongly dislike the JSX syntax as well. Its messy, and difficult to read.

I've read quite a few criticism of JSX but "difficult to read" is a first. It's not significantly different than any templating system out there (eg, ERB). It's just XML with interpolated code, what's confusing about it?

> what's confusing about it?

In my opinion the confusing part is mostly the fact that taking a markup language and embedding it into a scripting language is really awkward. You have two completely different types of syntax not only existing together but working together.

Also I've worked on multiple teams where designers will re-style and even change the markup of pages but trying to get non-developers to do this with JSX is just painful.

I find HTML and the DOM API awkward at times but since that's the final state I just prefer to work with that.

Well, now.

Firstly: context switching is an inevitable inconvenience, but in JSX you're context-switching line by line between two radically different syntaxes.

Secondly: switching into what? It's not HTML (Angular templates, for instance, are not going to win any beauty contests, but they are technically valid HTML). XML? No, not that either. So ... something that looks kinda like HTML/XML, but which isn't really. It's perfectly legitimate to sacrifice aesthetic elegance for the sake of adhering to well-understood standards. But if you're not going to adhere to that, then why pick something that is merely similarly ugly? I don't get it.

Thirdly: templating/view layers always face a trade-off - either they are embedded within the host language, or they use an external DSL which is parsed/compiled by the host language. The trade-off is: better change of 'correctness' and cleaner interop with the rest of the language if it's an internal DSL; on the other hand, with eternal DSLs, at least the possibility that non-engineers will be able to work on things. With JSX, you end up grafting an 'internal' DSL simply by adding a whole pile of syntax to the core language. You don't have the advantages of the separate template language, and you lose some of the advantages of the other by requiring a whole pile of extra tools. JSX is an attempt not to choose, in a situation where compromise is basically impossible. Hence its extreme awkwardness - just like E4X before it.

React has done some good things: it's put performance on everyone's agenda in a big way (Hallelujah!), and it has acted as a testbed for interesting front-end architectures. JSX, however, I feel is a serious mistake. I actually enjoy writing React code through Reagent or similar, but in native JS and especially JSX, it just feels awful. I just don't want that in my editor window.

> in JSX you're context-switching line by line between two radically different syntaxes.

Every programming languages has multiple syntax's to learn. That's just like saying switching from array literals to hash literals is an inconvenient context switch, or from strings to comments.

> It's perfectly legitimate to sacrifice aesthetic elegance for the sake of adhering to well-understood standards.

React goes out of its way to make it look like you're working with the real DOM, but in a different way. Take the event system for example: https://facebook.github.io/react/docs/events.html

In that sense its even closer to the standards than Angular is - it still uses events instead of databinding.

> the possibility that non-engineers will be able to work on things

Its highly suspicious that it was ever possible because of tight coupling between template and its data. Just look at an Angular controller and view. Tell me that two different people can work on that in parallel, one on the JS part, the other on the HTML part. Its impossible.

At best you can have a designer work on the HTML part first, then a programmer can import it (a fancy word for copy paste + add all the dynamic behaviour), then perhaps the designer can do incremental design-related fixes but might need to consult the programmer regarding the data. The programmer can also do HTML fixes but might need to consult the designer regarding how they would look.

Lets see if that workflow works with JSX:

  * copy-paste: check
  * add dynamic behaviour: check.
  * tweak and maintain the design: provisionary check:

If the designer really can't handle the surrounding JS, (although given what you are saying it sounds more like the programmer cannot handle the sprinkled HTML), you can move the render function in a separate file:

  module.exports = function() { return (
    // JSX goes here.
  ); };

Problem solved.

Anyways, this is just staying inside the box with old aesthetic sensibilities developed from a bygone dark ages era. React is a peek at what HTML and JS could be, if only they actually worked together. Its also a snide remark * implying: "Hey WWW, you're doing a crappy job at supporting web applications. Let me show you how its done"

* not saying its intentionally snide, just that it might come off that way

In fact, with v0.14's stateless function components the "render" function alone can be used as a component (except props are passed as an argument rather than "this.props")

Watch out for space between words in your designer's copy disappearing though, because React chose to deviate from the HTML whitespace semantics.

    <p>
      Hello and welcome to our fancy site, where you
      can do all kinds of cool things.
    </p>

In JSX, that text will become "...where youcan do all..." and the recommended solution is to type

    {' '}

to insert a literal whitespace. [Edit: See spicyj's response; I was wrong about this, but the behavior is different from HTML in other cases.]

That, plus the way JSX confuses the hell out of language modes—Emacs, GitHub's rendering—makes me want to stop using JSX. I just don't enjoy using it, and I really do enjoy creating DOM elements with normal JavaScript syntax.

But like so many other things people argue about... it's just preference, and ultimately pretty insignificant.

(This is actually not quite true -- you only lose whitespace when one side of the linebreak has an element, not when both are text.)

Oh, thanks for the clarification. I was misremembering; I think my actual case was something like:

    <p>
      Hello, etc etc, please
      <a href="#my-neat-anchor">click here</a>
      to continue.
    </p>

Ah yes, I forgot about that catch. Its not always just simple copy-paste.

This exists for a reason. If you do this in HTML:

    <li>Hello</li>
    <li>World</li>
    <li>!!!</li>

You now have text nodes containing a space in between the <li> elements. These will subtly affect how the elements are rendered. In HTML, if you want to get rid of those text nodes, you have to write the elements on one line:

    <li>Hello</li><li>World</li><li>!!!</li>

Or use float: left|right styles to push the text nodes out of the way. Both are ugly solutions. With JSX, I don't have to think about that.

I've never even ran into your issue because I use React for web app development and so use translation strings (i.e. function calls) for pretty much all user-visible text. If you ask me, the trade-off React chooses here is adequate.

Sure. I'm mostly just saying you can't take HTML and cut & paste it into your JavaScript file.

React does not require you to use JSX. Writing views with React.DOM is actually a quite nice alternative. This article gives an explanation: https://www.packtpub.com/books/content/using-reactjs-without...

However, newer React and Babel versions no longer compile JSX to React.DOM methods as the article shows, but other methods. Example for Babel: https://babeljs.io/repl/#?experimental=false&evaluate=true&l...

What is it that you don't like about react and css? React actually has nothing to do with CSS - 'by default', you just include a stylesheet as normal. If you want to upgrade, you can just something like CSS Modules with webpack's css-loader to make per-component stylesheets a lot better.

I'm a massive fan of Vue, and have been using it since v0.10 (IIRC); one thing I find React does better than Vue however, is large applications. Vue maps brilliantly to dynamic components that are rendered in your page (no matter where said page comes from, be it Rails or PHP or nginx serving static HTML), and while Vue.extend() and the new props/component hierarchy that v1 gave us moves us a long way towards handling larger apps, I still find it somewhat lacking at times. That's likely just a function of the sheer traction and community support React has, mind you.

Reply on news.ycombinator.com