feedjoelpie

>By the way, virtual-dom is a little bit early to use for production application. For example, if you have some elements in your vdom, that are changing after you render it (i.e. like buttons, embeded posts, etc.), virtual-dom will be totally confused and unpredictable.

On the one hand, yes, and on the other hand, I have never in practice had this happen when it was not my fault. I've also never had it be my fault unless I fell back on some old jQuery plugin or Google Maps or something that directly manipulates the DOM because I'm trying not to reinvent the wheel.

However, you can deal with these things gracefully by diligently recognizing these instances in which you, for one reason or another, need to directly manipulate the DOM. React's lifecycle methods like `componentDidMount`, `componentWillUpdate`, and `componentWillUnmount` are the place to deal with those kinds of issues.

It definitely takes you out of the React philosophy and forces you to manage your own state carefully. But that's generally confined to a single component, so if you get the component innards right, everything that calls it can be ignorant of the ugly stuff inside.

Unless you're talking about something else entirely that I've just been lucky to never encounter.

So, I get what you're saying, but the particular locations are completely irrelevant to the math/CS.

Idle curiosity because I've heard so little about it in the past year: Who out there is using Dart now?

Forgive me if I'm misunderstanding, but it sounds like you merely take offense. Perhaps the issue has been blurred through popular usage, but the "trigger warning" culture arose around social and environmental "triggers" that might cause someone to have a PTSD episode or to re-engage in self-destructive behavior (think eating disorders as a common case here).

And even so, if the point had been to halt discussion, there would be no such thing as "trigger warning" because the only reason to warn anyone is so that the discussion can still go forward, and people who feel the need can excuse themselves. How often we should promote discussion in which people feel the need to excuse themselves, however, is worth consideration.

When I see this quote in the article, “I was feeling bombarded by a lot of viewpoints that really go against my dearly and closely held beliefs,” I wince a bit too.

Offending and triggering are not the same thing. And although people within that political sphere are sometimes guilty of using the terms interchangeably, those who criticize that political sphere are often guilty of treating the entire thing as ridiculous. When in so many circumstances it's really not. I mean, you wouldn't dismiss the needs of a solider who had trouble around loud noises.

We just all need to be really careful about distinguishing between offensiveness (a matter of opinion) and triggering (a matter of involuntary mental state).

My bit of feedback would be that having the annotation dialog cover any part of the code at all is going to create a lot of frustration. Omniref's side-by-side approach is much easier to read.

The tragic comedy of the whole thing is that, while there's always some pork-slinging going on, at the outset of the program, the whole idea of a Joint Strike Fighter program was cost savings. On the surface, it was a competent economic thought: Build a bunch of variations on the same jet to achieve better overall economy across all military branches.

I really believe the people making that decision thought they would succeed. But since the premise proved incorrect, it looks like program continues to run entirely on a combination of addictions: Escalation of commitment and pork politics.

The author mentions "perverse" incentives in Congress, but what he doesn't mention (because it's a very politically difficult subject) is the perverse incentives afforded military officers. When you have a system in which it's so common as to be expected that the officers who influence your purchasing will in a couple years retire into a job with the private contractor from whom you're purchasing, you have a recipe for bias. Even from really standup people who don't recognize their own vulnerability to influence. It's just such a common thing to work in the private sector for the same office as you did when you were enlisted that nobody blinks an eye. Because it's often really good to still have those people around.

But at the same time, I think that's a pretty untenable situation. The military needs to do something to balance the career mobility of their officers with the ethical hazards of the current system. Without some rules to prevent the scenarios that have the most potential for abuse, the situation is not unlike the flow of Congress members into lobbying. Except we don't elect military officers.

It's a tough balance. Part of the promise of the military's recruiting is that you'll advance your career. They should fulfill that promise. At the same time, they need to make sure that the ways in which they fulfill that promise don't incentivize poor judgment on behalf of the public interest.

This is the article that made me understand the value in React and that it was more than a way to pollute your JavaScript with markup: http://jlongster.com/Removing-User-Interface-Complexity,-or-...

I hope it helps you as much as it did me.

I think the problem with Meteor was mainly that it started punching above its weight too soon. All these fancy demos and then you looked under the covers and it was... basically irresponsible from a security standpoint to ship anything that mattered on Meteor. I know that's been fixed now, but so many people like myself never gave it a second chance. And I wonder if it will ever really get that second chance or if something like it is what will get attention instead.

