13 ms·

Alternatives to JSX

104 points by bloomca 8y ago

austincheney 8y ago
I am getting a 404.
- masklinn 8y ago
  Works for me.
hn_throwaway_99 8y ago
Wow, after reading this, I'd be surprised if anyone could come away with the conclusion "Yeah, that's better than JSX." I think the general distaste for JMX is that it "feels" backwards initially: it mixes in HTML snippets within code, while many people are used to template files, which are mainly markup with small bits of "presentational" code injected. But once you realize and really understand that JSX is just shorthand for javascript calls (and the article does a good job of explaining this), you hopefully eventually reach an "Aha!" moment of thinking of JSX in terms of underlying component creation. That's what happened to me, anyway,.
- masklinn 8y ago
  > Wow, after reading this, I'd be surprised if anyone could come away with the conclusion "Yeah, that's better than JSX." IDK, hyperscript (or even just aliased createElement) is enjoyable, not that verbose, and not needing a compilation pipeline just for JSX is nice. As in, I want to drop in an interactive bit inside a wider static page, dropping in react's JS (or linking in a CDN copy) and using createElement is way more convenient than having to set up a compilation pipeline.
  - tracker1 8y ago
    I'm using webpack/babel and ES6 syntax anyway, so the transpile doesn't bug me. It's also very close to E4X which I really wanted for a very long time, but never gained acceptance outside of ActionScript 3 (Adobe) and Mozilla. VB.Net also has a similar literal syntax).
- brylie 8y ago
  That makes sense, it's like an HTML-esque DSL in JavaScript. I'm learning Vue recently, and it seems that Vue templates are also rendered in a JS function. This is perhaps similar to JSX, but the semantics seem closer to HTML. Are there other frontend component libraries that embrace web standard HTML and CSS, and in particular Web Components?
  - jgalentine007 8y ago
    Yep, with Vue single file components you can paste in your plain HTML (and css/sass) and it will just work without having to be properly formatted XML, as long as there is a single root.
- mateuszf 8y ago
  Yeah, usually the initial dislike to JSX is because of bad, past experiences of people mixing view code with domain logic, storage, often SQL. But once people realize that React handles only view - some XML in there makes a lot of sense, since HTML/XML is core object in the view domain.
- jsf01 8y ago
  The author doesn’t do justice to hyperscript. Hyperscript’s one-to-one mapping with CSS selectors is great for readability while remaining terse. For example: let value = ‘example’; let x = Math.random(); h(‘form.Foo[action=/whatever]’, h(‘input.Bar[type=text]’, { value, oninput(event) { value = event.target.value; } }), h(‘button.button-small.button-primary[type=submit]’, (x > 0.5) ? h(‘strong’, ‘Submit’) : h(‘em’, Submit) ) ) vs. let value = ‘example’; let x = Math.random(); <form className=“Foo” action=“/whatever”> <input className=“Bar” type=“text” placeholder={} value={value} onInput={ (e) => value = e.target.value } /> <button className=“button-small button-primary” type=“submit”> { (x > 0.5) ? <strong>Submit</strong> : <em>Submit</em> } </button> </form> Although the example is contrived, it highlights several of my pain points from when I used react/jsx. The equivalent jsx requires transpilation, dipping back into js via {}, is far more verbose, and is particularly annoying when logic inevitably becomes part of your template. Whereas hyperscript style js solutions to view templating have straightforward access to loops, array methods, ternaries, objects, functions, etc. jsx requires you to either reinvent js functionality as components or switch back and forth between contexts to use js in your jsx template. Hyperscript also nicely separates static vs dynamic properties in elements, making understanding a large code base easier. All the static stuff is in the selector, all dynamic stuff is in the optional second argument. There’s no equivalent in jsx. As an aside, React’s hyperscript is kind of a pain to write on its own and there are many good reasons to stick with jsx if you’re using React. (Last I checked, React was strict about the second argument being an options object or null and the third argument being specifically an array of children.) My arguments in favor of hyperscript are most applicable if you’re using a library that was intended to be used with hyperscript, like Mithril or snabbdom.
  - hombre_fatal 8y ago
    One nice thing about JSX is the tooling/linting available for it. For example, tooling with warn when you have target=_blank without rel=noopener or whether you've defined the necessary attributes for each tag. It's one thing that got me using JSX years ago regardless of how I felt about JSX. Does the same level of tooling exists for hyperscript seeing that it's so much more string-based?
- duopixel 8y ago
  I don't think anybody would argue that the alternatives are better than JSX (if it were, why use JSX at all?), the step that you want to avoid is transpiling jsx. Why? Javascript's tool chain is complex, once you're using jsx you probable want `react-create-app` too, and things begin cascading from there. It's only worth it if what you're doing has a certain degree of complexity.
- awirth 8y ago
  When I was first introduced to JSX I found it very confusing because it was sold to me as "HTML in Javascript" but it's... really not. In particular these things threw me off: - You need to close tags you wouldn't need to close in HTML (breaks copy+pasted HTML) - Argument quoting isn't optional (breaks copy+pasted HTML) - HTML style Comments aren't allowed (breaks copy+pasted HTML) - Whitespace gets stripped for all elements (breaks PREs) - There's a JSX-specific syntax for "fragments" that seem to only exist for parser reasons? - Variable references work inside of text nodes but don't inside of attributes. After I googled a bunch and read the spec it helped a bit, but it left a bit of a bad taste in my mouth. I'm still left scratching my head over why you should be able to use an element as the value for an attribute though, like this: <foo a=<bar> test </bar>/>
  - wereHamster 8y ago
    Elements as values of attributes are extremely useful in custom components. <FancyArticle heading={<h1>...</h1>} body={<main>...</main>} />
    - sametmax 8y ago
      Other systems address that by providing a <template>, # include or {% block %} element that allow you to state where/what things should be inserted. I dislike the attribute way because: - attributes are used for everything. It seems nice and simple - one single way to do all things ! - but it means when you see something passed this way, you never know what it's for without diving into the code or doc. There is no convention. Is it data ? Is it a children ? Is it a callback ? If yes, what for ? - it allows people to make big inline blobs of code. And as often, when something ugly is easy on the short run, and the clean things is hard, they do the easy thing. JS is full of those stuff, and I wish we would not add new ones in the tooling we use. - The syntax is so unatural when you have been doing HTML for decades. I understand the desire not to be limited by legacy, but here it's not working around any limit. There are alternatives. So we just break habits to break habits. Again something quite common in modern JS: let's replace the wheel by a different one. Not better. Just different. Because, reasons. - It's easy to get wrong. Case in point, your comment and the parent don't even have the same syntax because one of you couldn't, from the top of the head, come up with the proper one.
