Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSX in detail

blog.klipse.tech

Post reply on HN
Print view View original

21–30 of 73 posts

Re: JSX in detail

#21

Post by masklinn »

sbergot wrote: post #8
amk_ wrote: post #7

Earlier quoted context omitted.

I could be wrong, but I don't think a LISP macro can transform the structure of the code in the same way that the JSX pragma turns an XML tree "inside-out". For example here's the source for the Babel JSX transformer: https://github.com/babel/babel/blob/master/packages/babel-pl...

A lisp macro see a code block as a tree of symbols/primitives. It can do anything. This means that it is easy to write a library with a nice dsl, but hard to read other people's code.

> A lisp macro see a code block as a tree of symbols/primitives. It can do anything.

No, a regular macro still needs to be syntactically sensible. To handle arbitrary non-lisp syntax you need your lisp to support arbitrary reader macros (as in Common Lisp or — I believe — Racket) and that gets significantly more complex and involved and requires extensible/pluggable parsing.

Scheme does not have that for instance, SFRI-10 reader macros need to be wrapped in `#,()`, you can't just dump JSX or XML in Scheme source and expect it to work.

Re: JSX in detail

#22

Post by iMark »

danenania wrote: post #11

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.

Our team moved from hyperscript to JSX as well.

Personally, I find JSX much more readable, and there was little love for hyperscript on the team.

Re: JSX in detail

#25

Post by Androider »

thomasfl wrote: post #19

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.

Re: JSX in detail

#26

Post by omegote »

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.

Re: JSX in detail

#27

Post by dudul »

omegote wrote: 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.

Can't upvote this enough. Each time I try to dive into React/JSX I have some dark visions of PHP and JSP in my head.

Re: JSX in detail

#28

Post by lkrubner »

omegote wrote: 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 conclusion. It became clear to me that what developers wanted to do simply had nothing to do with HTTP/HTML. We don't yet have the technology to do what developers want to do. HTML was an interesting experiment, but it suffered from a dual mandate. Sir Tim Berners Lee wanted HTML to both structure data and also present it in graphical form. Almost from the start, developers were conflicted about which mandate they should obey, but the preference, since at least 1993, if not earlier, was to give priority to the visual. For all practical purposes, developers saw HTTP/HTML as GUI for IP/TCP. Previous IP/TCP technologies (email, gopher, ftp) had lacked a visual component, but HTML finally offered a standard way to send things over Internet and format the end result visually (emphasis on "standard"; I could insert an aside here about X window systems and some cool software of that era, but every app implemented their own ideas about visual presentation. X-Emacs, for instance, had its own system for visual formatting over a network)."

The point is, HTML was an interesting experiment, but we now know that it doesn't work for what developers want to build. So it is time to get rid of HTML and move on to something better.

Re: JSX in detail

#29

Post by viebel »

Here is the author of the Klipse plugin[1] that powers the interactive code snippets.

I've opened a github issue[2] to suggest to integrate the Klipse plugin on react.js official documentation. If you like the code interactivity, feel free to express yourself on the github issue[2].

1: https://github.com/viebel/klipse 2: https://github.com/facebook/react/issues/10646

Re: JSX in detail

#30

Post by bananicorn »

viebel wrote: post #4
brochington wrote: post #3

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.

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 essentially the same, just more restricted?

Post reply on HN