when will people learn - you're not Facebook, or will never likely reach facebook scale. Graphql, Relay, React were things etc made for Facebook at facebook scale i.e whether that's in terms of engineers, resources or actual tech problems.
There's plenty of other sites / services that receive almost as close to FB properties in terms of traffic yet you never hear them pushing all those tools. Trading firms, Porn firms etc. Some just use REST + JSON or RPC + JSON.
Wish us an industry would read Joel's Spolsky's Fire and Motion article: While you're fighting tools built by FB you're not making stuff for your customers.
Exaaaactly. I worked on big systems at a very large retailer, and at a very large bank, and in each case, there were reasons why GraphQL worked very well for us. But 90+% of developers across the world adopt tools and technologies because they look fun and shiny, not because they need it. For the overwhelming majority of developers (who in most cases are working at medium-to-large-sized companies on internally-facing apps with a small number of users) a simple web app stack from 2005 will serve you quite nicely.
I wonder if this phenomenon happens in other industries as well.
I can't imagine a road crew getting away with spending an extra year to build a road because they decided to use completely nonstandard equipment that doesn't work well for the task or they don't know how to operate. I especially can't imagine the road crew screwing up multiple jobs in a row because they change equipment every time they're starting to understand the current equipment.
Maybe it does happen though and I just haven't seen it since I'm not in that industry.
I don't know about construction, but as a farmer it's pretty natural to look at what your neighbours are doing and if they adopt a new technology in their operation you're at least going to give some thought to doing the same.
But I think it comes with a lot more reluctance and skepticism. You are not likely to jump in head over heels, and even when you do give it a try I expect most farmers will do so with the attitude of "if it doesn't work at least I can always go back to the old way".
The "OMG this is amazing and will solve all of my life's problems" attitude I see in tech certainly isn't there in my experience.
That’s the problem. In the days of jQuery/Angular2 (and even now personally), React was a blessing. Everyone hoped the same here. We should just join technology a little later on the hype cycle and have less stress.
React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason.
That was actually a very small parts of the projects in the world at the time, and in fact, a very small part of the number of projects that adopted react at the time.
I remember above all that:
- React was hyped to the roof by facebook. They had a fantastic marketing machinery for that.
- React sucked for years, with a terrible doc, a crippling webpack experience and breaking compact all the time.
- The JS community was moving from koolaid to koolaid, never assessing the new tech for their cost. They solely inflicted on the world slow and brittle preprocessors left and right, thousands of stuff you had to integrate manually because "libs > frameworks", and jumped on react, redux, graphql, docker, spa, microservices.
So I would say it was a loooot of hype for react, just like it was for graphql.
I'm going to feel like spamming at this point, but, remember when XML was the future?
> React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason.
performance was the least attractive reason for adopting React. React introduced composition as the default way of thinking about UIs to the web. You created components and used them to build more complex components. Data was immutable and flowed in one direction (parent component -> child component).
Comparing the above to ng with its dependency injection, MVC style approach to UIs, that used HTML based annotations and tags to sprinkle in functionality (`ng-if` baby) -- it was a much more simple way to build web applications.
React's style of building UIs has largely won. Vue, etc. all follow this component with composition view of the world.
> React sucked for years, with a terrible doc, a crippling webpack experience and breaking compact all the time.
Webpack has nothing to do with React. React has always had good documentation. The reason the documentation was good in the beginning was because the API surface area was tiny compared to Backbone, Ember, ng, etc..
I'm not going to go point by point here. You sound like you have a very superficial understanding of the space.
I'm going to hard pass on clicking a marketing link to your blog.
In fact, for years, react didn't even tell in the doc you could use it without a transpiler so people had to learn a whole build chain before even getting to the hello world.
At this stage it's not "superficial understanding of the space" this kind of comment is guilty of, it's total denial.
And by the way, we have been doing components for UI way before react was a thing. jQuery could do components. Backend frameworks could do components.
As for immutable data, I've seen more small projects die from the small cuts of trying to maintain that purity that I've seen those exploiting the benefits like free time travel.
I assume you've been living HN bubble for too long.
You know you can just check before making these claims. It helps with credibility.
> In fact, for years, react didn't even tell in the doc you could use it without a transpiler so people had to learn a whole build chain before even getting to the hello world.
React's original documentation site from June of 2013 (when React was first introduced):
> You'll notice that we used an XML-like syntax; we call it JSX. JSX is not required to use React, but it makes code more readable, and writing it feels like writing HTML. A simple transform is included with React that allows converting JSX into native JavaScript for browsers to digest.
XML was genuinely better than fix-width data formats (COBOL) or character-separated fields (CSV, HL7) for most APIs. Hierarchical deeply nested trees of data were the future. Everyone uses JSON or a more industrial format like protobuf/avro/BSON to represent such data now, but it wasn't necessarily wrong to point at XML and say it was an improvement.
The problem with XML is precisely that it is so much more than simple hierarchical, nested trees of data. The fact that in a casual conversation XML is reduced to hierarchical trees of data pretending the rest of XML does not exist more than proves OP's point.
I'm not pretending anything and I hate XML. I would still rather use it than HL7, because it's a hierarchical tree of data and HL7 is not. OP's point is that almost nobody wants to use XML anymore; my point is that almost nobody wants a Ford Model T as their daily driver anymore either, and yet it was still the future, in a certain sense.
XML is so much more than hierarchical data serialization format. In a typical conversation XML generally means "JSON-compatible subset of XML" as if the other parts do not even exist. Like in the meme "Javascript vs Javascript the good parts".
XML never really took off, only the parts that make up "different flavor of JSON".
I quite like FHIR. My experience with using it has been that everyone seems to implement it slightly differently, but it does a better job at being human-readable. It was much easier for us and our partners to work with than regular HL7.
Some things were a bit weird. From memory it had big lists of records all mixed together as the implementation of references.
> React sucked for years, with a terrible doc, a crippling webpack experience and breaking compact all the time.
Webpack wasn't how it started, remember gulp?
Also don't forget the switch from class components to functions, then inventing "hook" functions to reintroduce functionality that already existed in the class components.
For the past few years I've been on a team that handles a legacy system from long before React existed (internal) that just renders HTML directly, a client website that uses Backbone, and a newer client website that uses modern React. The old internal one that doesn't use any frontend frameworks has been by far the nicest to work with, and Backbone the worst.
I think that's some missing context as well - React+Redux was much better than what came immediately before it, for complex web apps. But when you're not building something like that, yeah, both are worse. It just doesn't seem like the Backbone era encouraged people to use it for everything, unlike React.
> React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason.
React solved a very specific issue that was a pain in Angular, which is making it easy to write small, self-contained components and attach them to a mostly static site. That people decided to use it to make entire SPAs further illustrates how much easier they found it than other solutions.
I can't think of a case where JQuery code is ever simpler than React code, even for small things. If you need to worry about the order of rendered items or moving them into different categories on a page based on input, it's much simpler in React.
I think an aggravating factor in the software world (that's maybe not as prevalent in other fields), is that developers tend to want to use the latest and newest technologies, even if said technology is not really appropriate for the task. It looks good on your resume to say that you used the same technology Facebook uses - the ol' "resume driven development".
You also usually need to actually try out a new technology to know if it’s going to help you. Less “must use the latest tech” and more “let’s see if this latest tech is helpful”. Of course, both happen.
There's plenty of other sites / services that receive almost as close to FB properties in terms of traffic yet you never hear them pushing all those tools. Trading firms, Porn firms etc. Some just use REST + JSON or RPC + JSON.
Wish us an industry would read Joel's Spolsky's Fire and Motion article: While you're fighting tools built by FB you're not making stuff for your customers.
Revenue / Profit >> Tech