"The simpler product makes it much easier to maintain and scale."
This is good news for the developers, the product owners and the customers.
I still can't understand why today people choose a (Javascript) stack of build systems, ton of dependencies, and all kinds of exotic tech that is the latest and most hyped. As a developer you need to support this in the future. It might be nice to build today but it will be a nightmare later.
I have seen days go to waste because of Docker misconfigurations, problems with dependency versions, outdated dependencies not available anymore, bugs deep down in an unknown dependencies, and so on. Personally I want to build systems. I don't want to spend my day debugging all kinds of weird problems.
The (old) WhatsApp teams sounds like a great workplace.
One is that the future is unknown. Your goal might be to keep the product simple and scale to 1bn users, but you don't really know if it will play out like this.
Maybe you plateau at 1m users with the initial idea and pivot the product somehow. Now the app does dating, social media or specialised communications for highway construction teams.
Tradeoffs are easier to make in hindsight. Whatsapp is a good demonstration of what you can gain with good trade offs. Do less but well. Whatsapp did trade some things off though. Their web version came late, is feature poor and a little clunky. Same for a lot of features, compared to similar apps ATT. IDK what exactly can be traced to the stack, but their decisions around user identity are similar. Phone numbers only. One device at a time. They gained simplicity, but lost options.
It's easy to see the benefits in hindsight. Real time is harder. Play that game again and it might turn out different. Most apps that set out to have 1bn never get close. At this point, scalability doesn't matter and tradeoffs made for maximum scalability don't seem as wise.
I think the Unix philosophy should apply here. The fact that WhatsApp did one thing well and it had a good business model (was it $1 per year?) is the important bit.
When you say, “Now the app does dating…” I think the right move is to scrap the project because that’s a colossal fuckup. Unless you have Microsoft cash to have multiple colossal fuckups in a row, don’t add another dating app to your messaging app. Ergo, less is more.
WhatsApp probably started with passion and a solid vision. The Zuckerberg gave them an offer they couldn’t refuse. Anyone will take 19 billion for a basket full of Indian users.
Another thing WhatsApp did well is they targeted ALL phones. They didn’t abandon their users like the fang-bangers (sorry been watching True Blood— FAANG is an annoying acronym so they are hereby fang-bangers).
>Another thing WhatsApp did well is they targeted ALL phones. They didn’t abandon their users like the fang-bangers (sorry been watching True Blood— FAANG is an annoying acronym so they are hereby fang-bangers).
That was clearly the killer "feature." Whatsapp is synonymous with communication on the developing world because of this. I remember when I was introduced to it fairly early on in Brazil and someone claiming that yeah, anyone no matter the OS could get on it. I couldn't believe it, to be honest, it felt like what iMessage was starting to look like... but for everyone? I can't imagine what it would've been like to support so many things, but clearly it was a lot of sweat that paid off extremely handsomely.
I'm not saying that philosophy is bad, just that reality is complicated.
"Scrap the project and move on" works in some contexts, not others. The way startups/products actually work, often, is evolutionary. If your texting idea didn't work, but you see a chance to pivot into something... are you really going to just fire everyone and tell investors "sorry?"
That said, the "one thing well" philosophy really does have big engineering advantages. You can't have everything. I'm just raising the "retrospectives" warning.
In any case, the "$1 per year" was never a real business model. They never even got around to actually charging it... because anything that limits the usership of a messaging app will sink it. It's the opposite of "support everything" strategy that made them successful.
Yeah I agree with the idea of pivoting. I suppose to clarify:
* Pivoting would leverage existing technology built in the process of initial concept. Which to me is the equivalent of scrapping the initial idea (while salvaging the generally-useful IP/technology).
* Adding a bunch of tangential features to a product to increase revenue is a colossal fuckup scenario (maybe the language is a bit over dramatic).
For instance, Google is great at search; gmail is cool; docs was innovative (albeit limited); and then… https://killedbygoogle.com/
Unfortunately, after seeing this time and time again it’s tough for me to get behind mainstream tech. I loved the old Microsoft/Nokia phones; and the Zune. You can tell a lot or love went into the design/engineering but then projects just get axed by corporate interests.
Meanwhile, you can by a mechanical device or appliance from 1950s and it’ll still work just fine.
Again, I don't disagree with you... just think reality makes it messy.
Pivoting via "scrap & salvage" is pretty tough for a startup. The tech behind whatsapp was evidently good, but the IP behind a messaging app is probably not enough to give you an edge. Users are.
Made up scenario: whatsapp loses the SMS replacement game. They have millions of users, but not a billion. Meanwhile, they find that a subset of users like to use whatsapp for dating (or customer support, etc. doesn't matter). They pivot to focus on those customers, and evolve into something else.
This might be a (drama noted) colossal fuckup scenario in an engineering sense. A tractor that you are now converting into a ship.
Evolving is definitely a worse way of engineering than starting with the intention of designing a ship, with neatly defined tonnage, speed and size requirements. Instead, it takes a miracle to implement basic ship features like floating.
Evolving is how a lot of actual software gets invented. Spreadsheets were intended for accountants. They weren't meant to be used as a database, incident report generators, a casual programming environment, or a HR tool. It became those things by evolving.
It happened that way because inventing UIs is hard, and evolving into them happened to work. It's still true that "colossal fuckup scenarios" arise because of this approach. Excel programmer spent decades making excel better at things it's architecture wasn't good at. It's ugly and messy, but life is sometimes ugly and messy.
Flexibility is valuable. Knowing the spec in advance is valuable. Very valuable. They're in conflict with each other to some extent
I think it was 79 euro cents for a lifetime at first (this thread brought back memories of my installing WhatsApp on my phone while I was asleep), then it became 89 euro cents per year (except for the users who had been grandfathered in), and then came the Facebook acquisition and they made it free for everyone.
Well, WhatsApp had to support exotic cases like BlackBerry, Symbian OS (Nokia), and Windows Phone. I will say, dealing with JS stacks, seems easy in comparison to mobile fragmentation from back then.
I don't see how this is related. Server-side you write and expose an API. Then you have 1-3 developers for each platform that write code that consumes that API. Those developers don't need to know anything about the internals of the server.
I wish that WhatsApp could make a public API. I'm very thankful that Facebook is integrating WhatsApp into their services, because that gives me hope that a true web interface will be developed.
For me, it takes between 10 hours (worst case) to 5 minutes (best case) to open WhatsApp.
My iPhone 4S is too old, so opening WhatsApp gives a message "This version of WhatsApp ha..., Update WhatsApp, Your update will be free of cha...". Clicking Update WhatsApp opens the App Store, and clicking Update results in another error message: "This application requires iOS 10.0 or later."
So I only use WhatsApp through BlueStacks Android emulator on my personal laptop. That's what leads to the 10 hour worst-case response time: a full working day, including commute. The 5 minute best-case is because BlueStacks takes a very long time to open, and runs my laptop fans really loud.
This is not only a pain point with WhatsApp, it's also a problem with WeChat, KakaoTalk, LINE, even 9gag (for posting videos).
Meanwhile, email continues to work just fine on my decade-old phone, mbasic.facebook.com is particularly speedy, iMessage still works, and Hacker News is great :)
Hey, if you do prefer that, I too have a broken phone, but the new multi-device beta let's you to have whatsapp in your computer with a powered-off phone. That works for me.
But this speaks to good architecture decisions, right?
If they tried to make a shared framework that ran the same codebase everywhere and then port it onto different platforms (cough facebook) then you don't get these nice isolated issues, for example.
Yes, if you don't write a native app for every platform the result will be rubbish. That's not a "good architecture decision", that is common sense. If they don't do it that way it's to save money, because as we all know Facebook is strapped for cash. (Talking about Facebook and Instagram here, because as far as I know WhatsApp is completely native on every platform)
This then also means a well defined server API without undocumented behaviour that individual implementations depend on. I stand by my assertion that the good scaling and separable builds is a sign of good architecture.
But this would be client side only, right? These issues would also only occur in the corresponding app repository, when building a separate native app for all platforms. The backend for all of these apps would be the same, not the frontend.
Sure. And so do I. Specifically, I don't want to rebuild systems that have already been built for me which I can use as dependencies. And I don't want to spend all my time troubleshooting bugs, either - I'll take a well-maintained repository on GitHub with thousands of users bug-testing it for me over some janky thing some guy on another team threw together a few quarters ago before he quit.
Simple isn't always better. Reusable patterns are. WhatsApp followed pretty standard erlang design patterns.
Rails and Django to some extent force a standard pattern, they're not really low dependency systems(although they are compared to most node projects). But that pattern to some extent makes sure that you can hand over the project to the next dev and he'll be able to make sense of it.
Somehow node.js has become what PHP used to be.
Whatever happened to interoperability? How are there hundreds of queuing system that use redis and rabbitmq under the hood, but you can only process things in python, javascript or ruby? The data structures are considered private.
So if you want to process your code in python you have to use the python message queue, if you want to process it in javascript you have to find a node mq. How does that make sense?
Want to do business intelligence on your javascript based system now? Gotta write javascript code. Welcome to debugging the same kind of memory leak and processing issues every other queuing system has had to go through.
I agree, but this assumes you actually know what you are building. This isn't usually the case for a startup.
I'm sure whatsapp wanted a million users, but they didn't originally know that would happen. If whatsapp later turned out to be about serving fewer users with more features, this becomes a story about premature optimization.
Do we really think Javascript is exotic? Hasn't it proved itself over many years now?
That doesn't mean it can't have issues like anything else. And because of the massive scale of the language you'll see a lot of shit. It's a language and ecosystem like anything else - it's what you do with it that matters.
I wouldn't say JavaScript is exotic, it's more to do with what is being done with it.
Traditionally it was used to enhance HTML pages with some DOM manipulation but it's now being used for a million other things too.
So historically, if your JavaScript code broke your page would still render as it was just html but now there are all sorts of build processes and long chains that use JavaScript to create the html in the first place... I'd consider that the exotic bit.
Traditional JS running in the browser manipulating DOM elements is very much a foundational aspect of the web and won't deteriorate with age (with the exception of perhaps deprecated functions in the far-off future) but all these js libraries and tools and build processes with massive dependency-chains are what's being referred to.
It's been used as a general purpose programming language for over a decade. It is a 'boring technology' nowadays and hardly exotic.
Of course, you could decide to do something exotic with it (edge rendering, data programming, whatever) but that's not a problem with the language but people wanting to stretch themselves...
JavaScript has matured massively over the past 10 years. I'm not a Node developer myself, but JS + TS is a very palatable combination to me. I'd pick it over many other languages.
10 years ago I would not have touched JS unless I was forced.
I'd be interested to know which ones, because I can't think of one advantage that Javascript has - aside from the ubiquity of browsers. If we're comparing any other aspect of it though, I just don't know what advantage it has (seriously).
Functions are first class. Async i/o by default. Familiar syntax (I'm sure Haskell or Clojure are better languages, but they sure take some time to get used to. You can be fairly productive in js in very little time). There are packages for anything you can think of, no need to reinvent the wheel most of the times.
And I even like it's single threaded nature. Being able to keep a process waiting without needing to spin a new thread with all that implies is very convenient.
Edit: Original commenter had already mentioned typescript.
So what's the deal with TS? I think on top of adding much needed type safety to Javascript, TS is also one of the best type systems you can ask for.
Firstly, thank you for answering. I think most people would be too defensive (devs are a touchy lot:) to bother or just dismiss my sincere question. I'm going to disagree though (quite gently, I hope:)
> Functions are first class.
Always a good thing to have in a language but I struggle to think of a language that doesn't have this now. Java has it, C#, Python… if a language is being developed and didn't have it then now it does, right? Perhaps C doesn't - I checked, functions may be passed as arguments but does not allw nested functions, but it has callbacks so a type of closure is possible… hard to tell. Still, I'd say not using C was an advantage!:)
> Async i/o by default
I'm not sure which languages this gives an advantage over?
> Familiar syntax
I don't think this is an advantage, most languages are much of a muchness, and there are some serious footguns that still lay around in JS. Is `==` familiar? No, that's a footgun. Automatic semicolon insertion (ASI) rules? No, they're another footgun. Are fat arrow operators familiar? Doubtful. The new backticks? They're the other way round to what I'm used to.
Certainly though, it can be picked up quickly enough.
> There are packages for anything you can think of
This is definitely an advantage over some newer languages, but over those in major use, it's not. Still, the way packages are installed and handled is… eye-opening. That wheel has been reinvented several times, and it still looks wonky.
> I even like it's single threaded nature
Sometimes that's a good thing, true, but it's not an advantage to have it set that way all the time.
> TS is also one of the best type systems you can ask for
I haven't used it, tbh, but I would say that an optional type system (it's optional in that you don't have to use TS, I don't know if it's optional once you start using TS, that would be better) is a definite advantage over some languages. It's not baked in though so that's half a point.
I just don't see it. I think the driving force of the move to Javascript everywhere was because devs were tired of learning at least three languages (JS, something, SQL) and not being very good in all three (usually poor at SQL) and thinking they'd get more control by kicking out the DB guy who'd stop their bad ideas (because they didn't know SQL) and they could become an expert in one language to rule them all. Companies love it because of fungibility and more new devs tend to start with Javascript than anything else.
Perhaps I've just got used to keeping several languages in my head?
> I think the driving force of the move to Javascript
> everywhere was because devs were tired of learning at
> least three languages [...] Companies love it because
> of fungibility [...]
>
> Perhaps I've just got used to keeping several languages in my head?
Another possibility that doesn't involve you being smarter than everybody in the room is that many people that were capable of learning several languages saw that the majority of companies wouldn't care for this and instead would prefer to hire for a fungible language. They specialised in this language and then used their free time to learn other skills so they could become more valuable in the marketplace.
You wrote a lot of words about how others were "tired of learning" and "not being very good" and "kicking out the DB guy who'd stop their bad ideas" and then finished it off by congratulating yourself on keeping several languages in your head. I can be rude but you should think about how this would be perceived by others.
No, you should try to keep your temper, you could’ve provided your objections without resorting to rudeness. As such, I feel that I’ll simply ignore your point of view.
Somehow I suspect this isn't the first time you've ignored other people's points of view and felt righteous about it. But, the way you act, must give the people around you a lot of entertainment so I'd certainly not want you to change!
Mate, there are published guidelines for the site. If you don't want to follow them, that is up to you. People aren't even supposed to be snarky but they are, sometimes I am - we're all human and can be a bit spiky at times - but outright rudeness isn't defensible. Of course I'm going to ignore you because of it.
> But, the way you act, must give the people around you a lot of entertainment so I'd certainly not want you to change!
I wanted to point out to you that there are other reasons for people choosing different choices to you which don't involve them being "tired of learning" and "not being very good".
You described yourself as being "used to keeping several languages in [your] head" as if this was an achievement that others couldn't muster.
I still feel that your derision towards others and self-congratulatory tone were deserving of rudeness and snark.
Anyway, I apologise for being rude since it was hurtful. I thought your comment was bad and let you know this by directly accusing you of exactly what you were doing, instead of finding some non-confrontational way of saying it.
Typescript has a pretty cool type system. A mixture of dynamic and static typing. You can be as dynamic as with js (or python), or stricter than Java (you can state a reference cannot be null for instance), or anything in between (and have dynamic parts and static parts in the same program).
I haven't used Typescript but I've generally heard very good things about it. I didn't know you can mix and match, that might give me a bit more of kick to include it in a project, thanks.
Whether or not it's an advantage of Javascript… I'm not sure. I mean, if someone wrote a transpiler for Java that overlayed stricter typing, would that really be an advantage of Java? Not sure, but of course, worth considering when choosing a language for a project.
> I still can't understand why today people choose a (Javascript) stack of build systems, ton of dependencies, and all kinds of exotic tech that is the latest and most hyped.
So the same cannot be said for "newer" languages like Rust, Go, and other's whose ecosystems and paradigms aren't completely fleshed out yet?
This comment reeks of someone who is looking from the outside in when it comes to building stuff in JS. Most comments I see criticizing JS stacks are so superficial and demeaning that's its obvious the commenters have little to no experience working in JS.
Why do you compare it to Rust though? JS is as old as Java, however its ecosystem seems to be much less mature (at least from outside). I haven't touched Java for 15 years, but I am fairly confident that people still use Apache Ant as build system. Every time I try to peak into JS world, it appears similar to tiktok trends in terms of how quickly people move from one thing to another.
It's even worse from the inside. The last 2 companies I have worked at have had significant amounts of JS code (even the majority of code) and it's inevitably became unmaintainable mess through a combination of lack of solid frameworks to instill structure and trying to apply it outside of its domain of the browser.
The last 3-5 years have convinced me that JS isn't appropriate outside of a browser almost ever. I am sure if you think hard enough you can think of cases where it's superior to some other lang but in general it's a very poor choice for almost anything that isn't DOM manipulation.
Worst was definitely attempting to diagnose an off-heap memory leak due to C extensions. Naturally the JS folk gave up and dumped the problem on my lap so I proceeded to do my usual "C guy" stuff and was amazed at just how bad stuff like node-gyp and friends are and just how fragile everything is. I found the leak and patched it and all was "ok" again but just peeking inside those layers makes you deeply uncomfortable with the runtime in production.
The rest of the problems can probably be attributed to lower quality developers but point remains. Things like lack of structure leading to insane architectures, pushing for microservices without understanding the tradeoffs because they didn't want to work on "legacy" JS code that was built with last years hipster tech rather than this years, etc.
These problems are endemic to to culture and ecosystem which IMO are inseparable from a language/tool in practice despite what we want to believe in theory.
I don't refuse to work with JS but I definitely make my concerns abundantly clear and I generally don't hold back with "I told you so" when it inevitably bites people in the ass.
> I am fairly confident that people still use Apache Ant as build system
As in: there are still (older) projects around that haven't (yet) migrated away from Ant? Sure.
As in: Ant is still the go-to build system or at least still commonly used? No, not at all. When I create a new Java project in IntelliJ for example, I can choose between Maven and Gradle as the build system. Ant isn't even offered as an option.
JS is as old as java, but they're both talking about the build process of JS.
in the beginning, JS wasn't really transcoded/compiled. The first time i personally found out about that was sometime after 2010 with coffeescript, not sure if there were preceeding examples.
and your claim that people move around is really false. React has been the defacto standard for a pretty long time at this point.
yes, other UI libraries/frameworks exist, but reacts marketshare has been extremely dominant since it displaced jquery/ember etc
Express isn't a framework though, maybe a "micro-framework". The nearest competitor to real frameworks like ASP.NET or Spring is Nest.js and it's definitely not got the same longevity as those stalwarts.
JavaScript is from 1996, it's 25 years old, and apps built with it are used by billions. With regards to the backend, it has a vibrant full stack ecosystem, it's performant, simple, and easy to hire talent for.
It's okay not to enjoy JavaScript (I'd always prefer to go with Dart or Rust myself), it's okay thinking that other languages (and ecosystems) are better equipped to solve some problems, but calling it unproven and exotic is very surprising to me.
Is the implication that FreeBSD is less mature now, intended? I'm assuming not. The BSDs have grown in popularity significantly in the last couple years.
No, but there are signs of distress, IMO. I think their decline in usage has resulted in a decline in port maintainers, which is a bigger deal now that systemd is the default on Linux for so many things.
In the 32 bit days it wasn’t hard to get most Linux binaries to run, now it’s virtually impossible for an end user to do on their own.
Pretty much nothing important depends on systemd, for the simple reason that it’s proprietary and non-portable. Thus, even if there is some code that depends on it, it’s optional.
Also, Linux binary compatibility - the capability to run unmodified Linux binaries - works much better now than ever before.
Seems redundant to have a Express backend + REST API, why can't you just build your REST API on the Express backend?
And also, React is complex, hardly anyone seems to know the internals. The API interface might be easy to learn, but "simple" is not something that you should label React with.
I'm not sure I understand why people build websites like that. My theory would be that usually at some point you have to go lower in the stack (learn how Linux/Node/V8 work or stuff like that). You can avoid going lower in the stack, but the complexity has to go somewhere, and that's what we see here.
"Personally I want to build systems. I don't want to spend my day debugging all kinds of weird problems."
Don't we all, I guess we all crave that snap, click, build -feeling Lego gave us. But in my experience building a system means debugging all kinds of weird problems. At least, when I start something, I usually for a long time feel like I'm just hopping from weird problem to weird problem. But, TBH, those problems don't seem weird anymore as experience grows.
I still can't understand why today people choose a (Javascript) stack of build systems, ton of dependencies, and all kinds of exotic tech that is the latest and most hyped. As a developer you need to support this in the future. It might be nice to build today but it will be a nightmare later.
You know that JavaScript developers don't see JavaScript as weird or exotic, right?
Honest question, is specializing in a JS stack bad in terms of career prospects? I've been using express + react/vuejs professionally for a couple of years and I wonder if it'll be in demand in the next 10-15 years.
You’re fine — don’t listen to JS haters on Hacker News. They pine for the simpler days of sites that primarily use HTML and CSS, with maybe a little bit of JS sprinkled in. But consumers are increasingly demanding an app-like experience from the web, which requires JS frameworks.
As for Express, JS on the backend will be popular as long as JS on the frontend is popular. JS backends have their flaws, but there’s a lot of value in using the same language in the browser and server.
> But consumers are increasingly demanding an app-like experience from the web
This seems tendentious. Which average user was looking for these changes? Can you point to a site that shifted to an "app-like experience" and became successful because of it?
I think it's a "general trend" rather than a website by website trend. I think that 20 years ago most of the discussion online took place with things that looked like websites (forums, mailing lists). These days, most of it takes place in places that look like apps (Twitter, Facebook).
This is a strange way to phrase the question. Sites that had to shift to app-like experiences are hard to find, because nowadays pretty much every web app is an app-like experience from the beginning and is created with a JS framework. The shift happened years ago.
Barring informational sites like blogs and news publications, it’s actually more challenging to come up with new web products that are NOT app-like in nature, and that do not use any kind of JS framework. Craigslist may be one of the few big ones and even it is losing market share to FB marketplace, which is an app-like experience.
If I start with 1990s ebay, does it become app-like when I add the ability to zoom images without a pageload? When I add a WYSIWYG listing editor? When I let people drag and drop images into their listings? When I add JS infinite scrolling to search results? When I add AJAX search autocomplete?
Or do I have to go as far as Google Docs, re-implementing copy/paste functions, taking over the mouse wheel, and adding my own text highlighting and zoom implementations?
My personal "line" is when links won't work without js and urls aren't written in the location bar. It makes a site quite useless without js. I know that progressive enhancement is supposed to be a thing but I've yet to see it outside of tutorials (browsers not properly supporting PWAs could be part of that, but I doubt it).
Google Maps was successful from the start, and in my view, has become worse over time. Docs started off "app-like", though I haven't used it in such a long time it may be different now.
JS is everywhere though. You even have parasitic languages that compile to JS (ClojureScript, TypeScript, etc). You got Node and also Deno for back-end stuff with support for multithreading. Concequently, JS is among the most popular, and most used languages.
I do admit the ecosystem needs to find a way to have more stability, because NPM outdated package tree nightmare is pretty bad, but I guess that's what you get with an industry that moves so fast, so in that case it's up to you as a developer to not use too many dependencies.
Anyway this is all to say I don't think JS is going anywhere for the next 10 years.
Yes, but you'll find that a lot of work becomes maintenance of older systems, and less new and shiny things.
I do think the 'craze' of new frameworks popping up left and right quieted down some years ago, and things have roughly settled on React, Vue, maybe Angular (which lost a lot of its shine after the Angular 2 announcement fiasco), etc.
For a new application, I picked React + Go because I'm confident that ten years down the line it will still be maintainable - although, Go moreso than the front-end, which doesn't feel nearly as solid and stable.
But there are great things happening. The wider community has solutions for everything. (For example here's the "reactive forms are not strongly typed" issue [0] that showcases both the good and the bad. The need for this feature has clearly emerged in 2016. People stepped up and a PR was created, but ... basically no signal from the Angular team. Of course using a wrapper was an easy workaround with a distinctly sour taste in the mouth. Then finally something happened and an Angular team member now seems to be working on it in "full steam ahead" mode.)
I recently had to maintain a large React + NestJS application and I was seriously considering organizing a terrorist cell to go back in time and ...
Same stack as what I chose for my personal projects. This is just my opinion, JavaScript on the server was a horrible idea. There are far better languages to reach for when writing API’s and other server related stuff. I’m curious how you are handling authorization/authentication (assuming you are developing api’s)?
No, it's great. But keep up with the "ecosystem". Learn a bit of frontend, backend and testing too. (Then keeping it fresh won't be a problem.) And we shall see where it goes in ~5-10-... years.
These issues that you described can happen with any language, ask any programmer or system engineer with long enough experience they’ll have stories with weird problems.
Regardless which language you pick, there will always be these kinds of issues.
> These issues that you described can happen with any language
While you're not wrong, I do strongly feel it depends on the language and architecture chosen. I'm a Go developer these days, and there's a big mindset to e.g. avoid dependencies, and for those dependencies to avoid including even more dependencies, keeping things fairly lightweight and with a low 'attack surface'. I mean I personally wouldn't mind a stricter type system and native enum support and some other things, but for now, I enjoy how basic it is, whilst avoiding the footguns that C/C++ brings.
See whilst obviously the JS ecosystem is quite volatile and can be trend-based, I think there are benefits - the language breeds innovation. Innovation doesn't always make the correct choices, and some tech-conservativism is important in many types of companies. But if our ancestors had just been lazy and just stuck with what was known and good, we'd never even had computers in the first place.
This is good news for the developers, the product owners and the customers.
I still can't understand why today people choose a (Javascript) stack of build systems, ton of dependencies, and all kinds of exotic tech that is the latest and most hyped. As a developer you need to support this in the future. It might be nice to build today but it will be a nightmare later.
I have seen days go to waste because of Docker misconfigurations, problems with dependency versions, outdated dependencies not available anymore, bugs deep down in an unknown dependencies, and so on. Personally I want to build systems. I don't want to spend my day debugging all kinds of weird problems.
The (old) WhatsApp teams sounds like a great workplace.