Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
JavaScript Fatigue Reply

In reply to @ericclemmons:
Article context:


Thanks for hitting me up with clarification.

My message was not intended as an attack on you or your post. Articles titled like yours have a tendency to take a life of their own. The bulk of my reaction was to the title itself and the resulting conversation.

I agree with you that there is a lot of pain building React apps today; I disagree that this is representative of building JavaScript apps today. I agree that React components demonstrate a lot of exploration; I disagree that this is a problem that needs to be solved right now—"let a thousand flowers bloom." I agree that application-level abstractions could help newcomers to a project; I disagree that this will be just one framework that serves all React apps.

I don't agree that a pluggable system will provide a significant reduction in "fatigue" and that we're more likely to see a variety of opinionated, single-purpose solutions spring up to support the wide array of applications that React can be used for. I also disagree that any significant sampling of React apps would reveal a 90% similarity of anything.

JavaScript is very close to the user and all close-to-the-user-abstractions hard-won. I don't think we're in a place to assume that arbitrary high-level abstractions would provide meaningful "fatigue insulation" from the exploration happening in low-level components. I think the distance would only continue to grow until apps built this way would require a major re-write.

I want nicer things as much as anyone. But I think we're still identifying that 90% and we won't solve the fatigue problem until we've found it.




This comment has been minimized.

Copy link

@ericclemmons ericclemmons commented Dec 29, 2015


Thanks for the thoughtful response is an, admittedly, much better medium :)

I'm thrilled that we agree on so much. (I figured we did, as we're very much an active part of the same community and working so hard together to push it forward.)

Feel free to ping me next time you'd like to chat things out. The echo-chamber is too real :(

The tl;dr of the post is that I'm not advocating a one-size-fits-all, but redirecting efforts that are currently producing yet-another-boilerplate instead into experimenting with abstractions that solve extremely popular scenarios, as seen in @erirkas's popular (by my standards at least) project:

Hope to see you at a conference sometime & catch-up IRL!

  • Eric

(I had a much longer response written up, but it's better saved for over drinks)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment