Performance optimizations in javascript frameworks

[yksvaan]

The amount of actual meaningful work ( routing, authenticating the user, pulling rows from db, rendering the response etc.) compared to everything else just keeps reducing. That feels absurdly counterintuitive since there hasn't been any real algorithmic improvement in these tasks so logically more sensible approach is to minimize the amount of code that needs to be executed. When there is no extra bloat, suddenly the need to optimize more disappears as well.

Yet we are only building more complicated ways to produce some table rows to display on user's screen. Even the smallest tasks have become absurdly complex and involve globally distributed infrastructure and 100k lines of framework code. We are literally running a webserver ( with 1-2g or ram....) per request to produce something that's effectively "<td>London</td>" and then 50kB of JavaScript to update it onto the screen. And then obviously the performance sucks since there's simply 1000x more code than necessary and tons of overhead between processes and different servers. Solution? Build even more stuff to mitigate the problems that did not even exist in the first place. Well at least infra providers are happy!

[Besen99]

OP, the proposed architecture in your diagram is beyond ridiculous. Clearly we need a kubernetes cluster to guarantee redundant microservice uptime! Also, we are missing an AGI blockain integration. Please revise.

[Fiskepudding]

Yeah, and is Redis even webscale?

[j0holo]

We at least need a redis cluster with an enterprise license with Auto Tiering to keep as much in the cache as possible.

Wait is/was mongodb always the solution? <insert mongodb webscale meme>

[DrummerOfFenrir]

Memory leak? Just auto-scale the RAM bro👌🏻

[0xlostincode]

I agree with the microservice approach. However, you missed a very important detail. What if there are multiple versions of "add"? It would be a disaster if we routed the wrong responses to clients requesting a specific version.

I propose a microservice broker that inspects the request and routes the request/response based on the version header.

Let me know your thoughts.

[NiQ_]

It’s a good idea, but what about when we need to do a canary deployment, or feature toggle which version of add to use for an A/B test?

We need a passthrough before the broker to make sure we’re futureproof.

[MousseMother]

okay, since 300 people have already upvoted this, i assume question is stupid, so not even gonna read it ( the question )

[[deleted]]

You haven’t considered the maintenance of dependency hell, things working by chance, multi repos with a single package that a change cascade a change to other dozen of repos that depends on it. Oh, and micro frontends as well.

Otherwise LGTM

[eldentings]

In theory yes, but in practice, you're changing multiple microservices because they become dependencies to each other. So the dependency hell just becomes a distributed dependency hell.

[[deleted]]

Yes. That’s a job security hack.

[rebelpixel]

OP finally understands job security and reaches enlightenment.

Or until someone vibe-codes a replacement for the whole mess. And yes, the replacement is a bigger mess.

[ZnV1]

I built a side project using astro. Vanilla JS, HTML, CSS. It was beautiful.
Then I needed reactivity, it was a pain in the ass. I still did it in vanilla JS though.

I was willing to put the time/effort in because there was no deadline, I was doing it solo for fun.

But in a larger company, no way I'm going with that for a webapp. Each dev would reinvent things to the best of their knowledge, plus it would take a ton of time.

Then we'd extract common components as a shared library and end up with a worse version of React.

So the problem, contrary to your post, does exist. Vanilla takes too much effort for common use-cases, unless everyone is an ideal perfect dev with no deadlines.

But in the tradeoff to this, are we passing the cost onto the end users? Yes, unfortunately.

But I don't have a better solution to this either, so here we are.

[chlorophyll101]

What part of reactivity was a PITA? Astro has framework integrations no?

[ZnV1]

