Sad. I thought Meta did a lot of things right when it came to using engineers, especially compared to Google. If I had a choice between React (Facebook) and Kubernetes (Google) I would pick the former anyday.
Kubernetes has held back cluster technology for the last decade and prevented a better alternative for smaller companies or companies that can't piss away monopoly profits on unwieldy technology and process. It would have been much better had somebody tried to make an open source product based on IBM's old Parallel Sysplex but there gotta be patents in there (now expired though!)
As much as people like to complain, React has come out on top in a highly competitive market. I've looked at a lot of systems for building UI objects which look superficially similar like Microsoft's XAML and Oracle's FXML and React's system is by far the most simple and flexible... An example that shows you can apply the ideas in On Lisp to any language which has basic functional programming practices with just a tiny compiler tweak on top to make it fluent.
They aren't directly competitive (you wouldn't pick one or the other as product) but they are the premier open source projects of the two companies in terms of industry impact and they both reflect the engineering culture. (e.g. I am picking one as an exemplar for other software... like I want to make something like React instead of make something like Kube)
With just a little bit of hyperbole:
The culture of Google is that you hire "the best" developers (say top 0.1%) and hamstring them with process and cumbersome tools so that you need 10x as many of them as another company would need and pay them 3x market rates, but it is OK because (1) at the scale they work at they can amortize the cost over a large user base and (2) they make monopoly products. Google's systems are highly scalable, I grant that, but they have the first mover disadvantage that their foundations are first-generation and not based on experience and still slowing them down... but the market can't discipline them.
Facebook on the other hand, cares about internal DX, sees it a problem when developers are stuck with cumbersome processes, and greases the skids. They benefit from huge scale and monopoly profits but Zuck is keeping more in his pocket than he would be if he did things like Google.
The problem with React is that mediocre developers can use it to build big things that are too big for them to handle. The problem with Kubernetes is that above-average developers can use it to build small things they can't handle. And the scalability of Kube is more than almost all of the industry needs. That is, a system like what Hazelcast was before it became an analytics play could support clusters of 30 or so big nodes (two racks) and there are probably just a few 100 systems in the worlds that really need to get bigger than that.
> The culture of Google is that you hire "the best" developers (say top 0.1%) and hamstring them with process and cumbersome tools so that you need 10x as many of them as another company would need and pay them 3x market rates, but it is OK because (1) at the scale they work at they can amortize the cost over a large user base and (2) they make monopoly products.
This describes basically every FAANG / MANGA company. Or even past that, any company that hit it big with a cash cow and now needs to come up with something new to satisfy shareholders.
In Meta's case, they have 3B MAU, they absolutely hire from the same tier of developers, and (pre-layoffs/economic downturn) they throw 10x more of them than they need at a problem. They even outcomp Google. The number of employees is more because employee growth was an indicator for company growth and only once that became a liability against the stock price it stopped.
Meta is just a newer company than Google.
> Facebook on the other hand, cares about internal DX, sees it a problem when developers are stuck with cumbersome processes, and greases the skids.
I am married to a Meta engineer and have mentored folks that have gone to work there. This might be the case if you work for a product that drives their cash cow of ads, but if you are doing anything that doesn't fit within that narrow bucket ... let's just say our viewpoints diverge significantly.
> The problem with React is that mediocre developers can use it to build big things that are too big for them to handle. The problem with Kubernetes is that above-average developers can use it to build small things they can't handle. And the scalability of Kube is more than almost all of the industry needs.
The problem with the Chrysler 300 is that bad drivers run over people. What does that say about the engineering culture at Chrysler?
Look, I agree that most cloud stuff is overkill, but I have a hard time indicting Google's entire engineering culture over a project they released into the wild 12 years ago that just happens to not fit your use case and that theoretical "above-average" developers wouldn't be able to tell that.
I’m grateful David Grand for your wonderful masterclass strategy which has help me earn at least $10,000 weekly using his masterclass strategy and has also helped me recover all my lost money in binary options trading, i recommend his help to each traders whose point is to succeed and make good profits in binary options and also for those who wants to get back all their lost money and for those who are new in trading or have any issues in trading’s, you can contact him
on: Email: wizardhackersunion@gmail.com.
Your comparison is like comparing The Eagles to some little local rock band!
Rather than two competitive products I think React and Kube are both market dominant products that reveal the engineering culture, values and impact of the two organizations.
I can say that when I first started with React I thought it sucked and looked at Vue and Svelte and similar things. My take on all of them was that they made the internal frameworks I was using to build very complex RIAs in the 2005-2010 time frame look like something that fell off a UFO.
I first thought Vue reflected the way I thought about conventional "webby" applications particularly in terms of treating lists as a first-class object. I eventually learned with React how to draw absolutely anything, even whole 3-d worlds!
I guess what I'll say about Svelte is "if you make such a radical change in your framework did you really believe in it?" Early on I stuck to controlled forms in React because uncontrolled forms seemed structurally unstable (add one too many features and it all breaks) and then I discovered
which is easy and very high performing. What I really like about React is not so much the DX or UX but rather the way it uses functions to seemingly transform a language into something else in a conceptually simple way... And how it solves the problem of composing components written by different people and organizations to the extent that we've now got the terrible problem of managing an app that has 50 third party components and 5 CSS management frameworks.
But Kubernetes is solving a much messier and more complicated problem than React. There are numerous similar web frameworks to React in different languages that have been created as basically hobby projects.
Of course Kubernetes is going to be way less fun to use. The problem of managing servers and distributed applications at scale is inherently not fun once you get into the nitty gritty details.
Kubernetes has the basic flaw that it has more scalability than 99.99% of companies need and you could serve almost all the market with a system that supports shared data structures (like IBM's Sysplex) and is more opinionated. An architecture which is less scalable could serve almost all of the systems on the planet and would be easier to work with.
I'll grant that there is essential complexity there, but Kube was built by people who didn't have fear of accidental complexity so it has a lot of it. Look at the whole "YAML sucks" thing which is partially a YAML thing (coulda chose something different) and also a function of the system they are trying to configure with YAML.
Kubernetes' YAML problem stems from its CLI tooling, and yes it was an atrocious choice once templating came in and visited horrors like helm on us. Internally, the the k8s api speaks only JSON, and you can already stuff whatever json you like in a yaml file.
> I thought Meta did a lot of things right when it came to using engineers
How is using talented software engineers to track users and design addictive algorithms any good? React might be a nice side effect, but it's certainly not the first thing when I think of Meta.
Someone who would compare React to Kubernetes instead of React (Facebook) and Vue.js (Google) does not have enough domain knowledge to provide an informed opinion on this matter
Kubernetes is the industry standard cluster orchestrator for a reason - it's fantastic
My main complaint is that React doesn't handle highly dynamic situations. Think of how tools like photoshop or programming IDEs have tons of views and windows and property sheets and stuff and manage to update the right parts of the UI when things change. React on the other hand makes a structural link between the component tree and how state propagates.
Specifically I wrote a bunch of React components for making little biosignals applications that can (say) show two people's heartrate from bluetooth LE and show my breathing based on a strap i am wearing and another person's breathing based on a $20 radar from China.
I can pretty easily snap together the components and the system that feeds the state to the components by writing code. It works great, it's not that hard to do, it looks great.
But: I really wish I could make something where I could drag and drop display and data acquisition and processing components like LabView. Actually I know a lot about how to do the dynamic processing (Hint: read the Dragon book, not On Lisp) but React doesn't support dynamically assembled components... But I know Javascript systems can because I was writing them 2005-2010 back when browsers didn't have async and all the great affordances they offer now.
I'm not a fan of state management in React apps, and it took me a long time to come to peace with it. What I landed on that works with the system rather than against is useContext at the page level containing Jotai atoms that wrapper Immer-managed objects representing the page states that get passed through the component tree as props.
I built my own action framework that gives me the ability to use Jotai getters to read atom data, launch asynchronous javascript, and then write to atom data via Jotai setters without ever having to fuss with useEffect myself. Jotai just handles the messy state transition work. My components used to be a jumble of DOM event handler, business logic, and markup, and now the business logic is all extracted to the separate action components.
React makes it hard to test business logic in isolation, and I am hoping my action framework could do a better job of that.
I tried using Jotai, and thought it was a great way to manage state. In contrast, useContext seems like an overcomplication with less control over rendering from state updates.
Is your action framework open source? I'd be interested in taking a look at it.
useState for local state or useContext (+ useReducer if it's complicated) for shared state is the "built-in" way that should be good enough for most things.
Instagram runs on angular doesn't it? They make more money per user than the core FB product... You might want to revisit your criteria for your FAANG journey
Kubernetes has held back cluster technology for the last decade and prevented a better alternative for smaller companies or companies that can't piss away monopoly profits on unwieldy technology and process. It would have been much better had somebody tried to make an open source product based on IBM's old Parallel Sysplex but there gotta be patents in there (now expired though!)
As much as people like to complain, React has come out on top in a highly competitive market. I've looked at a lot of systems for building UI objects which look superficially similar like Microsoft's XAML and Oracle's FXML and React's system is by far the most simple and flexible... An example that shows you can apply the ideas in On Lisp to any language which has basic functional programming practices with just a tiny compiler tweak on top to make it fluent.