What's wrong with React, and how MDG can fix it IMHO

core
1

Hello everybody,

I was in the process of writing a book on meteor, I was already 200 pages in, then MDG announced Blaze was going to be decommissioned.

It has been a frustrating news, but I’m ok with it. Blaze and tracker have a lot of problems, and better solutions might be at the horizon right now.

Anyhow I don’t think React is the solution, and I’m sure Facebook knows it too, and is already working on something better. Why do I say so?

At the beginning of IT history, in the '50s computer time was the most expensive resource. IT departments had a ratio of 1 calculator for every tens of engineers. Thus the goal was to make the code as efficient as possible, in order to help the machine be faster.

Since then the situation has changed to be the opposite. Now engineers are the most valuable resource. They are so scarce that Facebook instead of doing their codebase in C++, invested billions in creating HipHop, to be able to use the easier PHP language for their high performance needs. Google did the same with V8 (Javascript instead of C++).

In this scenario React sits in the middle. It is an early prototype of a future paradigm, so technical details are still very important. We need something that works before we can have something that’s easy, so the first version can be a bit rough.

Anyhow mixing HTML, CSS and Javascript in the same file is quite confusing, error prone and very verbose compared to Blaze or Jade. I know some people might disagree on this, but I want to ask them: what if there would be synthesis between thesis (Blaze) and antithesis (React), which would be a new grammar that encompasses both JS and HTML in a new, easier language, like what Jade or Mustache did with HTML and templating? I’m sure everybody would love it.

That’s where I think MDG should chime in, and create a product built on top of React, compatible with React, but much easier. It won’t be easy, it will take many iterations, but this way MDG can anticipate the market, and be sure to gain a big market share of developers time and love :smile:

I’ve also some management consideration on the choices MDG made, but I would like to hear other people opinion first.

Is there anything already moving in the direction of making React easier to use?

Remember science doesn’t become technological progress until it gains widespread use. Maxwell wrote some real nice poetry with his EM equations, but Marconi changed the world by inventing the Radio :smile:

9 Likes
2

With regards to Meteor (and Blaze specifically), how about Blaze React?

5 Likes
3

Can you point out some drawbacks of React except for mixing JS with HTML and CSS.

8 Likes
4

Did you check out Aurelia? … It seems they are heading where you are pointing ?

3 Likes
5

I don’t think React is hard at all? Can you maybe put some more words on this statement?

In regards to a singular new frontend language with more power, Elm is above and beyond anything I’ve seen anywhere else.

3 Likes
6

Respectfully, but fully, disagree. My code is cleaner & less error prone in react. If you’re writing a web app, you can keep CSS separate. If you’re writing for mobile, it doesn’t matter whether you use native, Cordova, Titanium, or React Native, you’re gonna combine these. The future is probably going to be web components (think Polymer), which also is following this pattern (but is IMO uglier than react). There’s nothing stopping react from adopting web components behind the scenes, so it’s pretty futureproof.

Now, just because everybody is doing it doesn’t make it right. But, the DOM is no longer static with a couple dynamic divs. Template languages work because they’re all just glorified string replacements, which work for simple things (if a A, else B) but things like a binary decision tree requires an easy-to-reason structure, which react enforces. Being forced to write clean code isn’t a bad thing! Sure, there’s a learning curve, but the right decision isn’t always the easiest :wink:

13 Likes
7

I highly doubt they’re working on a complete replacement. They have too much in infrastructure tooling and mindshare to drop it. I do think it’ll change a bit over the years. Currently they can hire someone and have them productive in the first day.

I’ve talked to some of the React devs and basically in time the Object Oriented interface will sunset and a more functional approach will be the norm, as the JS community adopts FP over OO. Stateless components are the first step. Stateful functions/modules are next. Here’s an example of a spike of what’s coming in the future:

// react stateful module

function handleClick(props, state, event) {
  if (event.button === 1) {
    return { count: 0 };
  }
  if (props.onClick) {
    props.onClick();
  }
  // state gets returned instead of using this.setState
  return { count: state ? state.count + 1 : 0 };
}

export function componentDidMount(props, state) {
  console.log('mounted');
}