- arkh 8y ago
  So JSX is like pure php templates.
  - bryanrasmussen 8y ago
    I remember reading somewhere that React was first written because someone wanted something similar to PHP workflow, but I don't see it, probably because I've only had a 1 month experience with PHP one time.
    - arkh 8y ago
      You can mix php and html. A minimal php hello world would just be "Hello World" in a file. I expect a templating engine equivalent to php's twig becoming the standard way to separate the views from the behavior soon enough.
      - krapp 8y ago
        There is a javascript fork of Twig that I used to play around with[0] but it's far from "standard." [0]https://github.com/twigjs/twig.js https://github.com/twigjs/twig.js
    - e1g 8y ago
      Indeed, JSX can be traced back to Facebook's idea of XML syntax on top of PHP called XHP [1][2]. It was never adopted by the community and did not break out of FB's custom PHP runtime called HHVM. [1] https://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919/ [2] https://docs.hhvm.com/hack/XHP/introduction
    - krapp 8y ago
      Hack actually supported it directly with XHP, which was great. Native support for extensible XML and data escaping out of the box is something PHP should have done as soon as was feasible, but unfortunately the best PHP can still do is string concatenation. Even Twig, which is basically an entire DSL with its own lexer, parser and everything, eventually just mashes strings together. I really wish XHP had been on the list of features PHP7 had taken from Hack and that it was default. Of course you can compile it in as a plugin, but that doesn't help the majority of PHP users nor does it encourage developers.
- jasonkester 8y ago
  You’re right that none of these alternative ways of writing JSX syntax are better than JSX. But I think you miss why people don’t like JSX in the first place; Having to compile your javascript sucks. If your framework requires me to have a build system in place just to write some javascript, I’m either not going to use it or, if forced, I’ll find whatever way I need to to get the code written without having to stand up a giant build system. Naturally, the true solution for people like me is to use Vue or Angular or another library that’s not as intrusive as React. But sometimes we’re forced, so we use that terrible createElement syntax. And come away disliking React even more.
  - chosenbreed37 8y ago
    Having to set up a build system is a bit of a pain. The value I get from being able to break down the UI in components and with the possibility of testing them independently makes it worthwhile for me.
    - markmark 8y ago
      I think people might just work on projects smaller than I'm used to. I set up a build on day one of a project and then just it for the next six months or year or whatever, so I really never see it as a pain point. As you say, well worth it for all of the benefits. Although frankly if I was doing lots of small projects I'm sure I'd have one of the many starter projects set up how I like it and it would just be running a script once.
  - dave7 8y ago
    Setting up a build system is not required, React with JSX can be inlined using plain old <script> tags just fine I believe. <head> <script src="https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react-dom.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/babel-core/5.8.23/browser.js"></script> </head> <body> <div id="app"></div> <script type="text/babel"> // React with JSX goes here </script> </body> It it is less performant than compiled setup, of course.
- genezeta 8y ago
  I've always thought the "HTML in JS" was in fact a strawman argument set up to deviate the attention from the fact that it is indeed a different syntax for function calls (and class instantiation). And it is actually that the thing that I dislike about JSX. I think it's a bad syntax for function calls/class instantiation. I do like hyperscript better than JSX... precisely because it's not a syntax for function calls. Because it's just a function.
  - TomMarius 8y ago
    It's not just that. The abstraction placed between a Node and an Element is very important and crucial for React (and for a good reason, this is similar to a well-known programming paradigm used for 3D games). I'd say there is a significant semantic difference that can be simulated by a function call (you can simulate nearly any statement).
  - abritinthebay 8y ago
    It doesn’t have to be function calls though. Conceptually it’s a nested model, that’s it. It could quite easily be a series of nested objects. The point is not that it abstracts functions it’s that it abstracts nested nodes. Anything else is a library implementation detail.
  - scriptkiddy 8y ago
    > I do like hyperscript better than JSX... precisely because it's not a syntax for function calls. Because it's just a function. You should check out Elm: https://elm-lang.org/ https://elm-lang.org/. It uses a hyperscript like syntax for rendering in a functional style. It's all just functions, and it reads that way too.
  - WorldMaker 8y ago
    It's not entirely a strawman, because there are legitimate concerns about separation of concerns that the "HTML in JS" argument worries about. Especially in the web world which still knows the legacy against fights of business logic in templates going back to "bad old PHP days", etc. There are good reasons to be skeptical about JSX simply because of the worry about how much business logic may accidentally be embedded directly into views. For JSX, the answer is typically to solve that in other areas of workflow and patterns of habit. But the war between "as dumb as possible a templating language" and "just let me use my real language for templates" will probably wage on in the web space forever.
- sametmax 8y ago
  If you dislike JS in the first place, having it also into your presentation layer isn't seen as an advantage. Plus, many people consider the presentation like something that should be limited and stay that way. Having a turing complete language in it defeat that purpose. But I agree, the alternative presented in the article don't address those issues at all so I can't see advantages over JSX.
  - hn_throwaway_99 8y ago
    If you dislike JS in the first place, you're probably not going to be doing much with React to begin with.
- bwindels 8y ago
  I hope/suspect transpilation will not be a given any more in the future. In that scenario, it's good to have alternatives to JSX.
mmmeff 8y ago
Awesome article. I appreciate the lack of bias. Thanks for writing this, OP. It's good to keep an eye on the horizon for potential alternatives to tech we use day in day out, but it looks like we're still on solid ground with JSX so no need to switch :)
ertucetin 8y ago
ClojureScript + Reagent
- schpaencoder 8y ago
  I was thinking the same thing. Hiccup is a much better way to represent jsx than jsx.
- mateuszf 8y ago
  The only one which is better than JSX imo.
- kgwxd 8y ago
  This combo is insanely beautiful. Not only does it solve the JSX issue, it does it without any new syntax and adds persistent, immutable data structures, something React is just begging for. My only problem is that I'd have to switch jobs for any chance of using it at work.
cdaringe 8y ago
Pug is a worthy mention. https://github.com/pugjs/babel-plugin-transform-react-pug/blob/master/README.md https://github.com/pugjs/babel-plugin-transform-react-pug/bl... wasn't mentioned
oorza 8y ago
There's also kotlin-react which let's you write React in Kotlin in a Kotlin DSL which looks exactly like your first imagination probably suggests: https://github.com/JetBrains/kotlin-wrappers/tree/master/kotlin-react https://github.com/JetBrains/kotlin-wrappers/tree/master/kot... It's also a pretty impressive demonstration of the typesafe flexibility of Kotlin's DSL support, but that's another conversation.
dazhbog 8y ago
I used to be really sceptical about JSX, 1 extra transp. step, anorthodox use of xml in JS, etc. Having been using it for the past 3-4 years I think its an above agerage elegant solution when it comes to templating solutions.
cygned 8y ago
What really bugs me about JSX is the complexity it introduces to the build pipeline - which might be fine for senior developers, but I regularly see junior developers struggle with configuration and errors.
- jayar95 8y ago
  To be fair, I see junior devs struggle with all build tools.
  - davnicwil 8y ago
    This is true, and further to this point, I don't think there is or should be any crossover between 'junior' and 'configuring build pipelines'. To me that's by definition a task for a senior Engineer. Put another way, if you have a skillset that includes configuring and/or maintaining non-trivial build pipelines, you're not a junior Engineer any more.
    - WorldMaker 8y ago
      Which is why as a Senior Engineer, some of the best productivity you can build for your team is to be able tell a Junior when starting a new application, "clone this template, npm start to debug it, it uses Typescript, you'll learn it as you work with it I promise, just let me know when you need help with something complex, and I'll be here to help you through all your PRs". (Or F5 to start in something like Visual Studio, depending on familiarity levels of Juniors you are trying to work with.) Junior developers are often just fine trusting build systems as block boxes once you've got them setup for them.
