[16bytes]

This is very interesting to see since I value Netflix's opinion. What's been holding me back was the pervasive JSX design. I know the react guys say that JSX is optional, but react without JSX seems cumbersome compared to, say, ember with handlebars.

It'd be interesting to hear from Netflix on the topic of JSX if they are going to grow their react codebase.

That being said, isomorphic javascript and using the vdom are really attractive and if react starts to lead those fields, then it becomes much harder to ignore.

[serve_yay]

If you think React seems interesting but JSX is a turn-off (or in my team's case a total non-starter), you might want to check out Ractive, http://www.ractivejs.org/ .

It uses some of the same ideas like a virtual DOM. Here's a writeup by Ractive's developer where he compares it to React: http://blog.ractivejs.org/posts/whats-the-difference-between...

[mercer]

I've been using Ractive + Reflux for two decently-sized projects and I'm very happy with it. I'll probably make the jump to React for most future project because of developer mind-share and a bunch of other smaller reasons, but I can definitely recommend Ractive.

[cnp]

Curious why JSX is a total non-starter? I've always been intrigued by things that completely invalidate ideas, regardless of how good those ideas appear to be.

Is it just aesthetic (xml like)? Is it the precompiler? What is the harm with trying it out?

[serve_yay]

Boy, people never want to accept this. On my team, designers write the HTML. They own markup & styling.

Designers don't want to dig through JS files to change markup, but an even bigger problem is that it's only kinda-sorta markup. For example, if you want to set a class on an element in JSX, it's not class="", it's className="". Because class is a reserved word in JS. How many other little warts like that are there, and how are they supposed to remember stuff like that? It just wouldn't work without a lot of undue pain.

[cnp]

"How are they supposed to remember stuff like that?" Designers are never given enough credit. If they can handle all of the insanities of CSS (and various preprocessors), this will seem like cake.

Its just a single `render` method, generally living at the top or the bottom of a file; nothing complex.

Additionally, you stub out your static html markup first -- just like in a template -- and then you add interactivity. In an ideal world this always happens first.

It took our designer all of two minutes to learn the nuances of JSX -- className, that's it!

I would give it a shot, i'm sure they'll manage :)

[serve_yay]

No, I explicitly told them about this and they said it sounded like a nightmare. I have gotten responses like yours - that basically I don't think highly enough of designers. On the contrary, I don't think they should have to waste their time with such things just because the JSers want to do things a certain way.

A wrinkle I did not mention is that we are in the process of transitioning how we do views. The new stuff is Ractive, but the old stuff is another library whose templates are also straight HTML. So using JSX would not only incur the aforementioned problems but also "wait, this is JSX so I should use this attribute name, and this is HTML so I should use this one." It just sounds shitty to me. And to them.

The situation is not designers can't handle it, the situation is they shouldn't have to deal with that kind of crap.

[16bytes]

So, I want to use a pretty lightweight framework, but then I'm not writing javascript anymore? I have to compile it like coffeescript? But what if I'm already using coffeescript? What if I want to use typescript?

Now I have to introduce a build step when I'm developing, or do I just say compile it on the client? If I use the new nodejs tools for visual studio, how does it affect debugging? How does it affect completion and highlighting? Does it break node-inspector? Maybe my team uses a bunch of different IDEs and debugging methods, now I have to see which ones break?

For me, it's a non-starter b/c having a framework say, "oh we recommend you write in a different language" seems so completely backwards to me.

I also don't think their justification is very convincing. Basically they say, "markup and code belong together because we think they should and that's why you should use JSX." So basically, they want people to use something that's not javascript because of a design decision they like. Weird.

[cnp]

All of this is trivial with the Node.js build ecosystem of 2015 -- all of it!

[codexon]

I am fairly certain that Ractive templates are similar to JSX in terms of overhead.

If you don't like compiling JSX you can run it with the JSX client compiler at the cost of compiling it on every client.

Ractive templates are parsed in JS just like JSX, which is why you have ractive compilers like this

https://github.com/ractivejs/rv

[untog]

I think the difference the OP mentioned is that Ractive templates are mustache-formatted strings, and can be stored in external files. So you have a JS file and a template file, not the combination of both you find in React.

[serve_yay]

Yes, indeed. I actually tried for a bit to get React templates in their own files separate from the JS, and I just couldn't do it. I know the React team's reasoning for why it's this way, but I still think it should be something devs can do if they want.

[codexon]

I don't think 16bytes said anything about any of that. React also uses mustache syntax.

[dodyg]

+1 for Ractive.js. The library is small and focused. It is trivial to integrate it to your application.

[proksoup]

riotjs has a complete html based style also that is interesting in this same category I think.