It's a cautionary tale about why you need to be very clear that your demo alpha isn't fit for general consumption yet. I think that, in the rush to get attention, the Meteor people didn't do a very good job of that. Therefore everyone who took a deep look thought they had uncovered a foul truth that Meteor wasn't what it was hyped to be. And they did. Because the people promoting it didn't talk about that.

Ditto. I don't think the CoffeeScript philosophy as it stands will ever have it keeping up with the pace of JavaScript proper at this point. Within the next year, I think our company will be migrating back to the land of curly braces. The charms of CoffeeScript just aren't worth missing out on all the great stuff coming to JavaScript as of late.

What if I told you that there are people who have to write those ORM adapters...

> I don't think of something as React-like just because it puts HTML and JS in the same file or combines HTML tags with blocks of JS code.

Totally agree. While I do (most of the time) appreciate JSX, it is IMO the least interesting and relevant feature of React. It mostly just lets our company's designers continue to edit view templates that would otherwise be far beyond their training/experience. So that's nice, but it's not what makes React tick.

So are you traversing the entire tree of children here? I'm familiar with cloneWithProps, but I've been wary about this technique because of how deep the components I actually want to bind could be and how much traversal it could take to find them.

I don't like PHP, and I do love Rails, but pretty much anything you compare to CakePHP is going to seem fantastic.

I think that the fact it has taken this long to even deprecate, let alone remove, utter garbage like these functions is a prime example of why PHP is often reviled.

It almost makes you wonder if the point isn't to keep catering to bad programmers' whims just to keep from losing the 50% of PHP's community that would never be able to write software at all if they weren't working in a language that enabled them to ignore every best practice from the past 20 years.

I kid, I kid. Mostly.

Because it's not fixed. We don't usually hire for a particular, specific level of talent/experience except in rare cases when we need to fill out a specific growth area. We just bring in people who seem interesting and then see if we can fit them somewhere.

Also, we're honestly pretty new at this. Our company's a little over two years old, and only in the past year have we gone from poaching people we already know and trust to interviewing people we've never met.

It's kind of an abstract problem to describe without code examples or without diving pretty deep into React, but let me see if I can just make something up without getting too far in the weeds. Imagine you're trying to make a ModelUpdateForm component that you can just drop in, which manages all its own state:

  var ProfileUpdateForm = React.createClass({
    render: function() {
      return <ModelUpdateForm model={@props.user}>
        // I don't actually have a reference to `form`.
        // I can't have a reference to `form`.
        // But I need to link state between the ModelUpdateForm and its inputs.
        // Anyway, this is never going to work.
        <ModelInput type="text" valueLink={form.modelValueLink("name")} />
      </ModelUpdateForm>;
    }
  });

Weird workaround that I'm not sure is an officially sanctioned way to deal with it and fear might break in future React versions or have unintended consequences:

  var ProfileUpdateForm = React.createClass({
    render: function() {
      return <ModelUpdateForm
        model={@props.user}
        do={function(form) {
          // Instead of taking children, ModelUpdateForm takes a `do` function prop.
          // It passes itself to `do` which give you a reference to which you can link its inputs.
          return <div>
            <ModelInput type="text" valueLink="form.modelValueLink("name")} />
          </div>;
        }}
      />;
    }
  });

Another idea I've been kicking around and haven't tried would be to create some sort of linker object. Here's the hypothetical end result:

  var ProfileUpdateForm = React.createClass({
    render: function() {
      var valueLinker = new ModelUpdateForm.ValueLinker()
      return <ModelUpdateForm model={@props.user} valueLinker={valueLinker}>
        <ModelInput type="text" valueLink={valueLinker.linkState("name")} />
      </ModelUpdateForm>;
    }
  });

tl;dr - The way React typically wants you to do things, ProfileUpdateForm would have to manage the state. But what I wanted to build was a reusable model-bound form component. If I have to write a lot of model-binding code every time I write a new form, then there's no point to trying to make a reusable component at all. So you start having to try weird-ish ways to get it to become feasible.

Mostly because the legacy of PHP as a toy project carried forward forever. Here's a great tidbit about why all the original functions have ridiculous, inconsistent naming schemes:

> "Well, there were other factors in play there. htmlspecialchars was a very early function. Back when PHP had less than 100 functions and the function hashing mechanism was strlen(). In order to get a nice hash distribution of function names across the various function name lengths names were picked specifically to make them fit into a specific length bucket. This was circa late 1994 when PHP was a tool just for my own personal use and I wasn't too worried about not being able to remember the few function names."

That's right: Every one of the original function names has a different character length because length was used as a lookup. There are a lot of clowny things like this that have never been stamped out of the language.