- nicoburns 8y ago
  You get a ton of other benefits from buying into a webpack-style build system though: - Modules - TypeScript - Newer JavaScript syntax - SASS compilation - Code splitting etc. For me, it's hard to imagine a medium/large sized JS project without using some kind of module system. And once you've setup the build system for that, you might as well use all of the other features that it enables.
keymone 8y ago
i'm surprised hiccup was never mentioned. ofc it's not for pure JS but there's this thing - https://github.com/lantiga/react.hiccup https://github.com/lantiga/react.hiccup though i never tried and don't know how well it works. still interesting.
- simongray 8y ago
  Hiccup is awesome for ClojureScript since we get to use plain Clojure data structures rather than a DSL that must be parsed in a separate step, but I think this advantage disappears when using it outside the context of Clojure/ClojureScript.
macco 8y ago
I would advice against using JSX alternatives. I come from a Clojure background and I like the ijk solution to just use an array to represent the virtual dom. But still I would recommend using JSX because it the "standard". Every documentation and problem solution you find on the internet is written with JSX. Using a JSX alternative will make debugging much harder for you.
deleted 8y ago
[deleted]
hardwaresofton 8y ago
If you read this article and thought Hyperscript might be something you wanted to try, please check out Mithril[0]. It's an excellent project, pretty decently fast (checkout the js-framework-benchmark[1] code, or more specifically the results of round 8[2]) -- but is currently suffering from a lack of recognition. It's the kind of project that absolutely doesn't care about that kind of metric (as in, the team seems to be more focused on slow, steady improvement of the library rather than chasing stars on github), but I figured I should say something. Shameless plug: I recently really wanted to contribute something (and kick the tires more) so I wrote an article that goes through replicating a simple mail design I saw[3] -- it might be a decent overview of what mithril is like to write (though I'm certainly not a mithril expert). This brings me back to the point at hand -- as others have noted, in my opinion one of the best things about hyperscript is the straight-forwardness with which you construct the render function. I'm not convinced it's necessary to segregate stateless/stateful components -- and mithril is simpler in that it doesn't introduce this dichotomy -- in the end there's the render function, and that's it. If you want to use state, go ahead -- if you don't, then don't. It's the simplicity I've wanted from component frameworks (and mostly get with Vue) without any of the posturing/looming complexity. Also there's the fact that you could write a completely vanilla es5 application with hyperscript (arguments whether you should or not aside) -- JSX is/was revolutionary, but is basically required in practice, which often makes people jump into bed with webpack without thinking, and makes frontend development harder than it has to be. [EDIT] - Another point for mithril is that it's self contained -- routing and ajax calls some with the framework. When people these days talk about "react" or "vue" what they're really talking about is react/vue + react-router/vue-router + flux/vuex and some other odds and ends. Mithril is by far the simplest and most feature-complete of these frameworks despite being smaller (both conceptually and on-the-wire). One of my only current gripes with Mithril is the lack of controllable subtree rendering (it isn't as much of a problem in practice, but more me wanting to optimize early). [0]: https://mithril.js.org https://mithril.js.org [1]: https://github.com/krausest/js-framework-benchmark https://github.com/krausest/js-framework-benchmark [2]: https://www.stefankrause.net/wp/?p=504 https://www.stefankrause.net/wp/?p=504 [3]: https://vadosware.io/post/mithril-systemjs-and-rollup-getting-started-guide/ https://vadosware.io/post/mithril-systemjs-and-rollup-gettin...
- 8y ago
fnordsensei 8y ago
There's also HDOM, part of the larger Umbrella collection of libraries: https://github.com/thi-ng/umbrella/tree/master/packages/hdom https://github.com/thi-ng/umbrella/tree/master/packages/hdom Purported benefits from the readme: - Use the full expressiveness of ES6 / TypeScript to define user interfaces - No enforced opinion about state handling, very flexible - Clean, functional component composition & reuse, optionally w/ lazy evaluation - No source pre-processing, transpiling or string interpolation - Less verbose than HTML / JSX, resulting in smaller file sizes - Supports arbitrary elements (incl. SVG), attributes and events in uniform, S-expression based syntax - Supports branch-local custom update behaviors & arbitrary (e.g. non-DOM) target data structures to which tree diffs are applied to - Component life cycle methods & behavior control attributes - Suitable for server-side rendering and then "hydrating" listeners and components with life cycle methods on the client side - Can use JSON for static components (or component templates) - Optional dynamic user context injection (an arbitrary object/value passed to all component functions embedded in the tree) - Default implementation supports CSS conversion from JS objects for style attribs (also see: @thi.ng/hiccup-css) - Auto-expansion of embedded values / types which implement the IToHiccup or IDeref interfaces (e.g. atoms, cursors, derived views, streams etc.) - Fast (see benchmark examples) - Only ~6.2KB gzipped
jayar95 8y ago
I think a lot of readablity issues with jsx are caused by the amount of logic react devs will put in their markup. It's painfully reminiscent of old-school PHP templating
itsbits 8y ago
lit-html surely does a good job.. - ES6 string literals - partial template rendering are few cool features with it.
- lauritzsh 8y ago
  I haven't looked much into lit-html but is it possible to type check your templates like you can do with JSX? That is one big advantage I found for JSX compared to template-based frameworks.
  - spankalee 8y ago
    It's possible. There's a VS Code extension that does this already called lit-plugin. If it becomes easier to add TypeScript compiler plugins via configuration, then I'm sure one will appear, allowing errors at build time.
  - Technetium_Hat 8y ago
    All components, expressions, etc are in template curlies `${}` so type checking works out of the box. If you mean type checking on HTML properties, no it does not. Lit HTML seems very extensible, so it should be possible to add support for thus.
- westbrookj 8y ago
  lit-html is great! - no build step - ergonomic - fast - flexible - useful whether alone or in a library/framework wrapper (see LitElement, https://lit-element.polymer-project.org/ https://lit-element.polymer-project.org/, Haunted, https://github.com/matthewp/haunted https://github.com/matthewp/haunted, et al.) Getting just about all the convenience of JSX with the ability to have your templates run in pure JS in the browser, with no build step is pretty rad. Even if the difference is just a few seconds here or there, multiply that by the amount of work I'm supposed to be getting done in a day, and it starts to add up. It's also nice to have control over whether to work with attributes or properties. A level of control that is mirrored by having direct access to event binding (rather than an abstraction of it) so you can pin down whatever custom events you might be passing around your application. Maybe that's my favorite part, you get control. Whether via the time you get back, the say you have over your templates, the interoperability of your code, you have it with lit-html in a way that JSX hasn't really allowed me to in my experiences with it.
batiste 8y ago
My problem with JSX is that if you introduce a DSL, why would you limit it to basic function calls/expressions? I created a small language to demonstrate what I mean https://github.com/batiste/blop-language https://github.com/batiste/blop-language
- com2kid 8y ago
  Easier to reason about. JSX is a simple wrapper around a JS call, it is trivial to mentally convert from JSX to what the real JS is. JSX is also super copy-pastable. Less logic and all that. If you want complex logic around what JSX to render, it get factored out into a function call (or its own component), which returns the appropriate JSX after evaluating any required logic. This means you are back to plain JS with all the existing tooling and language features around it. JSX being simple also makes the learning curve simple.
  - batiste 8y ago
    > JSX is a simple wrapper around a JS call, it is trivial to mentally convert from JSX to what the real JS is. Then maybe it is an indication is not worth very much. Why not using something like hyperscript instead if it is just some javascript. > JSX is also super copy-pastable. Less logic and all that. In my experience the copy-paste-reuse in FE is a red herring. And React is no exception. And a logic less templating is not necessarily helping with a flexible/reusable piece of code. > JSX being simple also makes the learning curve simple. Not so sure about that. I think I would have personally preferred not having to learn a new DSL if some basic function call in Javascript can do the same job. I guess I have been scared by colleagues using ugly ternary operator expressions with React. I also used so many template languages in the past: PHP, Django, Pug, Rails, etc, etc. That I try to reproduce similar features/mistakes.
SkyPuncher 8y ago
HTM actually looks pretty intriguing to me. One thing I like about JSX is that it looks and feels like HTML. For me, that has two huge benefits: 1. It narrows the dissonance between the code I'm writing and the actual structure that will be rendering into the DOM. I find it much easier to write and debug when I don't have translate between some JS factory function and the actual DOM implementation. 2. It's almost pure HTML. Sure I'll have to change class to className and update some other tags. Generally, though, if something works in HTML, it's little fuss to do in JSX. With tools like JSX, I can write in a single templating language across all of my software.
- wtfrmyinitials 8y ago
  One thing the author missed about htm is that you don’t necessarily need to parse it at runtime— there’s a Babel plug-in to compile it to plain js function calls. This way you can develop without a transpiler and add one later when (if) the extra performance becomes necessary.
nojvek 8y ago
We use virtual jade at work. It works with most virtual doms that use some form of h(name, attrs, children) calls. We have webpack hot reloading so we can work on UI without any page refreshes. It’s been very productive. I love the brevity of jade/pug. Jsx feels like a lot of boilerplate braces and ending tags. https://github.com/tdumitrescu/virtual-jade https://github.com/tdumitrescu/virtual-jade
- pjungwir 8y ago
  I've been using pug with the babel plugin for a React project, and I really like it. I'm a fan of Haml for server-side rendered Rails views, too. I'm surprised pug isn't more widely used in front-end dev, since it is so popular in Node apps. Also: projects are still using the "jade" name? I thought they were forced to change?
  - lf-non 8y ago
    pug is really nice (as is haml). The only reason I bear with the superfluous verbosity of JSX is because it plays well with typescript. The moment you switch to text based templates typesafety goes out of the window. I really wish javascript/typescript had a good builder syntax like Ruby. Hyperstack [1] (previously Hyperloop) is a great project that uses ruby blocks for component composition. I wish this was possible in javascript. [1] https://hyperstack.org/ https://hyperstack.org/
pier25 8y ago
The fact that front end has to deal with 3 different languages (JS + HTML + CSS) is a problem nobody has completely solved. These days the solution usually falls into 3 camps: 1) Write everything in JS like React.createElement or Mithril. No build setup but a pain to use. 2) JSX. Requires a build setup which might become complex as the project grows. 3) Templates. Probably the less elegant of all 3 but the most pragmatic and easy to use. Someone attempted to solve this and created a new language called Imba. It's like a mutant Ruby with HTML that compiles to JS. http://imba.io/ http://imba.io/ It has a lot of productivity benefits compared to previous attempts at solving the same problem, but goddammit it's ugly.
- sephoric 8y ago
  The project "create-react-app" is a good mixture of #2 and #3 that I have been using for almost a year with almost no issues, it's just a generally great way to use React. The only issue I had is that, even though all your configuration is "for free", you don't really get new features right when they come out. But you get them after their configuration has been polished up, so that you don't have to shave all the yaks yourself.
  - pier25 8y ago
    Personally I'd rather have my own configuration than use a CLI like create-react-app or Vue CLI. It's easy enough to create a template/starter kit the way you want it and tweak it to your taste. Also when (not if) you get a problem you know what's going on instead of a black box.
- kgwxd 8y ago
  ClojureScript along with any of the various libraries for generating JS, HTML and CSS can get you to a single syntax. Granted, you still have to understand all those things on some level with the addition of learning ClojureScript and it's ecosystem. For me, ClojureScript/Reagent [1] has been a dream come true. It marries JS, HTML and React very, very well. I still use normal CSS because I haven't hit a pain point with it yet, but there's some nice CSS tools that use EDN syntax and get rid of many CSS pain points. So far, I've only been able to use it for personal projects but they're not all small. I work with normal React at work on large projects and I've yet to run into anything I thought would be harder to do if were done with Reagent. [1] https://reagent-project.github.io/ https://reagent-project.github.io/
deleted 8y ago
[deleted]
droobles 8y ago
A point to the discussion of whether JSX is preferable or not to a programmer, most React projects with JSX I've worked on has had the awesome bonus of a designer who knows markup/css to be able to add layouts to our web and React Native projects. Just wanted to throw that out there as a plus to JSX. I don't think the designer could follow hyperscript very well.
bennypowers 8y ago
Why JSXBelPack when you can import { html, render } from 'https://unpkg.com/lit-html'; const benefitTpl = ({name, desc}) => html` <dt>${name}</dt> <dd>${desc}</dd> `; render(html` <lit-rocks> <dl>${benefits.map(benefitTpl)}</dl> </lit-rocks>`, document.body) And updates are fast without any VDOM overhead.
- westbrookj 8y ago
  Yes, this! Also, don't forget your `?module` at the end of your unpkg link to get that running
- zemptime 8y ago
  I'm popping in here to say, I've had people from both Vue and React join my team where we're using lit-html. Transitions have been seamless, mental models map over quite well.
- hyperpress 8y ago
  There's so much less cruft and overhead with lit-html, and you get speed that's akin to vanilla JavaScript. As for JSX, I think we can all get used to something non-standard, which after enough time feels normal, but the benefits of a lit-html are so immediately apparent. The transition is super easy.
- tracker1 8y ago
  Is this doing a full re-render on each change? Having not seen the state management piece... but could be nice for progressive enhancement modules in a server-rendered app. I've done similar in JS.
  - zemptime 8y ago
    Nope! It doesn't visit each node like vdom. VDOM visits every virtual node. lit-html looks at only the expressions. That's where a lot of the speed/performance comes from
  - spankalee 8y ago
    zeptime's correct. lit-html places markers in the HTML where the expressions are. Then it renders the HTML once, and updates the expressions directly. That's how it avoids a full re-render and avoids building am in-memory VDOM and doing any diffing.
fromalex 8y ago
There is also a babel-transform for pug[1]. It works quite well as JSX replacement. Not having any endig tags can be quite beneficial when reformatting stuff. Paired with Tachyons (best atomic CSS lib) you get superpowers and can write code like const someComponent = () => pug` ul.p2.f3 Some list li.red Some text li.pink Some more` [1] https://github.com/pugjs/babel-plugin-transform-react-pug https://github.com/pugjs/babel-plugin-transform-react-pug
oldboyFX 8y ago
I was a bit apprehensive about JSX before quickly getting used to it. Now I love it. The only decision I dislike is renaming class to className. Why not klass, cls, cs... anything shorter. ClassName is simple to understand but adds a lot of clutter to component files.
- acemarke 8y ago
  Because it matches the field name for DOM nodes: https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

Alternatives to JSX

104 points by bloomca 8y ago

austincheney 8y ago

I am getting a 404.

masklinn 8y ago
Works for me.

hn_throwaway_99 8y ago

Wow, after reading this, I'd be surprised if anyone could come away with the conclusion "Yeah, that's better than JSX." I think the general distaste for JMX is that it "feels" backwards initially: it mixes in HTML snippets within code, while many people are used to template files, which are mainly markup with small bits of "presentational" code injected. But once you realize and really understand that JSX is just shorthand for javascript calls (and the article does a good job of explaining this), you hopefully eventually reach an "Aha!" moment of thinking of JSX in terms of underlying component creation. That's what happened to me, anyway,.

masklinn 8y ago
> Wow, after reading this, I'd be surprised if anyone could come away with the conclusion "Yeah, that's better than JSX." IDK, hyperscript (or even just aliased createElement) is enjoyable, not that verbose, and not needing a compilation pipeline just for JSX is nice. As in, I want to drop in an interactive bit inside a wider static page, dropping in react's JS (or linking in a CDN copy) and using createElement is way more convenient than having to set up a compilation pipeline.
- tracker1 8y ago
  I'm using webpack/babel and ES6 syntax anyway, so the transpile doesn't bug me. It's also very close to E4X which I really wanted for a very long time, but never gained acceptance outside of ActionScript 3 (Adobe) and Mozilla. VB.Net also has a similar literal syntax).
brylie 8y ago
That makes sense, it's like an HTML-esque DSL in JavaScript. I'm learning Vue recently, and it seems that Vue templates are also rendered in a JS function. This is perhaps similar to JSX, but the semantics seem closer to HTML. Are there other frontend component libraries that embrace web standard HTML and CSS, and in particular Web Components?
- jgalentine007 8y ago
  Yep, with Vue single file components you can paste in your plain HTML (and css/sass) and it will just work without having to be properly formatted XML, as long as there is a single root.
mateuszf 8y ago
Yeah, usually the initial dislike to JSX is because of bad, past experiences of people mixing view code with domain logic, storage, often SQL. But once people realize that React handles only view - some XML in there makes a lot of sense, since HTML/XML is core object in the view domain.
jsf01 8y ago
The author doesn’t do justice to hyperscript. Hyperscript’s one-to-one mapping with CSS selectors is great for readability while remaining terse. For example: let value = ‘example’; let x = Math.random(); h(‘form.Foo[action=/whatever]’, h(‘input.Bar[type=text]’, { value, oninput(event) { value = event.target.value; } }), h(‘button.button-small.button-primary[type=submit]’, (x > 0.5) ? h(‘strong’, ‘Submit’) : h(‘em’, Submit) ) ) vs. let value = ‘example’; let x = Math.random(); <form className=“Foo” action=“/whatever”> <input className=“Bar” type=“text” placeholder={} value={value} onInput={ (e) => value = e.target.value } /> <button className=“button-small button-primary” type=“submit”> { (x > 0.5) ? <strong>Submit</strong> : <em>Submit</em> } </button> </form> Although the example is contrived, it highlights several of my pain points from when I used react/jsx. The equivalent jsx requires transpilation, dipping back into js via {}, is far more verbose, and is particularly annoying when logic inevitably becomes part of your template. Whereas hyperscript style js solutions to view templating have straightforward access to loops, array methods, ternaries, objects, functions, etc. jsx requires you to either reinvent js functionality as components or switch back and forth between contexts to use js in your jsx template. Hyperscript also nicely separates static vs dynamic properties in elements, making understanding a large code base easier. All the static stuff is in the selector, all dynamic stuff is in the optional second argument. There’s no equivalent in jsx. As an aside, React’s hyperscript is kind of a pain to write on its own and there are many good reasons to stick with jsx if you’re using React. (Last I checked, React was strict about the second argument being an options object or null and the third argument being specifically an array of children.) My arguments in favor of hyperscript are most applicable if you’re using a library that was intended to be used with hyperscript, like Mithril or snabbdom.
- hombre_fatal 8y ago
  One nice thing about JSX is the tooling/linting available for it. For example, tooling with warn when you have target=_blank without rel=noopener or whether you've defined the necessary attributes for each tag. It's one thing that got me using JSX years ago regardless of how I felt about JSX. Does the same level of tooling exists for hyperscript seeing that it's so much more string-based?
duopixel 8y ago
I don't think anybody would argue that the alternatives are better than JSX (if it were, why use JSX at all?), the step that you want to avoid is transpiling jsx. Why? Javascript's tool chain is complex, once you're using jsx you probable want `react-create-app` too, and things begin cascading from there. It's only worth it if what you're doing has a certain degree of complexity.
awirth 8y ago
When I was first introduced to JSX I found it very confusing because it was sold to me as "HTML in Javascript" but it's... really not. In particular these things threw me off: - You need to close tags you wouldn't need to close in HTML (breaks copy+pasted HTML) - Argument quoting isn't optional (breaks copy+pasted HTML) - HTML style Comments aren't allowed (breaks copy+pasted HTML) - Whitespace gets stripped for all elements (breaks PREs) - There's a JSX-specific syntax for "fragments" that seem to only exist for parser reasons? - Variable references work inside of text nodes but don't inside of attributes. After I googled a bunch and read the spec it helped a bit, but it left a bit of a bad taste in my mouth. I'm still left scratching my head over why you should be able to use an element as the value for an attribute though, like this: <foo a=<bar> test </bar>/>
- wereHamster 8y ago
  Elements as values of attributes are extremely useful in custom components. <FancyArticle heading={<h1>...</h1>} body={<main>...</main>} />
  - sametmax 8y ago
    Other systems address that by providing a <template>, # include or {% block %} element that allow you to state where/what things should be inserted. I dislike the attribute way because: - attributes are used for everything. It seems nice and simple - one single way to do all things ! - but it means when you see something passed this way, you never know what it's for without diving into the code or doc. There is no convention. Is it data ? Is it a children ? Is it a callback ? If yes, what for ? - it allows people to make big inline blobs of code. And as often, when something ugly is easy on the short run, and the clean things is hard, they do the easy thing. JS is full of those stuff, and I wish we would not add new ones in the tooling we use. - The syntax is so unatural when you have been doing HTML for decades. I understand the desire not to be limited by legacy, but here it's not working around any limit. There are alternatives. So we just break habits to break habits. Again something quite common in modern JS: let's replace the wheel by a different one. Not better. Just different. Because, reasons. - It's easy to get wrong. Case in point, your comment and the parent don't even have the same syntax because one of you couldn't, from the top of the head, come up with the proper one.
