Hacker News Reader

Comment by nobody0 | Hacker News Reader

This, that's why React was a bit revolutionary at its time. No customized template dsl. Just speak JS.

Writing HTML programmatically or using JSX are both unfortunate React-isms.

Not saying that Angular's banana box is ideologically superior, just that all JS frameworks have idiosyncrasies.

Honest question, why? The problem one always runs into in client side apps is you need various features like conditionals and looping when rendering your HTML. This has lead to a proliforation of templating languages that half-assedly implement these features. Moving to using a full programming language for generating your HTML removes the need for janky inconsistant templating languages.

Browsers support HTML and JS (and a few other things not relevant to this point).

Neither HTML or JS on its own will do what you're describing. HTML doesn't allow binding to a data source. JS doesn't allow you to write HTML declaratively. So, people build abstractions.

If an abstraction ever became popular enough and futureproof enough, there could be a case for supporting it natively. But I don't know of anything that currently exists and does what you're describing.

Natively no, but writing some JS code that will take an array of objects and turn it into a DocumentFragment is a trivial exercise. And once you're representing your HTML as data, looping and data binding are trivial.

You're right. But how often do you want to rewrite that code? It may be worth accepting a few -isms (and the associated performance hit) in order to be able to write something like this instead of having to bang out the imperative version:

What are you talking about? That's the exactly the purpose of jsx - manipulate html with straightforward javascript. and jsx is just a wrapper for React.createElement().

I find JSX is only straightforward for the simple cases. Often you wind up with unreadable, convoluted garbage because someone was trying to be clever with too many ternary operators, etc.

If you can refactor JSX with simpler js code then you should do that. It's just js expression. If u find reading js expression is harder than all those custom operators in other template languages, you can always switch.

JSX isn't HTML. Is it truly less cognitive burden to have a language that looks like HTML but isn't? With properties changed because they're reserved words? And with control statements from other languages supported inline?

If someone gave me a language that looks like Lisp but with car and cdr renamed to something else, is that really making my life easier?

What cognitive problem do you have? It's just syntax sugar to let you easily manipulate the dom tree. Generating dom nodes and intertwined logic becomes trivial when you have jsx. If u want a list u can do dataList.map(data -> SomeComponent); or do ifTrue ? Component1 : Component2; or even use a function to return conditionally with a switch.

JSX is not HTML because it need to blend logic and HTML seamlessly. React is not static site builder, it's an app builder. If your project doesn't need this sure go ahead. Otherwise are there much better choices?

JSX is exactly a customized template DSL. It's not a particularly difficult one, but that's exactly what it is.

> JSX is exactly a customized template DSL.

Yes, but its a template DSL for JavaScript (and TSX is one for TypeScript), not a template DSL for HTML.

Building JSX outputs JS, not HTML.

Yes, that's true. I don't see why it's significant though. There doesn't seem to be any inherent reason why an HTML-hosted DSL is more difficult to learn or use.

Reply on news.ycombinator.com