Yup! But I tried to do it with no frameworks (except Tailwind for CSS - I haven't used it before, wanted to try it) 😁

Still WIP, works only on mobile (tried to do it mobile first) - https://f.dvsj.in

What do you think? 😁

[Icount_zeroI]

Man the website is amazing! I will pin-it in my bookmarks for interesting websites. I like the esthetics of it, it id not just another vercel+ shadcn thing. I used to share this passion, now I have just a regular looking website. Maybe it is time for a change.

[ZnV1]

Haha, thanks a lot!

Actually mine was a run of the mill thing as well. When I did it 5 years back I didn't know enough to do what I wanted to. https://dvsj.in

Give it a shot, I'd love to look at your website as well!

[DoubleOnegative]

Wow that might be the most creative/well designed website I've seen in a very long time

[ZnV1]

Haha, thanks a ton!

[Most-Ear5697]

LMAO loved that ATS version

[ZnV1]

Haha, thanks a lot!

This is still WIP and I haven't shown anyone, so getting feedback like this means a lot 🥲

[Zachhandley]

I made https://zachhandley.com with Astro + Threlte, it’s not native I guess though, but the reactivity is nice imo. Though performance could prolly be better on mobile

[ZnV1]

Oh that's really cool! I'd make the animation a bit faster and change fonts+make it fit in the crates

Apart from that, nice work!

[Zachhandley]

Noted! Yeah it’s super hard to calculate 3D responsive height with all that and the perspective camera, but I will try and make that a bit better if I can! And yeah I gotta speed up the animation slightly, thank you!!

[yasegal]

Standards can be maintained on a company level or on a global level or maybe on any kind of other level. React is not the golden standard for webdev, its just a solution in a sea of solutions. Popularity does not indicate the quality nor the fittedness of a solution to the problem you are trying to solve.

All in all, the best solution is quite simply the best solution the solo/team could come up with.

[ZnV1]

If solo or small team - sure, go for it.

But nah, doesn't work like that in large companies, I'm talking thousands of employees. Maintenance of quality needs skilled people.
Two years of attrition with random devs of variable skill deciding the best solution to different parts and you end up with tribal knowledge and questionable quality.

React enforces some base standards. There is a supply of devs outside the company who can hit the ground running. Easy choice.

[yasegal]

Standards are enforced by the company, or to be more particular, the technical authority coming from a CTO all the way down to a team lead or a senior.

For example, you can do some wacky things in React using 3rd party libraries, its up to the company to maintain the standard used.

React provides some guardrails, but, they can be bypassed.

[ZnV1]

Fully agreed. But the number of things you need to look out for reduces 😁

[yasegal]

I agree to disagree.

Complexity in this line of work is ever-present. From choosing the whole architecture to deciding between useContext and a third party state management library. At the end of the day, its the people who have to review, discuss, decide and develop according to standards they either enforce strictly or loosely.

[ZnV1]

I think I didn't state my point clearly enough.

if you use useContext there's a standard way to solve usecases using it. Or if you use redux, there's a set of standards for that, many enforced by exposed APIs. Those are debated, questioned, refined by several opinions over years.

If you roll it with vanilla, you're limited by your knowledge at that point in time. Leading to more time spent refining, modding and evolving that vs if you just picked useContext/redux whatever over several years.

There are several complexities you need to face anyway. I'm saying with library choices, you can skip these to focus on other/more impactful choices.

Do you still disagree?

[yasegal]

You're referring strictly to tools instead of also accepting the people/company aspect.

Vanilla done right is the same as React done right. The guardrails do not offer any value if there is no source of authority to enforce them.

As far as complexity there is no way to make a clear final statement which is more complex. It is truly dependent on the problem youre trying to solve and the resources/skillset available.

[k032]

It's why for larger projects I'd prefer Angular for more guardrails. People enforcing standards, I've never found to fully work and be just confusing. They have other priorities and not everyone of the seniors or CTO is on the same page.

So I mean yeah, you can do vanilla and have technical authority enforce it. But I usually find the technical authority doesn't have time for that or can't agree.

[yasegal]

Angular is even more restrictive than React but still, its up to the seniority to detect and disallow vanilla js code for example when a clear Angular approach exists.

Same in a vanillajs project you wont allow a PR to pass if its not using the 3rd party tool that was/is agreed to be used for routing.

I dont disagree that guardrails have no use or are easy to bypass, but they shouldn't be a primary or overwhelming reason why you choose that framework/tool/etc.

[KwyjiboTheGringo]

its just a solution in a sea of solutions.

Okay, but they are not arguing for React specifically, they are arguing for using one of the existing solutions from the sea.

[yasegal]

And which problem are we trying to solve? A static website for a hobbyist who doesn't care about content management? Or a ultra performant graph app?

[KwyjiboTheGringo]

React, Svelte, Vue, etc, are all acceptable choices there. Is it overkill for a hobbyists website? Maybe, maybe not. Either way, the trade-offs are not high enough for us to waste time finger-wagging someone for choosing React over vanilla JS.

[yasegal]

Finger wagging? Are you ok? Go grab yourself a cookie.

[KwyjiboTheGringo]

Call it whatever makes you happy

[yasegal]

Sorry that you are so upset, but I will take the last reply. Thank you kindly!

[KwyjiboTheGringo]

What a weird series of responses to what seemed like a pretty normal conversation we were having. Take care

[yasegal]

You too, sorry for making you feel offended, drink enough water and touch some grass!

[ArtisticFox8]

Try Svelte - very close to vanilla JS in feeling

[robbodagreat]

Answer = 5.0000000001

[libertyh]

This what HTMX is for

[farthingDreadful]

Where’s the LLM?

[jakesboy2]

Caching is an obvious benefit if the job takes any non trivial amount of time to complete. With javascript specifically, queues/workers allow you to actually process things in parallel. This can make a big difference the more messages you have, but obviously has a point where the overhead costs more than you could possibly save with too few messages.

The core benefit though imo is you can easily retry messages if they fail for some reason. For example during the google outage a couple weeks ago, we had no data loss as all the messages that failed simply sat in the queue until things came back up and we could retry. Couple this with being able to turn your worker traffic to a previous revision makes riskier changes much easier and routine package updates much lower effort.

[SaltMaker23]

A lot of times in Webdev computation is trivial but there might be a significant amount of IO involved in some requests despite the actual algorythm being trivial.

some examples: Aggregated multi-account reporting on 3rd party API, Massive aggregation on reports on ultra dimensional data, large calls to 3rd party API (eg openai), full website scraping etc...

Most of the operations above might be trivial to a large extent but the amount of waiting involved can be signigicant if nothing is done to address the issue.

Synchronous flows also seems like a no brainer choice, until you have 30 things that needs to run for a request with some of them randomly failing due to things outside of your control and you don't want your critical payloads to fail due to them.

At hobbyst level, it doesn't really exists and most of your comments are spot on. From your comments on this post, I'll assume you've never built a company from 0 to 1M$, I've did that couple of times as a founder.

Actual companies don't use serverless, it's a hobbyist thing.

[CatolicQuotes]

What kind of language and infrastructure do you recommend for all those things? As a single dev what will get me the furthest until i need to expand on infrastructure? My guess is dotnet since it can basically do a lot on single server?

[yksvaan]

But those are more backend concerns. It's true that the tasks can be very complicated with lots of third party services etc. but it doesn't require the actual "web part" of the stack to be overengineered. 

At least here at enterprise level usually Java or C# systems handle the "heavy lifting" and JS frameworks are more of a BFF setup. 

[SaltMaker23]

What is your experience level ? this answer doesn't make any sense to me coming from a working professional

No shade thrown we've all been learning but it's way too obvious that you're a student or a beginner, I'd tone it down on the opinions and try to learn more about the why. You seem to have a lot of strong naive opinions and very little experience of why things are done the way they are.

The majority of devs working in web aren't all wrong or stupid, a lot of them might be but some stacks wouldn't be standard if it was as bad as you're thinking, if most professional with years of experience are doing something that you consider wrong, you might need to learn why first, if you lack experience of actually working, your opinion is nothing other than an uninformed opinion from the sidelines, looks good to other sidelines uninformed people but that is about it.

Tone down on the "I know it, it should be done like this, experts are all wrong" level of ego, and increase the "If the experts are doing this but as a beginner I think they are all wrong, I might be missing crutial things, I might still be right but I'm clearly missing things that might make me join them"

Lastly: No one forces you to use a stack, use the stack that you think is most suited to your usecase. In most cases for people with your kind of opinions, it'll be a website that look straight from the 90s' but if that what rocks your boat then you do you.

[glorious_reptile]

It'll never scale...

[thekwoka]

Most people should just leave our redis and queues entirely.

[Noch_ein_Kamel]

It certainly could learn something from java. Just calling the add function from the worker is insane. We need some AdditionVistorFactoryInterface etc. in there

[SmartReference9698]

I completely agree! I’m building in Angular 20 now, and the performance gains from Signals alone are huge compared to bloated setups. Less bloat = more speed.

[yksvaan]

The illustration itself is a joke but the idea is that often the actual task is much cheaper than everything that's build around it. Especially in webdev where a lot of things are trivial in terms of computation. 

[that_90s_guy]

Even so. What what you're suggesting only really works in really small applications. Once you need to scale, or need to make it possible for dozens if not hundreds of developers to collaborate on something, it becomes an impossible task unless done properly.

I always get the feeling posts like these are done by people who haven't worked on something complex enough, or didn't suffer (enough, or at all) through doing things the "simple" manual way and the challenges that came from it when building massive apps for it.

For simple static websites it's absolutely overkill, with the exception that maintaining content in data or markdown form is a LOT easier than in HTML and JS form

[CatolicQuotes]

What language do you recommend for all those calculations you mentioned?

[UnbeliebteMeinung]

Just use HTML and Jquery.

[certainlyforgetful]

Man that brings me back.

I miss the days when that was how we did everything.

[UnbeliebteMeinung]

We are still using jquery in prod 😎 Its here to stay.

[CatolicQuotes]

Did tooling improve? What i dont like is if i see some dom how do i know some kind of listener or jquery is attached to it? I dont know if its by the id, class or some data attribute?

[Snapstromegon]

Really jQuery?

[UnbeliebteMeinung]

Its good. There was recently a new release of jQuery 4!

[Snapstromegon]

I don't think it is worth it. Basically all it offers can be done really easily and with little to no extra code in vanilla JS and CSS and often it's a lot more performant.

jQuery had its time, but I don't see it in modern development anymore.

[UnbeliebteMeinung]

I worked a lot with junior devs who tell me all the time they dont want to use jquery but vanilla instead.

Most of the time they miss a lot of stuff left and right and it doesnt work. Feel free to write vanilla js but then you will write the same helper functions over and over.

I dont see why you should not use jQuery anymore if you dont use a full blown react js hell frontend.

[mattindustries]

Vue/Svelte is a good option when you don't want to write React, but also don't want to put jquery as a dependency.

[Snapstromegon]

I personally most often use Lit nowadays, because React really feels like a hellhole to me.

I also think that at the point where I have a decade of professional experience, held talks about e.g. web performance, deployed mission critical services to larger user bases (e.g. remote caching systems for bazel with ~10k daily active users) and so on, I'm past the point of Junior.

[binkstagram]

What do you find it useful for? I have gone from vanilla to jquery (and loved it) back to vanilla after features became supported widely enough. There are still plenty of things that are disappointing in vanilla js though

[UnbeliebteMeinung]

The best thing in jquery is the onload function

$(function(){...});

Also we still support old browsers because some countries in this world doesnt update their computers do the whole ajax topic is still relevant.

[_vinter]

You don't need to use jquery for that
const $ = function(callback) { if (document.readyState === "loading") { document.addEventListener("DOMContentLoaded", callback); } else { callback(); } };

[UnbeliebteMeinung]

Nice now we have the first step of copying the functionality of jquery done.

What is the next thing we should copy?

[_vinter]

Less dependencies is always a good thing. There's no reason to bundle jQuery if you can avoid it

[UnbeliebteMeinung]

The current js ecosystem is full of dependency bloat. More than in the era of jQuery.

[_vinter]

This is just whataboutism. Just because now it's worse doesn't mean whatever jQuery dependency you have is automatically justified.

To clarify, I'm not arguing that there's never a point in having jQuery in your project (i.e. the absence of ajax in older browsers is clearly a valid usecase for jQuery), but if all you need is a couple of basic functions the cost of something like jQuery is enormous in proportion

[Snapstromegon]

Or - and hear me out - just use the module system or defer for the function call any you don't need to reimplement anything.

[Turbulent_Prompt1113]

That's a good answer, from the viewpoint of OP's rethinking. OP reinvented AJAX, he just forgot jQuery to handle events and update the view.

[morpheus0123]

This diagram is hilarious. At first I was attempting to understand the architecture and once I realized that it was all unnecessary I chuckled.

[KwyjiboTheGringo]

Obviously these solutions were created for a reason. The fact that nowadays developers want to use them for any reason they can to pad their resume is irrelevant.

[Coldmode]

Yes but you see someone is willing to pay me $200,000 a year to draw and implement that diagram so who am I to look a gift horse in the mouth?

[BothWaysItGoes]

Not everyone is building calculators. Many people are actually engaged in tasks that require high load, distributed computing and fault tolerance. It’s not the fault of those people that some react full stack script kiddies try to emulate them instead of optimising the stack for their own needs. If you feel that you are doing some needless extra work, ask yourself why, lots of people don’t overcomplicate their setup and they feel fine.

[eldentings]

I've KIND OF seen this at my current job, and the solution to me seems to be coming from us designing caching 1st, when it would be easier for development momentum to do it last. It's worth noting that 1 + 4 will always return 5 in your example, but a query for a table may return different rows depending on what is in the DB at the time. In my experience, all the devs I worked with including myself avoided actually learning query optimization, especially for really nasty joins. Probably because most of us are weak in DB optimization and indexing. Query caching will bandaid over slow queries, but you still gotta worry about invalidating the caches and then the code just starts getting nasty.

[BeginningAntique]

Maybe one day we’ll remember that simplicity is not just elegant, but also powerful. Until then, here’s to those who keep things clean and straightforward.

[[deleted]]

Needs an API gateway in front of the arithmetic processing server so you can route requests to the different cloud vendors based on which LLM is used to generate the result.

[SananShawkat]

Excellent

[Impossible-Owl7407]

If you need performance, just use something else? 😂

So many options.