At a previous job, there was an argument over a code review where I had done some SQL queries that fixed a problem but were not optimal. The other side were very much "this won't work for 1000 devices! we will not approve it!" whereas my stance was "we have a maximum of 25 devices deployed by our only customer who is going to leave us next week unless we fix this problem today". One of the most disheartening weeks of…
This is why everyone uses microservices and React. We don't know how these work, but we are netfligs/farcebook level companiez, so we must.
What? How does react fit into that? It's just a web framework that works for any scale basically. If you are a react dev and familiar with react, it's as easy as anything else to use. Now sure if you're not familiar with it you'd have to learn it but that's not an issue with react.
Best example I've seen is wanting to optimize a frontend JS for loop that gets triggered maximally only once per page load, runs max 100 times in a loop with complicated data structures that will confuse any reader of that code why it was done like this and not just with a for loop.
It's such a Dunning-Kruger effect. You get legitimately talented engineers who are talented enough to do a legitimately hard thing: optimizing a complex piece of code. So, they don't realize that there's kind of another level of understanding beyond that (when to optimize vs. how to optimize) There's also the fact that some people just like optimizing shit for selfish or even slightly nefarious reasons. Some just lik…
I don't know how to exactly classify this, but based on my experience it feels like a certain type of engs who have only been exposed to this type of way of doing things from when they started, like at uni. It's to do with going through certain type of education, after that certain type of enterprisey environment following very strict rules of design patterns and applying these patterns to absolutely everything they do. They haven't done many quicker projects or side projects to realize that simpler things can work absolutely well enough to realize there can be flexiblity. I think they are good people and outside of work I get along well with them, but during work I do feel frustrated and when I try to explain it to them, I get kind of a West World like response "Doesn't look like anything to me". Like they can't get it, because they only have the uni and enterprise experience, and not experience to build things on their own volition.
This is why everyone uses microservices and React. We don't know how these work, but we are netfligs/farcebook level companiez, so we must.
What? How does react fit into that? It's just a web framework that works for any scale basically. If you are a react dev and familiar with react, it's as easy as anything else to use. Now sure if you're not familiar with it you'd have to learn it but that's not an issue with react.
~90% of SPAs could be static HTML with a few kilobytes of vanilla JS sprinkled in for AJAX.
What? How does react fit into that? It's just a web framework that works for any scale basically. If you are a react dev and familiar with react, it's as easy as anything else to use. Now sure if you're not familiar with it you'd have to learn it but that's not an issue with react.
~90% of SPAs could be static HTML with a few kilobytes of vanilla JS sprinkled in for AJAX.
And they could also be react apps. What's your point? For a lot of people, a suitable react app is easier to make than the equivalent static HTML page with vanilla JS. The "it should be static HTML with a sprinkle of JS so the filesize is extra small!" guy is the one overengineering, here. The SPA's 20 customers are all using modern web browsers on modern first-world internet connections and don't care or notice that the page is not Stallman-approved.
What? How does react fit into that? It's just a web framework that works for any scale basically. If you are a react dev and familiar with react, it's as easy as anything else to use. Now sure if you're not familiar with it you'd have to learn it but that's not an issue with react.
~90% of SPAs could be static HTML with a few kilobytes of vanilla JS sprinkled in for AJAX.
Why? The whole thread is about how keeping it simple is supposedly better. Using react when you know react is easier than static html+ajax. It handles a lot of stuff for you and you can then use the incredibly rich react ecosystem for everything else (authentification, forms). Even a pretty basic web app usually requires those, so again, it's simpler to just use react and it adds basically no overhead for a react dev.
Plus, the big issues with react usually only manifest themselves in larger web apps, so it's basically "perfect" for simple stuff. You could make a functional react page in a single file in a few hours.
~90% of SPAs could be static HTML with a few kilobytes of vanilla JS sprinkled in for AJAX.
And they could also be react apps. What's your point? For a lot of people, a suitable react app is easier to make than the equivalent static HTML page with vanilla JS. The "it should be static HTML with a sprinkle of JS so the filesize is extra small!" guy is the one overengineering, here. The SPA's 20 customers are all using modern web browsers on modern first-world internet connections and don't care or notice that…
Stallman-approved pages will happily welcome any and all users visiting your site. Modern SPAs maybe not so much due to the overengineering and mostly unnecessary features.
These days, I would, yeah, but this was a long time ago and I was a lot more invested in not letting nonsense go past without a fight.
Yeah it's one of those things where it's like... ...okay, I can let this nonsense go today with very little impact, but if I do... will the team need to deal with it 100 times in the future? (And more broadly, by silence am I contributing to the evolution of a bad engineering culture ruled by poor understandings?) It is very very difficult to know where to draw the line.
Three axes in my mind to take into account: Likelihood, impact, and complexity. The article seems to mostly be about likelihood and complexity. I'd place more importance on impact and complexity. It's worth saving a headache later if it's simple to do right now, however unlikely it is, as long as it doesn't create a maintenance burden before that point.
~90% of SPAs could be static HTML with a few kilobytes of vanilla JS sprinkled in for AJAX.
And they could also be react apps. What's your point? For a lot of people, a suitable react app is easier to make than the equivalent static HTML page with vanilla JS. The "it should be static HTML with a sprinkle of JS so the filesize is extra small!" guy is the one overengineering, here. The SPA's 20 customers are all using modern web browsers on modern first-world internet connections and don't care or notice that…
People seriously underestimate the amount of clients you can serve from a single monolith + SQL database on a VPS or physical hardware. Pretty reliable as well, not many moving parts, simple to understand, fast to setup and keep up to date. Use something like Java, C#, Go or Rust. If you need to scale you can either scale vertically (bigger machines) or horizontally (load-balancer). The SQL database is probably the h…
Kotlin probably deserves an honorary mention instead of Java.
I dunno, I've lived the other side of this where people made boneheaded choices early on, the product suddenly got traction, and then we were locked into lousy designs. At my last company, there were loads of engineers dedicated to re-building an entire parallel application stack with a view to an eventual migration. A relatively small amount of upfront planning could have saved the company millions, but I guess it w…
More experienced software engineers can usually make the right design decisions that don't mean rebuilding when/if it comes time to scale things. This is usually about avoiding bad decisions because they know better.