export function render(props, state) {
  return (
    <div>
      Clicked {state.count} times
      <button onClick={this(handleClick)} style={{ width: props.width }} />
    </div>
  );
}

Replacing Redux functionality is something that I imagine is being experimented with too.


> Anyhow mixing HTML, CSS and Javascript in the same file is quite confusing, error prone and very verbose compared to Blaze or Jade. I know some people might disagree on this, but I want to ask them: what if there would be synthesis between thesis (Blaze) and antithesis (React), which would be a new grammar that encompasses both JS and HTML in a new, easier language, like what Jade or Mustache did with HTML and templating?

I agree with @mattkrick , i’ve found the opposite to be true. Having everything in one file increases cohesion.

Also you’re not mixing HTML with JS, you’re mixing JS with JS. JSX is just sugar that was originally meant for designers. React started out without it. The attributes that people complain about (like className) are the DOM API because it’s not HTML it’s the a representation of what the DOM should look like.

For example this is pure React and a JSX version, the JSX de-sugars to the first example:


// before
const MainView = React.createClass({
  render() {
    return (
      React.createElement("form",  formProps,
        React.createElement("input", {ref: "email", type: "email"}),
        React.createElement("input", {ref: "password", type: "password"}),
        React.createElement("input", {ref: "submit", type: "submit"}),
        React.createElement("div", {ref: "errMsg"}, this.state.loginErrMsg)
      )
    );
  }
});

// after
const MainView = React.createClass({
  render() {
    return (
      <form>
        <input ref="email" type="email" />
        <input ref="password" type="password" />
        <input ref="submit" type="submit" />
        <div ref="errMsg">
          {this.state.loginErrMsg}
        </div>
      </form>
    );
  }
});

> Is there anything already moving in the direction of making React easier to use?

I’m hoping React itself will make it easy to share data across components without flux/redux. I think this is the main rub with building apps that are not simple.

I think a lot of people dismiss React without taking a day or two to learn it. They judge it based on a simple todo app and miss the big picture on how it helps you structure code on a real app.

14 Likes
8

I think React could learn a lot from Elms model for HTML, which in my opinion feels more natural, especially if we want to be functional.

2 Likes
9

We’re also judging it on W3C standards, quality of the API, existing tooling infrastructures outside of Facebook, and different market needs.

React breaks color coding standards in editors; the ‘props’ and ‘mount’ verbiage sounds like brogrammer gutter slang, we can’t scan/reuse HTML templates in non-react pipelines, web components aren’t being exposed according to W3C standards, and while the static imports might be great for file load ordering, they’re brittle and horrible for discovery-based application design.

The BlazeReact package solves most of these issues.

4 Likes
10

What does that even mean? :smile:

2 Likes
11

Seriously…what does that even mean? Get your mind out of the gutter and stop bringing up syntaxes that have no bearing on if you should use something or not.

Babel does syntax highlighting for sublime


Atom:

WebStorm - JSX support built in

Web Components are not their flavor, and not the flavor of many popular UI frameworks:

I thought static imports were banned in strict mode for ES5? Not sure what that means.

BlazeReact may never be finished, as Tim Brandin is still questioning the upside of that project.

2 Likes
12

Thanks for the question, as replying to it forced me to better focus on what was the issue at hand.

I won’t bother you with the importance of separation of concerns, as many developers better than me already faced the question, but I will try to follow a more managerial outlook.

Right now you have some developers more experienced with front end (HTML/CSS), and some which works more with backend (JS, Databases, etc). The have different salaries, as this represents the fact that learning JS and backend stuff is an additional complexity.

When you mix JS and HTML you either need to drop the less experienced front end devs, or to teach them how to become front end devs.

Isn’t there a value in keeping things separated? This forum is filled with very very smart people, but not everyone is a full stack developer, and you are cutting out a large workforce by imposing this.

2 Likes
13

yeah, Aurelia and Elm are really interesting, but I was hoping to improve my Meteor skills before jumping on the next bandwagon. If you keep jumping, you learn nothing :stuck_out_tongue:, but aurelia now that is out is definitely worth checking.

