Live data from Hacker News

JSX in detail

blog.klipse.tech

51–60 of 73 posts

Re: JSX in detail

#51

Earlier quoted context omitted.

JSX is not HTML. You are not writing HTML when you write JSX, you are writing Javascript. You are using a more convenient syntax to generate the virtual dom. All this hand wringing, navel gazing cargo-culting JSX gonna eat my baby bs is unnecessary. The PHP/html templating lessons of yonder simply does not apply.

> 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 (it is code, btw) living in a templating language that probably doesn't have as good of debugging, documentation, performance, encapsulation, composition, etc. as the underlying language it's using to process the template. It's up to the maintainer of the templating system to handle re-implementing that, and if you end up in a situation where it doesn't actually meet your requirements, you either have to add these basic language features yourself or start from scratch.

That's why things like React and Hiccup (and even more advanced, something like Racket), etc. have gained huge popularity and mind share: instead of re-implementing the programming language in a template system to show HTML, let's implement an embedded DSL to conveniently write HTML.

Then suddenly we get away from managing gnarly data dependencies, stack traces through templating systems, and writing stuff like this:

    {{%if medicare_eligible %}}
    Here's some discounts!
    {{% else %}}
    You gotta pay full price
    {{/if}}

    // ...
    templateSystem.create('template.hbs', { medicare_eligible: user.age >= 65 }

To just:

    if (user.age >= 65) {
      return Here's some discounts!
    } else {
      return You gotta pay full price!
    }
Once you are writing in an embedded DSL, you no longer need to worry about re-implementing all of the constructs of the underlying language; it's laid there at your feet.

Furthermore, by modeling your view as simple functions and data, you get all the features of data manipulation (huge productivity gain; don't need to write to rewrite or relearn `map`, `reduce`, `for`, serializing, etc.) and function composition (this is HUGE. I could write a whole blog post on this).

Re: JSX in detail

#52
post #6

Earlier quoted context omitted.

who needs JSX when you have hiccup!

Possibly a more uniform treatment of components versus "literal elements", but yeah the value proposition becomes very low. In fact I'd argue the value proposition of JSX is already relatively low when you factor in hyperscript in regular javascript (and yes there are component-compatible hyperscript helpers for React).

I think that Hiccup's idea of writing the tree as a tree-like data structure is superior to writing a tree of function calls.

I tried doing something similar in JavaScript; the result looks a bit silly (I realized the elegance of not needing to delimit lists with a , in LISP right here) and has questionable performance: https://github.com/Lokeh/hux

Re: JSX in detail

#53
post #34
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.

spaguetti PHP has been replaced with PHP in templating. See Blade in laravel for example: https://laravel.com/docs/5.5/blade So it totally makes sense to continue with this trend. Unless you have a very static website you don't really have a choice. edit: woot, you don't use in Blade anymore?

I don't think you ever used . Only thing I recall is that there was a debate over double "{{" or triple "{{{" as the default for auto-escaping output.

Re: JSX in detail

#54
post #4

Earlier quoted context omitted.

In LISP based languages like ClojureScript, macros are part of the language. No need to build tools like JSX (that requires to run on webpack + IDE tooling etc...).

They work something like this in LISPs, right? Like, can you define new language constructs with them? http://www.red-lang.org/2016/12/entering-world-of-macros.htm... (BTW, have a look at red for desktop apps, it's not even at 1.0 and already fucking amazing) But on topic; Are Macros a well-defined "thing"? Since a macro in C, seems to be rather different from a RED or LISP Macro. Or is it just that C macros are esse…

C macros are text substitution, implemented in a separate less-expressive language (the C pre-processor).

Lisp macros access the input program fragment as structured data, and manipulate that using the same Lisp functions and data structures that you use for regular, normal Lisp code.

I think that both forms are technically Turing-Complete, but Lisp is more expressive. In particular, it's much more common to see Lisp macros that destructure and reform their inputs, where C macros tend to see their inputs as black boxes that can't be opened. The textual-substitution model of C also has some extra perils, because code fragments can be context sensitive (such as creating identifiers that are already in scope).

In both cases, Macros are well-defined "things" in the sense that they are thoroughly defined in their respective language documents, but in both cases they are not first-class language items because they don't exist at run-time.

Re: JSX in detail

#55

Has anyone else made the switch from JSX to hyperscript? JSX works well enough, but I love the consistency and composability of building views with plain old functions and data structures.

Yeah, I wrote about it last week:

https://medium.com/@alexkrolick/writing-react-components-for...

"Overall it's not a bad experience. JSX makes HTML feel more at home, but tends to obscure the underlying Javascript. Composition and higher-order components are more obvious in plain JS. If I was writing a library using those patterns heavily I might be tempted to go JSX-free even if bundling with Webpack + Babel."

Re: JSX in detail

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

You bring up a point that was discussed 35 days ago: https://news.ycombinator.com/item?id=14925899 Tarikyn said: "Most developers I knew in person didn't care about CSS or didn't 'get' it." Part of my response was: "Some people looked at the chaos of non-standard HTML and decided the Web was successful because it had been broken from the beginning, and it had learned to work well while broken. I reached a different c…

HTML wasn't intended as an application platform, but for hyperlinked documents. That developers are using browsers for apps has economical reasons (eg. end users not willing to pay for software). That HTML isn't a good fit for a purpose it never was intended for is hardly TBL's fault, is it?

Re: JSX in detail

#57

Hyperscript markup looks like a nice replacement for JSX. The source for hyperscript-react is 50 lines of code, including comments and empty lines, so it's fairly easy to learn: https://github.com/mlmorg/react-hyperscript/blob/master/inde...

To me this looks much less readable than the equivalent JSX. JSX has been such a non-issue for me, it's extremely reliable and you can use all the new JS map/filters, loops, etc. instead of learning some half-finished template language.

> learning half-finished template language

javascript?

Re: JSX in detail

#58
post #49

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…

>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 React gets DOM/template model pre-validated, no mess with converting HTML code to the template model), not for the template makers.

Re: JSX in detail

#59

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…

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

Re: JSX in detail

#60
post #48

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…

It never gets turned into HTML. It gets turned into JS, which, eventually causes calls to `createElement(...)` etc. to happen. You are writing declarative code that says what the UI should do. It is NOT - and I cannot stress this enough - a "template langauge" in the same way as Handlebars or PHP. There is no string interpolation anywhere.

> It never gets turned into HTML

Really? So users get the JS code in the browser rendered in the same way as the code source looks, not the dynamically built DOM model which has the native representation form of HTML? Surely JSX is an abstraction layer on top of the createElement thing, and that thing is a part of the building strict template model scenario.

Post reply on HN