Live data from Hacker News

JSX in detail

blog.klipse.tech

61–70 of 73 posts

Re: JSX in detail

#61
post #26

It's funny how, for years, we've been trying to get away from HTML mixed with code (specially in spaguetti PHP), just to get back to something similar again.

It's not the same thing. JSX is a user experience enhancement for developers.

PHP's everything-is-a-template philosophy is also a user experience enhancement for developers. React's nested components may provide a much saner rendering model than PHP's glorified string concatenation, but that's a separate question from how their templates are parsed.

PHP templates advertise, and do in fact provides, most of the same benefits as JSX. There are almost no new concepts to learn, the syntax is the same as the language proper, and developers have the full expressive power of that language at their disposal wherever they want it.

In practice, however, this seems to fail more often than not in a couple of ways. First, inexperienced developers (i.e. all developers at some point in their career) have a hard time resisting the urge to inline their business logic into their presentation logic. And second, the resulting templates are as often as not illegible, often requiring a reader to trace substantial chunks of tangentially related procedural logic in order to understand what will actually be rendered.

It's important to remember that PHP templates seemed like a good idea at the time. They did, and do, have real short-term benefits, and talented developers can leverage those benefits to great effect. But it turns out those benefits come with real long-term penalties, and besides, many developers are too green or too pressed for time or just don't care enough about the task at hand to wield that power consistently well enough to reliably reap the benefits in the first place. The PHP community has spent the last decade painfully crawling out of that tar pit; I'm not thrilled to see the JS community happily diving into it.

Re: JSX in detail

#62
post #49

Earlier quoted context omitted.

>And why the hell you have to write code in JS that will be ultimately represented as HTML? If an analogy helps, the React virtual-DOM is philosophically similar to the very old and industry-accepted technique of double-buffering[1]. Your question would be similar to asking, "why the hell do you write pixel data to an invisible memory buffer if you're going to ultimately display it on the screen?" The plain old HTML…

> Your question would be similar to asking, "why the hell do you write pixel data to an invisible memory buffer if you're going to ultimately display it on the screen?" That's not an argument. VueJS for example also supports the VDOM thing and it doesn't require you to write templates in JS code. My point is that React requires you to cook templates in the way that's is more convenient for the React (as with JSX Reac…

>My point is that React requires you to cook templates in the way that's is more convenient for the React

And likewise, Vue.js requires one to "cook HTML" with extra Vue extended syntax such as "v-if", "v-else-if", "v-for", etc. to make it convenient for Vue.js. (See sibling comment from lilactown that went into more detail.)

Since you weren't questioning the validity of vdom but was actually wondering why one would write pseudo-HTML (aka JSX) if it's going to be ultimately rendered as HTML anyway, you can turn that around and ask, "And why the hell you have to write template v-xxx _code_ in HTML that will be ultimately executed as Javascript by the Javascript engine?"

Re: JSX in detail

#63

Experimenting with JSX has introduced me to two language constructs: the Pragma, and the Macro. I know that these might seem a bit pedestrian to most folks, but they opened up my understanding of programming languages considerably. I am genuinely a bit surprised that the Javascript community hasn't played around more with the possibilities that both can offer.

[deleted]

Re: JSX in detail

#64

Earlier quoted context omitted.

> And why the hell you have to write code in JS that will be ultimately represented as HTML? I only use React for React-Native, so my JSX gets turned into native objects. Have you ever written a non-web program though? The default mode for almost all native GUI kits is for developers to define the UI in code. I've never, ever seen a UI designer or a high level DSL (like HTML) that works better than code for non-trivi…

> Have you ever written a non-web program though? The default mode for almost all native GUI kits is for developers to define the UI in code. Surely I have. I do understand that with JSX you get the valid template model, not the raw HTML that will need to be validated and converted into the template model then. That's actually what I meant writing above message - it makes React's life easier.

> it makes React's life easier.

It makes the programmers life easier by allowing JavaScript, not just React, to reason about GUI components before they are rendered.

You can use JSX with something other than React if you want to. React just happens to be the most popular kit that is using it right now.

Re: JSX in detail

#65

Note that JSX is not limited to React. You can use JSX (or TSX in the case of Typescript) as a better replacement for Moustache or Handlebars. See here: https://github.com/wisercoder/uibuilder

I didn't think JSX made sense until I used it in Typescript (TSX). Having type safety and refactoring support in views and templates is wonderful. I know that both Vue and Angular have worked to build Typescript compiler plugins to support type checking their view files, but TSX is out of the box, has great editor support, and gives you the full power of Typescript's downleveling transpiler, too.

For what it is worth, the project I'm primarily using TSX in isn't using React either. It's built with Cycle.JS which uses competitor virtual DOM Snabbdom.

Re: JSX in detail

#67

Earlier quoted context omitted.

> You are not writing HTML when you write JSX, you are writing Javascript. And why the hell you have to write code in JS that will be ultimately represented as HTML? Is it because it simplifies some processes for the React's VDOM implementation? Don't you make your life harder in order to make React's life easier? If you say it's because you get template code linted in the same way as a regular JS code, I say that ot…

The problem with templates is, ultimately, they end up re-implementing a lot of whatever programming language they're built in. Things like `{{%if}}`, `{{%for}}`, helpers, etc. are simply ways to write code in a template. Which is fine on the surface; these are features that meet the requirements of creating a UI, it's not like we'd want a templating system without them. The issue is that now you have a ton of code (…

> (this is HUGE. I could write a whole blog post on this).

and please do

Re: JSX in detail

#68

Earlier quoted context omitted.

> You are not writing HTML when you write JSX, you are writing Javascript. And why the hell you have to write code in JS that will be ultimately represented as HTML? Is it because it simplifies some processes for the React's VDOM implementation? Don't you make your life harder in order to make React's life easier? If you say it's because you get template code linted in the same way as a regular JS code, I say that ot…

The problem with templates is, ultimately, they end up re-implementing a lot of whatever programming language they're built in. Things like `{{%if}}`, `{{%for}}`, helpers, etc. are simply ways to write code in a template. Which is fine on the surface; these are features that meet the requirements of creating a UI, it's not like we'd want a templating system without them. The issue is that now you have a ton of code (…

You are comparing with Handlebars templates, which bring an overhead on top of the HTML structure itself - in this case it makes sense to use JS instead of the custom syntax. But compare with Thymeleaf/Angular/Vue like templates - these are natural templates, you work only with HTML, controlling behavior using attributes which are part of the HTML.

> The problem with templates is

But the good part is that with natural templates you see stuff in a perspective and in a more plain/readable structure. It's like coding something in Assembler/low-level vs in Java/C#/JS.

Re: JSX in detail

#69
post #62

Earlier quoted context omitted.

> Your question would be similar to asking, "why the hell do you write pixel data to an invisible memory buffer if you're going to ultimately display it on the screen?" That's not an argument. VueJS for example also supports the VDOM thing and it doesn't require you to write templates in JS code. My point is that React requires you to cook templates in the way that's is more convenient for the React (as with JSX Reac…

>My point is that React requires you to cook templates in the way that's is more convenient for the React And likewise, Vue.js requires one to "cook HTML" with extra Vue extended syntax such as "v-if", "v-else-if", "v-for", etc. to make it convenient for Vue.js. (See sibling comment from lilactown that went into more detail.) Since you weren't questioning the validity of vdom but was actually wondering why one would…

> with extra Vue extended syntax

Syntax remains the same as it's still just HTML with a custom attributes.

Re: JSX in detail

#70

Note that JSX is not limited to React. You can use JSX (or TSX in the case of Typescript) as a better replacement for Moustache or Handlebars. See here: https://github.com/wisercoder/uibuilder

I didn't think JSX made sense until I used it in Typescript (TSX). Having type safety and refactoring support in views and templates is wonderful. I know that both Vue and Angular have worked to build Typescript compiler plugins to support type checking their view files, but TSX is out of the box, has great editor support, and gives you the full power of Typescript's downleveling transpiler, too. For what it is worth…

> downleveling transpiler

What's wrong with the JS "scene", in two words.

Good lord.

Post reply on HN