Same thing for Elm, before I will learn any new language I want first to master the new features of JS.

14

As a Jade (and Coffeescript) user my plan is to use react-jade when 1.3 modules will work to have a Coffeescript file and a Jade file for my React client pages.

3 Likes
15

some very good points as usual :smile:

Facebook has done it before and I personally think it’s a good management practice to start over once the project has become too bloated.

Facebook totally dropped HipHop for HHVM, and did similar things with their API in the past. You can’t know everything at the beginning of a project, and when you gain said knowledge it seems faster to re-architect your project rather than force unplanned features in it.

I’m not speaking of breaking changes, but syntactic sugar like what mustache has been for HTML.

But don’t you think that respecting the separation of concerns principle would help many noobs developers to enter the world of Meteor and React?

True. I will try to master React, since so many people sponsor it. Then maybe I will refuse to use it, but I need to master it first.

1 Like
16


It means there are women in the audience; and that not everybody who uses Meteor thinks like a 20-something male programmer trying to emulate Mark Zukerburg.

Look, I’ve been programming for 30+ years, and have programmed in dozens of languages. Did IBM and Microsoft systems for a long time, so I’m familiar with what well designed APIs look like.

And the simple fact of the matter is that there’s been a marked decline of late of the quality and professionalism in the API design and language included in the examples of the broader Meteor community. ‘props’ is just one of the many terms creeping their way into the API that makes the platform sound like it was developed by a bunch of brogrammers. Fine. Whatever.

But there are some of us who don’t want that kind of slang in our APIs. Because we’re selling into ambulance dispatch centers, genome sequencing labs, emergency rooms, and intensive care units. Blaze has a squeaky clean API, and we have a right to hold other technologies up to its standard.

So when we ask the question ‘what can MDG do to make React better?’, one of the responses coming from the community is ‘clean it up and make it more professional’.

Facebook is not a shining example of professionalism, what with Zukerburg and his hoodies and his ‘move fast and break things’ mentality. That doesn’t fly in the healthcare or finance industries.

6 Likes
17

It’s pretty much already finished. It’s definitely usable for our purposes, and will be going into the Clinical Meteor track in all likelihood.

4 Likes
18

Perhaps. But only if the beginner has been told that using div in your JavaScript is a bad thing. When building a React Native app there are no qualms about using <View> and <Text> or inline styles because there isn’t dogma stating that Objective-C is kept out of the UI file. However, these are both the same thing if you swap View for div.

This ‘rule’ started when we had a giant HTML page, and it made sense then. Web components are the future for ‘building apps’ and a React component encapsulates everything it needs in one little component that are composed to make a big page (as opposed to one large page).

IMHO, we’re starting to build more ‘apps’ now a days and using patterns that desktop and mobile apps have been using for years makes more sense than trying to hold rules/practices made when building “HTML” webpages.

We’re doing things with HTML that it was never intended for, which is why we have so much pain when comparing it to building an iOS app for example.

If anything I think that having a beginner use React, Elm, etc… Will guide them to be a better developer by thinking about things in a functional and declarative way. Again, just an opinion. Blaze could have done this, but failed to push devs into building great apps that won’t crumble (like @awatson1978 apps, they’re a great example of Blaze done well. The other resources… Not so much).

True. I will try to master React, since so many people sponsor it. Then maybe I will refuse to use it, but I need to master it first.

Yeah, I think learning it and contrasting what makes it different than Backbone or Ember 1.x will be eye opening. I’ve heard lots of great things about https://reactforbeginners.com for those who want a fast one stop place to learn.

3 Likes
19

I thought about Aurelia as replacement of Blaze/React… but then again, I dont knot much about Aurelia and it seems more than just that…

20

I don’t think there’s anything wrong with props (as short for properties) or saying that a component can be ‘mounted’ in a view.

I don’t see how React is going to get any better by replacing terminology you find offensive.

Unlike you, I have less than 3 years of experience studying CS, but you’re not even talking about CS, but instead misinterpreting and applying your own sexist views…

I don’t want to read about your sexist attitude towards male programmers… I just want to learn about cool tech :smiley: plz

7 Likes