arkh 8y ago
So JSX is like pure php templates.
- bryanrasmussen 8y ago
  I remember reading somewhere that React was first written because someone wanted something similar to PHP workflow, but I don't see it, probably because I've only had a 1 month experience with PHP one time.
  - arkh 8y ago
    You can mix php and html. A minimal php hello world would just be "Hello World" in a file. I expect a templating engine equivalent to php's twig becoming the standard way to separate the views from the behavior soon enough.
    - krapp 8y ago
      There is a javascript fork of Twig that I used to play around with[0] but it's far from "standard." [0]https://github.com/twigjs/twig.js https://github.com/twigjs/twig.js
  - e1g 8y ago
    Indeed, JSX can be traced back to Facebook's idea of XML syntax on top of PHP called XHP [1][2]. It was never adopted by the community and did not break out of FB's custom PHP runtime called HHVM. [1] https://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919/ [2] https://docs.hhvm.com/hack/XHP/introduction
  - krapp 8y ago
    Hack actually supported it directly with XHP, which was great. Native support for extensible XML and data escaping out of the box is something PHP should have done as soon as was feasible, but unfortunately the best PHP can still do is string concatenation. Even Twig, which is basically an entire DSL with its own lexer, parser and everything, eventually just mashes strings together. I really wish XHP had been on the list of features PHP7 had taken from Hack and that it was default. Of course you can compile it in as a plugin, but that doesn't help the majority of PHP users nor does it encourage developers.
jasonkester 8y ago
You’re right that none of these alternative ways of writing JSX syntax are better than JSX. But I think you miss why people don’t like JSX in the first place; Having to compile your javascript sucks. If your framework requires me to have a build system in place just to write some javascript, I’m either not going to use it or, if forced, I’ll find whatever way I need to to get the code written without having to stand up a giant build system. Naturally, the true solution for people like me is to use Vue or Angular or another library that’s not as intrusive as React. But sometimes we’re forced, so we use that terrible createElement syntax. And come away disliking React even more.
- chosenbreed37 8y ago
  Having to set up a build system is a bit of a pain. The value I get from being able to break down the UI in components and with the possibility of testing them independently makes it worthwhile for me.
  - markmark 8y ago
    I think people might just work on projects smaller than I'm used to. I set up a build on day one of a project and then just it for the next six months or year or whatever, so I really never see it as a pain point. As you say, well worth it for all of the benefits. Although frankly if I was doing lots of small projects I'm sure I'd have one of the many starter projects set up how I like it and it would just be running a script once.
- dave7 8y ago
  Setting up a build system is not required, React with JSX can be inlined using plain old <script> tags just fine I believe. <head> <script src="https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react-dom.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/babel-core/5.8.23/browser.js"></script> </head> <body> <div id="app"></div> <script type="text/babel"> // React with JSX goes here </script> </body> It it is less performant than compiled setup, of course.
genezeta 8y ago
I've always thought the "HTML in JS" was in fact a strawman argument set up to deviate the attention from the fact that it is indeed a different syntax for function calls (and class instantiation). And it is actually that the thing that I dislike about JSX. I think it's a bad syntax for function calls/class instantiation. I do like hyperscript better than JSX... precisely because it's not a syntax for function calls. Because it's just a function.
- TomMarius 8y ago
  It's not just that. The abstraction placed between a Node and an Element is very important and crucial for React (and for a good reason, this is similar to a well-known programming paradigm used for 3D games). I'd say there is a significant semantic difference that can be simulated by a function call (you can simulate nearly any statement).
- abritinthebay 8y ago
  It doesn’t have to be function calls though. Conceptually it’s a nested model, that’s it. It could quite easily be a series of nested objects. The point is not that it abstracts functions it’s that it abstracts nested nodes. Anything else is a library implementation detail.
- scriptkiddy 8y ago
  > I do like hyperscript better than JSX... precisely because it's not a syntax for function calls. Because it's just a function. You should check out Elm: https://elm-lang.org/ https://elm-lang.org/. It uses a hyperscript like syntax for rendering in a functional style. It's all just functions, and it reads that way too.
- WorldMaker 8y ago
  It's not entirely a strawman, because there are legitimate concerns about separation of concerns that the "HTML in JS" argument worries about. Especially in the web world which still knows the legacy against fights of business logic in templates going back to "bad old PHP days", etc. There are good reasons to be skeptical about JSX simply because of the worry about how much business logic may accidentally be embedded directly into views. For JSX, the answer is typically to solve that in other areas of workflow and patterns of habit. But the war between "as dumb as possible a templating language" and "just let me use my real language for templates" will probably wage on in the web space forever.
sametmax 8y ago
If you dislike JS in the first place, having it also into your presentation layer isn't seen as an advantage. Plus, many people consider the presentation like something that should be limited and stay that way. Having a turing complete language in it defeat that purpose. But I agree, the alternative presented in the article don't address those issues at all so I can't see advantages over JSX.
- hn_throwaway_99 8y ago
  If you dislike JS in the first place, you're probably not going to be doing much with React to begin with.
bwindels 8y ago
I hope/suspect transpilation will not be a given any more in the future. In that scenario, it's good to have alternatives to JSX.

mmmeff 8y ago

Awesome article. I appreciate the lack of bias. Thanks for writing this, OP. It's good to keep an eye on the horizon for potential alternatives to tech we use day in day out, but it looks like we're still on solid ground with JSX so no need to switch :)

ertucetin 8y ago

ClojureScript + Reagent

schpaencoder 8y ago
I was thinking the same thing. Hiccup is a much better way to represent jsx than jsx.
mateuszf 8y ago
The only one which is better than JSX imo.
kgwxd 8y ago
This combo is insanely beautiful. Not only does it solve the JSX issue, it does it without any new syntax and adds persistent, immutable data structures, something React is just begging for. My only problem is that I'd have to switch jobs for any chance of using it at work.

cdaringe 8y ago

Pug is a worthy mention. https://github.com/pugjs/babel-plugin-transform-react-pug/blob/master/README.md https://github.com/pugjs/babel-plugin-transform-react-pug/bl... wasn't mentioned

oorza 8y ago

There's also kotlin-react which let's you write React in Kotlin in a Kotlin DSL which looks exactly like your first imagination probably suggests: https://github.com/JetBrains/kotlin-wrappers/tree/master/kotlin-react https://github.com/JetBrains/kotlin-wrappers/tree/master/kot... It's also a pretty impressive demonstration of the typesafe flexibility of Kotlin's DSL support, but that's another conversation.

dazhbog 8y ago

I used to be really sceptical about JSX, 1 extra transp. step, anorthodox use of xml in JS, etc. Having been using it for the past 3-4 years I think its an above agerage elegant solution when it comes to templating solutions.

cygned 8y ago

What really bugs me about JSX is the complexity it introduces to the build pipeline - which might be fine for senior developers, but I regularly see junior developers struggle with configuration and errors.

jayar95 8y ago
To be fair, I see junior devs struggle with all build tools.
- davnicwil 8y ago
  This is true, and further to this point, I don't think there is or should be any crossover between 'junior' and 'configuring build pipelines'. To me that's by definition a task for a senior Engineer. Put another way, if you have a skillset that includes configuring and/or maintaining non-trivial build pipelines, you're not a junior Engineer any more.
  - WorldMaker 8y ago
    Which is why as a Senior Engineer, some of the best productivity you can build for your team is to be able tell a Junior when starting a new application, "clone this template, npm start to debug it, it uses Typescript, you'll learn it as you work with it I promise, just let me know when you need help with something complex, and I'll be here to help you through all your PRs". (Or F5 to start in something like Visual Studio, depending on familiarity levels of Juniors you are trying to work with.) Junior developers are often just fine trusting build systems as block boxes once you've got them setup for them.