Add to that its history of being a beginner language that most of its early adopters sprinkled into HTML and where many people who mayyybe have no business being professional programmers started making a career out of it. This severely undermined PHP's credibility as a language for professionals even though good software can be created in PHP in the right hands.

That all said, I spent about year coding in Hack, and while the parts that still feel like PHP are annoying, it is awesome in so many other ways. Hopefully it either starts to unseat PHP or PHP turns into Hack at some point.

From the hirer side, maybe this is unreasonable given "No matter what, don't give them a number," but my past experiences on the other side of the table lead me to try and press a different dynamic. I try to get us and applicants talking salary during the first interview, before we even know if we fit each other at all.

The rationale is:

A) If how much money you want from us isn't even an option, we don't waste your time. We can be very up-front about that before a lengthy interview process proceeds.

B) We can judge your follow-up interview (generally a full-day paid tryout) against how much you expect to be paid. Which on the negative side lets us weed out expensive mediocrity, or on the positive side, give opportunities to people who aren't quite there yet but wouldn't cost much to take a chance on and try to train up.

A few people definitely look at it with suspicion, but in general I think it's worked out better for everyone.

Also, as an aside, I would take issue with what you said about researching what a company pays. For so many companies (mostly small ones), all you can do is ask around and find a current or former employee who is willing to tell you. And that is so often, for most applicants, not an opportunity you get. I think you're making that research sound much easier than it actually is.

Yes, yes, yes. At my company we've been switching everything over to React for both client/server rendering using our own ExecJS rendering engine for Ruby on Rails. It certainly adds a bunch of complexity to the stack, but every improvement we make provides new benefits in terms of the ease with which we can keep the API stack we like while cranking out rich UI while worrying much less about the client/server distinction.

Needless to say, I am a React fan.

That said, here are some things you will run into as you build more complex applications with this architecture. Some are related to shared browser/server JavaScript and some are React in general:

* You will find that some JavaScript libraries you want to use should not be loaded into the server context.

* On occasion, you will need to add server-vs-browser conditionals. And creating components to deal with browser-focused JS libraries (think Google Maps) will require some liberal and sometimes awkward use of React component lifecycle methods.

* Until there's a nice, agreed-upon open-source layering library for React out there, or you make your own, things like click-based (not hover-based, which can work with just CSS) dropdowns and non-modal dialogs are weirder to get to dismiss (when clicking outside of them) than they should be. Just because of the way React events happen and are bound.

* Also because of the way events are bound, it's awkward to write nice reusable form components. Without some trickery, you can only bind events from the component you're writing to its descendents. You can't bind events from one descendent to another. You end up writing a new component for each form every time, which isn't necessarily terrible until you want to make a fancy form builder like Rails provides in ERB. I've tried every which way around this, and I've had some success, but the solution always feels wrong and ugly no matter how I do it.

* This is really more of a good thing, but it's so enabling that you'll never really be done adding convenience features. There are just so many "Wouldn't it be nice if ____ just worked?" scenarios that get you thinking about the next reusable tool you want. I spend a LOT of time trying to create the "perfect" browser-side data store abstraction and the "perfect" lazy loader/renderer component for not-yet-fetched models.

The tradeoffs thus far have been worth it, but we haven't yet found or built the holy grail. So many things are so much easier than the old ways, but sometimes they're harder.

Though I still mostly disagree about the utility of a noscript-friendly web going forward into the future, that's at least something I'd consider a worthy debate. CSS2-only, on the other hand... No. Just no. That's completely indefensible, especially given that you're aiming for mobile-friendliness. In addition to all the other things CSS3 fixes, it's where media queries come from. CSS2-only would set everyone back to having to duplicate effort to add m.blah.com sites. Which would be awful. You might as well be advocating for the return of WAP as far as I'm concerned.

> browser with a very limited set of feature: limited to css 2, js deactivated by default

I think I speak for every web developer in the world when I say that I hate you, and I'm extremely happy that almost no one else wants to buy your dream product. :)

That's a really good one. And yes, I think we have all done that. :(

I don't disagree, but when you're growing and responsible for the economic livelihoods of several households, it's hard to write your anxieties off as first world. Because it's not really about you anymore, and a "whatever, I'll be fine in the end" attitude just feels, selfish? Irresponsible? I think a great many of us would sleep just fine if we only bore responsibility for ourselves. I'm not arguing that anyone should be destroying themselves over their startup, just that writing all the anxieties off as first world problems just isn't a reasonable ask for founders who care deeply about their teams.