Pandastrike Blog

Follow up post by Original Author from a few months ago: https://www.pandastrike.com/posts/20160331-facebook-react-party-gone-w…

> The original purpose of open sourcing Go was different for Google (make the language more robust/better) I'm not so sure about that. I like the 'baseball cap' argument more. The quote is about React, but it may be relevant for Go as well > Facebook doesn't care if you use the Web, it only cares that you use Facebook. > So why release an open source Web framework at all? Because Facebook is battling Google for engineers. So you've got a big fight between two companies over which company is the coolest place to work, and both of them are companies that your grandparents love. How are you going to win this fight? One way is to have the hippest Web framework. > Basically, both Google and Facebook are desperate to find a baseball cap that they can put on backwards. Angular is Google's baseball cap. React is Facebook's. https://www.pandastrike.com/posts/20150311-react-bad-idea

I have been learning new technologies pretty much continuously. It's not impossible, especially if you follow sites like Hacker News, to keep a finger on the direction of the industry, and then try to stay on top of the next new hot technology of the year. But I hear you on the "worse" technology sometimes winning. You mentioned Java; it was worse than just about all other major contenders, and is only finally losing popularity. On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices. [1] Separation of concerns? Who needs that any more? And the rationale for it is that it allows teams of 100 developers work together on an app. Open standards? Nah, how about lock-in to custom language extensions that will prevent you from migrating your code to the next web standard! Much better. And how many app teams have 100 or more active developers? Probably fewer than a dozen, and I submit that none of them probably should. Certainly not the Facebook app: It has a lot of features, but not that many features, and yet it has a 150Mb footprint. When I hear things like that, I can't help but fill in "junior" or "mediocre" in front of "developers." React helps to prevent people from breaking each others' code when you have bloated development teams filled with junior developers. React has some cool ideas, but all told I think it's a step backward for software engineering, and certainly isn't as much of a help for small teams,…

I am hesitant to spend time learning on react because of this: " SomeCallMeTim: I have been learning new technologies pretty much continuously. It's not impossible, especially if you follow sites like Hacker News, to keep a finger on the direction of the industry, and then try to stay on top of the next new hot technology of the year. But I hear you on the "worse" technology sometimes winning. You mentioned Java; it was worse than just about all other major contenders, and is only finally losing popularity. On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices. [1] Separation of concerns? Who needs that any more? And the rationale for it is that it allows teams of 100 developers work together on an app. Open standards? Nah, how about lock-in to custom language extensions that will prevent you from migrating your code to the next web standard! Much better. And how many app teams have 100 or more active developers? Probably fewer than a dozen, and I submit that none of them probably should. Certainly not the Facebook app: It has a lot of features, but not that many features, and yet it has a 150Mb footprint. When I hear things like that, I can't help but fill in "junior" or "mediocre" in front of "developers." React helps to prevent people from breaking each others' code when you have bloated development teams filled with junior developers. React has some cool ideas, but all told I think it's a step backward for…

I think it's only fair that the original repo should be the most promoted one. Usually, the original author has put a lot of thought and effort into coming up with the idea and turning it into a popular open source project. OP brings up the example of a project where the original repo shouldn't be the most promoted one, because it's been abandoned, while plenty of other repos are still alive. I blogged about the same thing earlier this month and used the same example. if you haven't encountered this problem, you will. it is absolutely a problem every developer will encounter. it's only a matter of time. somebody starts a great project, doesn't have time to keep it alive, and the community fractures because GitHub has no way to differentiate between "original repo" and "canonical repo." not going to rant about this because I already did in a blog post: https://www.pandastrike.com/posts/20150610-thought-experiment-github-c… If an 'owner' no longer feels up to the task of managing their project, GitHub lets them transfer it to someone else. That's what happened with ExpressJS and it worked out fine. this is a ludicrous statement. the Express.js transfer of ownership was a ridiculous fiasco full of angry drama, hurt feelings, and core developers resigning from the project. documented here: http://gilesbowkett.blogspot.com/2014/07/the-bizarre-bazaar-who-owns-e… also, the idea that you can solve this problem by having the original owner…

I like this blogpost on the subject: https://www.pandastrike.com/posts/20150622-remote-assess-dev-productiv…

There's been some comparisons in the past. http://logz.io/blog/fluentd-logstash/ https://www.pandastrike.com/posts/20150807-fluentd-vs-logstash http://jasonwilder.com/blog/2013/11/19/fluentd-vs-logstash/

While I agree that it would have been nice had he given examples of why React is bad and/or Web Components are better, I don't see anywhere in the post where he suggests React is bad simply because its developed by a for-profit corporation. His argument in that respect is that Facebook has a financial incentive to strengthen their walled garden and, to that end, they promote a custom implementation over web standards. And that is bad for everyone. There is a more recent post (https://www.pandastrike.com/posts/20160331-facebook-react-party-gone-w… - thanks to @suyash for pointing that out!) that clarifies this point and even offers some counter-points to the argument. It doesn't touch on the technical merits of Web Components over React which I would like to see but I have to agree with their overall feeling on the matter.

We're not religious about REST. For example, see: https://www.pandastrike.com/posts/20151215-http-rest-great-better-deve… and https://www.pandastrike.com/posts/20160210-rest-is-the-wrong-way-to-un… We've also tried to be specific in how you might approach addressing the limitations of HTTP in a way more consistent with the design of the protocol: https://www.pandastrike.com/posts/20151022-rest-data-api and https://www.pandastrike.com/posts/20160509-http-is-the-new-lisp In fact, our thesis in this article is not about REST at all, but the design goals of projects like Falcor, which may be unrealistic. And it's those unrealistic expectations of what's possible are why people are turning from HTTP.