JSX in detail • Hacker News Board

Re: JSX in detail

#71

Post by arvinsim » Sat, Sep 09, 2017, 11:29 AM UTC

vladimir-y wrote: post #69

jasode wrote: post #62

Earlier quoted context omitted.

>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.

I don't get this obsession with "just HTML". Is it just for its own sake? What tangible benefits do you get when it's laid out that way?

I am fairly certain the reason is not readability because a lot of people get by JSX just fine.

Re: JSX in detail

#72

Post by jasode » Sat, Sep 09, 2017, 12:14 PM UTC

vladimir-y wrote: post #68

lilactown wrote: post #51

Earlier quoted context omitted.

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 natura…

>Angular/Vue like templates - these are natural templates, you work only with HTML, [...] the good part is that with natural templates you see stuff in a perspective and in a more plain/readable structure

If you're using adjectives like "natural" without qualifying it with "in my opinion", it means you don't really understand the higher meta level discussion.

It is not objective fact that embedding a Turing Complete programming language inside of HTML via custom attributes such as Angular "ng-xxx" and Vue "v-xxx" is "natural". Many find it quite unnatural and unreadable![1].

If that's your personal preference, that's fine but be aware that many see HTML custom attributes to express a pseudo-language ("ng-for", "v-for", etc) is not really HTML. Yes, it's cosmetic HTML for appearances sake but not semantic HTML. The semantics is the pseudo-programming-language that's executed by Javascript. If you're unaware, the extending HTML with custom attributes for expressing code is an example of The Inner Platform Effect.[2] It doesn't matter whether you use new HTML custom tags[3] or custom attributes; that's just a difference in cosmetics.

[1] Examples:

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

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

[2] https://en.wikipedia.org/wiki/Inner-platform_effect

[3] tag soup to express a pseudo-programming language in HTML: https://blog.codinghorror.com/web-development-as-tag-soup/

Re: JSX in detail

#73

Post by lilactown » Sat, Sep 09, 2017, 2:02 PM UTC

vladimir-y wrote: post #68

lilactown wrote: post #51

Earlier quoted context omitted.

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 natura…

What's natural about them? Controlling behavior through attributes is one of the silliest ideas invented, IMO.

I've used Angular - frankly, its template syntax is horrendous. I had to learn a ton of new semantics (`whatever` `(whatever)` `[whatever]` `#whatever` all have different execution contexts), and ultimately they've re-implemented most of JavaScript and* Angular inside of this HTML template syntax. Vue is about the same AFAICT. There's a lot of good in these frameworks, but templates is not one of them.

I don't understand your comparison to Assembler. How is this more like Assembly than a high level language?

React:

    return (
      
        
        {heroes.map(hero =>
          {hero.name})}
         ... 
      
    );

Angular template:

    Save
    {{hero.name}} 
     ...

Think of it like this: in templates, you write a string that will be tokenized and compiled into an AST, which then get interpreted by the host language. In React (or whatever other vdom-building library you want to use), you generate the AST using functions in the host language. This is simpler, more powerful, AND (in this day and age) easier to use.

Here's something neat about the React example, too: since it's a pure function, it can easily be unit tested without rendering to a DOM or doing some weird string stuff.