nicoburns 8y ago
You get a ton of other benefits from buying into a webpack-style build system though: - Modules - TypeScript - Newer JavaScript syntax - SASS compilation - Code splitting etc. For me, it's hard to imagine a medium/large sized JS project without using some kind of module system. And once you've setup the build system for that, you might as well use all of the other features that it enables.

keymone 8y ago

i'm surprised hiccup was never mentioned. ofc it's not for pure JS but there's this thing - https://github.com/lantiga/react.hiccup https://github.com/lantiga/react.hiccup though i never tried and don't know how well it works. still interesting.

simongray 8y ago
Hiccup is awesome for ClojureScript since we get to use plain Clojure data structures rather than a DSL that must be parsed in a separate step, but I think this advantage disappears when using it outside the context of Clojure/ClojureScript.

macco 8y ago

I would advice against using JSX alternatives. I come from a Clojure background and I like the ijk solution to just use an array to represent the virtual dom. But still I would recommend using JSX because it the "standard". Every documentation and problem solution you find on the internet is written with JSX. Using a JSX alternative will make debugging much harder for you.

deleted 8y ago

[deleted]

hardwaresofton 8y ago

If you read this article and thought Hyperscript might be something you wanted to try, please check out Mithril[0]. It's an excellent project, pretty decently fast (checkout the js-framework-benchmark[1] code, or more specifically the results of round 8[2]) -- but is currently suffering from a lack of recognition. It's the kind of project that absolutely doesn't care about that kind of metric (as in, the team seems to be more focused on slow, steady improvement of the library rather than chasing stars on github), but I figured I should say something. Shameless plug: I recently really wanted to contribute something (and kick the tires more) so I wrote an article that goes through replicating a simple mail design I saw[3] -- it might be a decent overview of what mithril is like to write (though I'm certainly not a mithril expert). This brings me back to the point at hand -- as others have noted, in my opinion one of the best things about hyperscript is the straight-forwardness with which you construct the render function. I'm not convinced it's necessary to segregate stateless/stateful components -- and mithril is simpler in that it doesn't introduce this dichotomy -- in the end there's the render function, and that's it. If you want to use state, go ahead -- if you don't, then don't. It's the simplicity I've wanted from component frameworks (and mostly get with Vue) without any of the posturing/looming complexity. Also there's the fact that you could write a completely vanilla es5 application with hyperscript (arguments whether you should or not aside) -- JSX is/was revolutionary, but is basically required in practice, which often makes people jump into bed with webpack without thinking, and makes frontend development harder than it has to be. [EDIT] - Another point for mithril is that it's self contained -- routing and ajax calls some with the framework. When people these days talk about "react" or "vue" what they're really talking about is react/vue + react-router/vue-router + flux/vuex and some other odds and ends. Mithril is by far the simplest and most feature-complete of these frameworks despite being smaller (both conceptually and on-the-wire). One of my only current gripes with Mithril is the lack of controllable subtree rendering (it isn't as much of a problem in practice, but more me wanting to optimize early). [0]: https://mithril.js.org https://mithril.js.org [1]: https://github.com/krausest/js-framework-benchmark https://github.com/krausest/js-framework-benchmark [2]: https://www.stefankrause.net/wp/?p=504 https://www.stefankrause.net/wp/?p=504 [3]: https://vadosware.io/post/mithril-systemjs-and-rollup-getting-started-guide/ https://vadosware.io/post/mithril-systemjs-and-rollup-gettin...

8y ago

fnordsensei 8y ago

There's also HDOM, part of the larger Umbrella collection of libraries: https://github.com/thi-ng/umbrella/tree/master/packages/hdom https://github.com/thi-ng/umbrella/tree/master/packages/hdom Purported benefits from the readme: - Use the full expressiveness of ES6 / TypeScript to define user interfaces - No enforced opinion about state handling, very flexible - Clean, functional component composition & reuse, optionally w/ lazy evaluation - No source pre-processing, transpiling or string interpolation - Less verbose than HTML / JSX, resulting in smaller file sizes - Supports arbitrary elements (incl. SVG), attributes and events in uniform, S-expression based syntax - Supports branch-local custom update behaviors & arbitrary (e.g. non-DOM) target data structures to which tree diffs are applied to - Component life cycle methods & behavior control attributes - Suitable for server-side rendering and then "hydrating" listeners and components with life cycle methods on the client side - Can use JSON for static components (or component templates) - Optional dynamic user context injection (an arbitrary object/value passed to all component functions embedded in the tree) - Default implementation supports CSS conversion from JS objects for style attribs (also see: @thi.ng/hiccup-css) - Auto-expansion of embedded values / types which implement the IToHiccup or IDeref interfaces (e.g. atoms, cursors, derived views, streams etc.) - Fast (see benchmark examples) - Only ~6.2KB gzipped

jayar95 8y ago

I think a lot of readablity issues with jsx are caused by the amount of logic react devs will put in their markup. It's painfully reminiscent of old-school PHP templating

itsbits 8y ago

lit-html surely does a good job.. - ES6 string literals - partial template rendering are few cool features with it.

lauritzsh 8y ago
I haven't looked much into lit-html but is it possible to type check your templates like you can do with JSX? That is one big advantage I found for JSX compared to template-based frameworks.
- spankalee 8y ago
  It's possible. There's a VS Code extension that does this already called lit-plugin. If it becomes easier to add TypeScript compiler plugins via configuration, then I'm sure one will appear, allowing errors at build time.
- Technetium_Hat 8y ago
  All components, expressions, etc are in template curlies `${}` so type checking works out of the box. If you mean type checking on HTML properties, no it does not. Lit HTML seems very extensible, so it should be possible to add support for thus.
westbrookj 8y ago
lit-html is great! - no build step - ergonomic - fast - flexible - useful whether alone or in a library/framework wrapper (see LitElement, https://lit-element.polymer-project.org/ https://lit-element.polymer-project.org/, Haunted, https://github.com/matthewp/haunted https://github.com/matthewp/haunted, et al.) Getting just about all the convenience of JSX with the ability to have your templates run in pure JS in the browser, with no build step is pretty rad. Even if the difference is just a few seconds here or there, multiply that by the amount of work I'm supposed to be getting done in a day, and it starts to add up. It's also nice to have control over whether to work with attributes or properties. A level of control that is mirrored by having direct access to event binding (rather than an abstraction of it) so you can pin down whatever custom events you might be passing around your application. Maybe that's my favorite part, you get control. Whether via the time you get back, the say you have over your templates, the interoperability of your code, you have it with lit-html in a way that JSX hasn't really allowed me to in my experiences with it.

batiste 8y ago

My problem with JSX is that if you introduce a DSL, why would you limit it to basic function calls/expressions? I created a small language to demonstrate what I mean https://github.com/batiste/blop-language https://github.com/batiste/blop-language

com2kid 8y ago
Easier to reason about. JSX is a simple wrapper around a JS call, it is trivial to mentally convert from JSX to what the real JS is. JSX is also super copy-pastable. Less logic and all that. If you want complex logic around what JSX to render, it get factored out into a function call (or its own component), which returns the appropriate JSX after evaluating any required logic. This means you are back to plain JS with all the existing tooling and language features around it. JSX being simple also makes the learning curve simple.
- batiste 8y ago
  > JSX is a simple wrapper around a JS call, it is trivial to mentally convert from JSX to what the real JS is. Then maybe it is an indication is not worth very much. Why not using something like hyperscript instead if it is just some javascript. > JSX is also super copy-pastable. Less logic and all that. In my experience the copy-paste-reuse in FE is a red herring. And React is no exception. And a logic less templating is not necessarily helping with a flexible/reusable piece of code. > JSX being simple also makes the learning curve simple. Not so sure about that. I think I would have personally preferred not having to learn a new DSL if some basic function call in Javascript can do the same job. I guess I have been scared by colleagues using ugly ternary operator expressions with React. I also used so many template languages in the past: PHP, Django, Pug, Rails, etc, etc. That I try to reproduce similar features/mistakes.

SkyPuncher 8y ago

HTM actually looks pretty intriguing to me. One thing I like about JSX is that it looks and feels like HTML. For me, that has two huge benefits: 1. It narrows the dissonance between the code I'm writing and the actual structure that will be rendering into the DOM. I find it much easier to write and debug when I don't have translate between some JS factory function and the actual DOM implementation. 2. It's almost pure HTML. Sure I'll have to change class to className and update some other tags. Generally, though, if something works in HTML, it's little fuss to do in JSX. With tools like JSX, I can write in a single templating language across all of my software.

wtfrmyinitials 8y ago
One thing the author missed about htm is that you don’t necessarily need to parse it at runtime— there’s a Babel plug-in to compile it to plain js function calls. This way you can develop without a transpiler and add one later when (if) the extra performance becomes necessary.

nojvek 8y ago

We use virtual jade at work. It works with most virtual doms that use some form of h(name, attrs, children) calls. We have webpack hot reloading so we can work on UI without any page refreshes. It’s been very productive. I love the brevity of jade/pug. Jsx feels like a lot of boilerplate braces and ending tags. https://github.com/tdumitrescu/virtual-jade https://github.com/tdumitrescu/virtual-jade

pjungwir 8y ago
I've been using pug with the babel plugin for a React project, and I really like it. I'm a fan of Haml for server-side rendered Rails views, too. I'm surprised pug isn't more widely used in front-end dev, since it is so popular in Node apps. Also: projects are still using the "jade" name? I thought they were forced to change?
- lf-non 8y ago
  pug is really nice (as is haml). The only reason I bear with the superfluous verbosity of JSX is because it plays well with typescript. The moment you switch to text based templates typesafety goes out of the window. I really wish javascript/typescript had a good builder syntax like Ruby. Hyperstack [1] (previously Hyperloop) is a great project that uses ruby blocks for component composition. I wish this was possible in javascript. [1] https://hyperstack.org/ https://hyperstack.org/

pier25 8y ago

The fact that front end has to deal with 3 different languages (JS + HTML + CSS) is a problem nobody has completely solved. These days the solution usually falls into 3 camps: 1) Write everything in JS like React.createElement or Mithril. No build setup but a pain to use. 2) JSX. Requires a build setup which might become complex as the project grows. 3) Templates. Probably the less elegant of all 3 but the most pragmatic and easy to use. Someone attempted to solve this and created a new language called Imba. It's like a mutant Ruby with HTML that compiles to JS. http://imba.io/ http://imba.io/ It has a lot of productivity benefits compared to previous attempts at solving the same problem, but goddammit it's ugly.

