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

31–40 of 73 posts

Re: JSX in detail

#31

Post by spsoto »

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.

I used to think that way, but then you realize that JSX ends up behaving only as syntactic sugar for `React.createElement`.

If you have that clear, JSX is only syntax for the pure JavaScript you end up writing. Diving in the toolchain and ecosystem also helps you note that. Adding Webpack loaders to the mix, and then your application ends up only consisting of JavaScript files, where you abbreviate `React.createElement` with the old HTML tags.

Re: JSX in detail

#32

Post by camus2 »

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.

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

The difference is that PHP+HTML is basically just templating. The HTML you put in PHP isn't a type that the interpreter is aware of and PHP isn't going to validate anything about.

Javascript used to have E4X in Firefox until it was removed when ES4 effort failed.

https://developer.mozilla.org/en-US/docs/Archive/Web/E4X/Pro...

Like someone said separation of concerns =/= separation of files.

Re: JSX in detail

#33

Post by ageofwant »

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.

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.

Re: JSX in detail

#34

Post by baby »

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.

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?

Re: JSX in detail

#36

Post by ageofwant »

lkrubner wrote: post #28
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 c…

Developers can build whatever they want with the html/css/javascript stack we have today, and they have.

Its up to you whether or not you write semantically pure html using display agnostic , etc. structural elements and only use css for styling. That is, after all, what they are for.

You can have what you want by simply pretending that browsers do not have default rendering rules, and not use the html elements that are arguably presentation only things, like , etc.

Re: JSX in detail

#37

Post by blorenz »

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

It may be fairly easy to learn, but mentally evaluating context during usage will be the friction much akin to HAML.

Re: JSX in detail

#38

Post by shakna »

ghusbands wrote: post #14
viebel wrote: 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...).

In Lisp, if you created something like JSX, your IDE or text editor would still be unlikely to understand it, as it'd be a very complicated reader macro. It doesn't magically solve all macro problems. Doing it the Lispy way, though, you'd likely use sexprs directly, with maybe some normal macros, so you wouldn't have HTML-like syntax but would have something that worked nicely in your editor.

SXML has been around a while, and makes working with HTML in most Lisps a breeze. See this for example [0].

    '((html (head (title "My Title"))
         (body (@ (bgcolor "white"))
               (h1 "My Heading")
               (p "This is a paragraph.")
               (p "This is another paragraph."))))
[0] http://www.neilvandyke.org/racket/html-writing/

Re: JSX in detail

#39

Post by davexunit »

ghusbands wrote: post #14
viebel wrote: 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...).

In Lisp, if you created something like JSX, your IDE or text editor would still be unlikely to understand it, as it'd be a very complicated reader macro. It doesn't magically solve all macro problems. Doing it the Lispy way, though, you'd likely use sexprs directly, with maybe some normal macros, so you wouldn't have HTML-like syntax but would have something that worked nicely in your editor.

Lisp comes with a built-in templating system: quasiquote. Systems such as SXML (an s-expression representation of XML documents) build on top of that. This takes care of multiple problems with JSX: 1) writing HTML/XML is annoying (remembering to put the close tag in the right place, etc.) 2) JSX is a DSL, not an embedded DSL, so you need new compiler infrastructure to work with it.

Here is a snippet of real code that produces an SXML tree. It generates atom feeds for websites that use a static generator I wrote:

    `(feed (@ (xmlns "http://www.w3.org/2005/Atom"))
           (title ,(site-title site))
           (subtitle ,subtitle)
           (updated ,(date->string* (current-date)))
           (link (@ (href ,(string-append (site-domain site)
                                          "/" file-name))
                    (rel "self")))
           (link (@ (href ,(site-domain site))))
           ,@(map (cut post->atom-entry site 
                       #:blog-prefix blog-prefix)
                  (take-up-to max-entries (filter posts))))
By far the best templating system I've ever used.

Re: JSX in detail

#40

Post by shakna »

masklinn wrote: post #21
sbergot wrote: post #8

Earlier quoted context omitted.

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, SF…

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

That's not 100% true.

See SRFI-105 which gives you infix expressions without needing to wrap them, and mixing and matching is supported the moment you dive into reader macros.

    #!curly-infix
    (+ 2 {a + b + c})
You do need to enable the reader modification, either in your own read (useful if you want safe eval, and parsing in limited environments), in which case you'd just provide an argument to read, or if you want it globally it'll probably just look like:

    #!jsx
    DOM.render(
      Hello world,
      document.getElementById((string-append "hel" "lo"))
    )
Writing the reader would be considerable work, but hardly impossible for Scheme to play nicely.
Post reply on HN