I’ll happily to eat my words when I see evidence otherwise, but it seems that so many peoples’ excitement about react is purely the fact that it’s well-marketed reactive frontend programming. For the rest of us who have seen this type of thing before (ember, blaze, whatever) it’s pretty unexciting in itself, and it has an ugly templating API reminiscent of PHP (a deference that comes as no surprise, because Facebook).
Sure we could use react, but why? I agree with the sentiments above, namely: we already have a markup language for the web. Until there’s a better option (I would argue emphatically that JSX does not fit this bill), let’s use it and not abuse it.
Does react really have some magic power that we’re all missing? If so, why not recreate that with the tools we have. It seems like we were having this discussion a year ago about angular. I don’t hear many people calling for angular to replace this or that now.
I was waiting for someone to drop the PHP argument and here it is. My initial reaction to react was exactly the same “HTML in JavaScript!? PHP!!”. But after using it for last couple of months I think I’m starting to get the hype. For me react delivers one simple problem which neither angular not blaze even tried to solve - make it easy to reason about state of your UI. Removal of data binding and forcing explicit set of UI state makes even the most complex components easy to understand, at least for me.
Finally, I can stop pretending that my UI has no logic - if, each and other helpers is not logic, right ?
Yea, I think spaghetti code/templates are a concern, which is one of the worries I have about spacebars as it advances, I mean, mustashe was the notion that logic-less templates provide a solution to that by only really interpolating templates, then it switch to a compromise with handlebars and helpers. And now I see the evolution of spacebars moving towards a fully featured templating language. It seems to be that JSX is a comprise between both.
If our problem with spacebars/blaze is state, let’s work on that. If we believe nested expressions within spacebars is a waste of precious mdg developer effort, let’s raise that concern. If we like react for whatever reason and believe it is whatever spacebar lacks, let’s discuss solving that specific problem within spacebars.
A year ago famous was the thing. Now it is react native and I’ve frankly yet to hear a single word about famous. The same with the uproar about not ditching stuff for angular and now with react.
We should all know better. We got so much work to do, so many apps to develop and maintain. It pays to keep a consistent, stable, backwards compatible tech stack and it sure does make one pay to jump on the every new thing having to change technical contexts and paradigms supporting and maintaining multiple apps developed with different hypes over the past few years, heck months!
I agree, how long ago did react even come out? I would wait for some of the hype to die down and see what it’s really all about before so to speak “jumping on the bandwagon”. Being an early adopter has its upsides and downsides, but it’s basically always just kinda risky
The experimental branch preserves the current Blaze API, but renders everything with React underneath. It was a hack week project so it’s not super robust, but at this moment it can render the simple-todo tutorial app (including accounts-ui) out of the box, without any code changes to the app itself.
Under the hood, every Blaze.Template is compiled into a React Component. You can customize the Component further by mixing in React-specific methods, or you can directly include raw React Components using the same template inclusion syntax.
Probably the biggest advantage of this approach is that we get the nice opt-in separation of development style. If you don’t like React, you can continue to write spacebars like nothing ever changed; if you like React, you can seamlessly include raw React components, or even just write the whole app with React.
Regarding “there should be only one obvious way to do it”: I honestly don’t think this rule applies to the web app view layer. This is because the view layer is a unique place where engineering and visual design intersects, and it naturally gives rise to drastically different preferences in terms of development styles.
JSX is also maybe the most problematic part of the entire React approach. It’s very React-centric (re: Facebook-centric), with its custom syntax/markup approach; and that leads to vendor lock-in.
Last time I jumped on such a bandwagon was with MSHTML in Trident/IE6. Sure, it turned out to be productive; but it also left me being tied to Microsoft for the next decade. I’m not sure I want to go down that path again, and compromise web standards for a vendor’s custom syntax. Particularly when that vendor is Facebook.
Which is why I bring up JSON as an alternative. JSX has to be custom installed, but JSON is already installed everywhere. As an XML inspired markup syntax, JSX is concerned with representing set-theory based groupings; but JSON can do just as well. So why not just use JSON?
tl;dr - I’m on board with pretty much everything that React offers, except for JSX; which I don’t think the React community has given a good enough defense/justification of.
edit: Also, it might be a bit premature to write off Famo.us just yet, as they’re releasing MixedMode today. People are (subconsciously?) bringing it up, in part, because the hype cycle around Famo.us is starting up again. Which I’m quite looking forward to, because MixedMode was the missing piece to make Famo.us and Meteor work pretty much seamlessly together.
JSX, as a matter of fact, is not React specific. It is simply a set of syntax extension to JS, and the specification on how the code should be transpiled. It is not a part of React - the Facebook JSX transformer is shipped separately, and Babel.js also supports transpiling JSX. Babel even supports customizing how JSX should be transpiled through config. In fact, there are other virtual-dom implementations that also support JSX, e.g. Mercury and Deku.
The value of JSX really lies in JS itself. Consider the simple example where you want to render the current index of a list item. Because SpaceBars didn’t provide such a construct previously, you are limited by the template DSL and have to wait until MDG implement it. In JSX it’s really just using the second argument in the map function. Also, you naturally get proper lexical scoping instead of nested data contexts.
I’m not arguing everyone should use JSX, but I do want to clarify the benefits it provides. JSX is more like syntax sugar for “programmatically composing a tree of nodes” rather than writing templates.
I like that it also gives you the same Virtual DOM abstraction. I’m not super familiar with the Blaze internals, but I think right now it matters what data is passed to the template for rerenders even if parts of the data is not displayed. When you use a Virtual DOM on the other side it is only relevant what is actually displayed. Correct me if I’m wrong.
Yea, this is part of what I’m calling attention to, JSX compiles to JS, much like spacebars does, but the JS API in React is first class, in Meteor not so much. For example have a look at generated templates under the Template global. I think it would be nice if we could write templates without needing spacebars, and I think there are a couple issues holding this style back (api design, a mix of namespaces - Spacebars.include/Spacebars.mustache, I think they should be normalized and it would be nice if it was a bit more elegant, but I do think it’s very close to being there)
The branch is still in experimental state, but when rendering the DBMonster demo (which Ember used to demo Glimmer), there was roughly 20~30% fps increase. It is slightly slower than native React because of the overhead, but slightly faster than native Blaze. Note this is only for massive re-renders; Blaze would be much faster for single property changes, but in those cases perf usually doesn’t matter that much.