sephoric 8y ago
The project "create-react-app" is a good mixture of #2 and #3 that I have been using for almost a year with almost no issues, it's just a generally great way to use React. The only issue I had is that, even though all your configuration is "for free", you don't really get new features right when they come out. But you get them after their configuration has been polished up, so that you don't have to shave all the yaks yourself.
- pier25 8y ago
  Personally I'd rather have my own configuration than use a CLI like create-react-app or Vue CLI. It's easy enough to create a template/starter kit the way you want it and tweak it to your taste. Also when (not if) you get a problem you know what's going on instead of a black box.
kgwxd 8y ago
ClojureScript along with any of the various libraries for generating JS, HTML and CSS can get you to a single syntax. Granted, you still have to understand all those things on some level with the addition of learning ClojureScript and it's ecosystem. For me, ClojureScript/Reagent [1] has been a dream come true. It marries JS, HTML and React very, very well. I still use normal CSS because I haven't hit a pain point with it yet, but there's some nice CSS tools that use EDN syntax and get rid of many CSS pain points. So far, I've only been able to use it for personal projects but they're not all small. I work with normal React at work on large projects and I've yet to run into anything I thought would be harder to do if were done with Reagent. [1] https://reagent-project.github.io/ https://reagent-project.github.io/

deleted 8y ago

[deleted]

droobles 8y ago

A point to the discussion of whether JSX is preferable or not to a programmer, most React projects with JSX I've worked on has had the awesome bonus of a designer who knows markup/css to be able to add layouts to our web and React Native projects. Just wanted to throw that out there as a plus to JSX. I don't think the designer could follow hyperscript very well.

bennypowers 8y ago

Why JSXBelPack when you can import { html, render } from 'https://unpkg.com/lit-html'; const benefitTpl = ({name, desc}) => html` <dt>${name}</dt> <dd>${desc}</dd> `; render(html` <lit-rocks> <dl>${benefits.map(benefitTpl)}</dl> </lit-rocks>`, document.body) And updates are fast without any VDOM overhead.

westbrookj 8y ago
Yes, this! Also, don't forget your `?module` at the end of your unpkg link to get that running
zemptime 8y ago
I'm popping in here to say, I've had people from both Vue and React join my team where we're using lit-html. Transitions have been seamless, mental models map over quite well.
hyperpress 8y ago
There's so much less cruft and overhead with lit-html, and you get speed that's akin to vanilla JavaScript. As for JSX, I think we can all get used to something non-standard, which after enough time feels normal, but the benefits of a lit-html are so immediately apparent. The transition is super easy.
tracker1 8y ago
Is this doing a full re-render on each change? Having not seen the state management piece... but could be nice for progressive enhancement modules in a server-rendered app. I've done similar in JS.
- zemptime 8y ago
  Nope! It doesn't visit each node like vdom. VDOM visits every virtual node. lit-html looks at only the expressions. That's where a lot of the speed/performance comes from
- spankalee 8y ago
  zeptime's correct. lit-html places markers in the HTML where the expressions are. Then it renders the HTML once, and updates the expressions directly. That's how it avoids a full re-render and avoids building am in-memory VDOM and doing any diffing.

fromalex 8y ago

There is also a babel-transform for pug[1]. It works quite well as JSX replacement. Not having any endig tags can be quite beneficial when reformatting stuff. Paired with Tachyons (best atomic CSS lib) you get superpowers and can write code like const someComponent = () => pug` ul.p2.f3 Some list li.red Some text li.pink Some more` [1] https://github.com/pugjs/babel-plugin-transform-react-pug https://github.com/pugjs/babel-plugin-transform-react-pug

oldboyFX 8y ago

I was a bit apprehensive about JSX before quickly getting used to it. Now I love it. The only decision I dislike is renaming class to className. Why not klass, cls, cs... anything shorter. ClassName is simple to understand but adds a lot of clutter to component files.

acemarke 8y ago
Because it matches the field name for DOM nodes: https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...