random

Ranter

techcatchers

594

Comments

1

p100sch

1446

5y

Troll answer: "So, you mean we should parse the site for the client and should stream the result instead. After all, that is the most time consuming task."
Google: "What a brilliant idea. It will go well together with our stedia service."
3

techcatchers

594

5y

@p100sch He even went on to say this would be a problem on old devices and PCs.

So, are we living in 1980's?

And the irony is we are using react for the front end.
1

vane

11052

5y

🤦‍♂️🤦‍♂️🤦‍♂️
1

p100sch

1446

5y

@techcatchers What will be next, force the user to use the IE version. Because backwards compatibility. That would honestly be hilarious.
3

Krokoklemme

4453

5y

"yes, practically none"
10

netikras

34843

5y

Your answer was incorrect. Frontend almost always has more processing power.

Add up all the backend servers and sum up their processing power.

Now add up all the frontend consuming devices that run your js with all the loops et al and sum up their processing power.

Now compare them.

You backend is soooooo far behind the frontend proc power.
1

techcatchers

594

5y

@netikras My assumption while saying 'Backend' was the processing power of all servers and a single frontend device.

Anyway, your answer would have pissed him off even further. Lol
1

netikras

34843

5y

@techcatchers and yet unless your service has under 10 users I believe your whole bkend might add up to less processing power.

If I alone open up your website it's already a 4GHz i7 hexacore machine. If 10 users like me open it -- do the math. And yes, # of cores has impact on js too, even though it's single-threaded.
6

Root

79767

5y

Server cpu is expensive, both via limited amount (thousands to tens of thousands of clients per server) and cost. You very literally pay for server cpu (via hardware or time), and increasing the total amount is always expensive.

By contrast, client cpu is free in cost (they run your code by choice) and almost free in amount. Eventually increases in cpu use will cost UX, but you can always (and often easily) scale this with device and connection specs to mitigate it.

------
tl;dr, the client is your bitch. Make it do all of the boring, unimportant busywork.
3

bittersweet

46031

5y

@Root

Bandwidth, both server-server and server-client is the biggest bottleneck though.

Better to write a good SQL query, than to filter through half a million records in JS.
1

Root

79767

5y

@bittersweet ofc
0

bittersweet

46031

5y

@Root Now that I'm thinking about it.... it's also dependent on the type of website.

If your customers are paying, and you want to give them an optimal experience, you might go for stuff like server-side rendering, large redis/elastic caches, workers to warm up those caches, etc.

If you serve something that users are really attracted to regardless of performance, like clickbait articles about popstars and top 10 lists, you probably want to cram in as many JS tracking scripts, ad banners and caroussels as you can, because users are stuck with their brainless browsing addiction anyway 😄
1

Root

79767

5y

@bittersweet 😮
I would never!
0

bittersweet

46031

5y

@Root You passed the test. You are now a Certified Javascript Developer.
1

Root

79767

5y

@bittersweet 🙄 Pass.
1

bittersweet

46031

5y

@Root You passed the second test. You are now a certified and slightly bitter Ruby developer.
1

Root

79767

5y

@bittersweet It's true, though I'm bitter for very different reasons 😋

I think I'm mostly bitter because humans are a thing. And not a particularly good thing.
1

bittersweet

46031

5y

@Root That's why I'm on my 23th refactoring branch.

*drops EEG wires on floor, wipes bloody scalpel on hoodie*

git reset --hard

My basement is starting to get a bit crowded

Related Rants

Add Comment

devrant

rant