These are the people building the CMS that powers significant portions of the Internet

*heats up your computer*

Attached: web.png (900x495, 163K)

Google fonts are honestly the worst for this. You make one call to one domain, and it returns like ten lines of CSS sending you off to fetch multiple font files from a different domain.

Just inline that .css you might ask? Nah, webshits flip out about Google being faster.

>quoting hacker news
bold choice.

If that's so, why are sites so god damn fucking bloated?

Well i could have quoted reddit

Attached: reddits2.jpg (1009x99, 15K)

it's an important concept. as people will often agonize over meaningless shit. but using a build tool that removes unused code is not what it refers to.

because of niggers like the one in OP
you wouldn't believe how infected senior positions are with these piles of shit

u are a retard, premature optimization doesnt exist, if you know what u are building you should be competent enough to architect it properly and reason about points that will take most of computing time/power/size and try to reduce it since the start

because most sites are used by god damn NPC retards that have a 1 Hz clock so 300ms or 800 ms, they wont notice it, and if they do, they'll blame their iFag phone for being too slow

But it is. I was in marketing and most people leave if your website takes longer than 2-3 seconds. That contributes to the bounce rate and thats when you go attack the webdevs.

Marketing are nearly always the problem though.

>Build nice website
>Put lots of effort into optimising
>Marketing replace 300KB images with 11MB images then scale with height= so they look the same on screen
>Marketing use three different fonts hosted on three different domains
>Five different tracking tools because different marketing people have their favourites

for loops are ugly and add unnecessary noise to the code. if they perform worse, it should be the compiler's / interpreter's job to perform the necessary grunt optimizations instead of requiring the programmer to perform straightforward conversions into less readable code. this is the same reason we don't use assembly anymore.

>u are a retard, premature optimization doesnt exist, if you know what u are building you should be competent enough to architect it properly and reason about points that will take most of computing time/power/size and try to reduce it since the start

Attached: b4665eeb.jpg (1060x1168, 78K)

For loops are completely readable.
>if they perform worse, it should be the compiler's / interpreter's job...
Not feasible due to language semantics.
You think V8 engineers wouldn't have done so already if it were easy/doable?

itt: incels complaining about webdevs

t. Jow Forumsprogramming and/or hackernews react ninja XD

Attached: 1535408720795.png (7004x4951, 1.49M)

>For loops are completely readable.
But they do add unnecessary noise, like always having to ensure your iterator variable does what you'd expect it to do. And they can suffer from off-by-one errors, something a simple map call never can.
>Not feasible due to language semantics.
Why would it be impossible? In fact, transforming a .forEach call would indeed be trivial. You're right about .map though, since it creates a copy it's not possible to straightforwardly turn it into a for loop without some extra analysis.
>You think V8 engineers wouldn't have done so already if it were easy/doable?
Have you benchmarked looping structures for yourself? I have, and the differences are so small they don't make any difference, unless it's the bottleneck of your code.

> he wrote in a thread featuring a Reddit screenshot in the OP

Webdevs are the special olympians of programming. That's why they use JavaScript and Python instead of C++.

>we don't use assembly anymore
yeah fuck off retard you dont know shit lol

>In fact, transforming a .forEach call would indeed be trivial
No by ES spec there's more checks etc.
Even somewhat recently V8 could still blow up array size if you called forEach depending on your exact code.

If you're just running through some elements whatever, but if you're writing a library that will be used a lot or similar just use the faster low overhead option. The number of people running your code is likely way higher than the cost of you looking at a for loop.

>not understanding abstraction, the basis of modern computer science
>using assembly for things that don't benefit from it
Whatever helps you cope, fag

>No by ES spec there's more checks etc.
What do you mean? Why wouldn't you be able to just inline the body of the function? It's no different from C++ function call inlining.

I don't disagree on your last point, if you're writing a generic module that is expected to use up a lot of cycles, then obviously worrying about these kinds of micro optimizations becomes important. But even then the most important thing is analyzing which parts of your code the actual bottlenecks are, not just blindly transforming everything into less readable versions by hand.

Also in fact, a for each loop should be faster than a for loop in JS. A for each doesn't need to do bounds checking like a regular for loop would. So no, lower abstraction doesn't equal more performant necessarily.

>Well yes, a sufficiently smart compiler could inline it. Currently we don't. It's not as trivial as it may seem at first glance though. (Who's to say that the .bounce method doesn't fetch bounce.caller, the closure you expect to be eliminated.) The performance of .forEach will always be at least a little worse (requires more expensive warm-up), and will need more expensive tracking that a simple for-loop.
V8 dev from awhile ago, you can find similar comments more recently. I can't find blog with description of some of the specific issues.

Imo relying on the interpreter can be bad because what seem like unrelated changes elsewhere can cause it to fail to optimize or similar or even just changing versions, unlike compile code you're less likely to notice since you're not shipping new binary just users update chrome or who knows what.
A for loop is unlikely to ever have any performance regression ever due to simplicity and how common they are.
>But even then the most important thing is analyzing which parts of your code the actual bottlenecks are, not just blindly transforming everything into less readable versions by hand.

Sometimes it's just death by thousand cuts. A for loop is not unreadable hand optimized mess it's one for the most common control flow structures in programming.
If you can't read a for loop you're a spastic.

>Who's to say that the .bounce method doesn't fetch bounce.caller, the closure you expect to be eliminated
Well, I see that some exotic JS things like "this" references and metaprogramming features could cause problems - but at the same time it shouldn't be that hard to make minor changes to the code emitting phase to accommodate for that stuff. I suppose they don't want to add that extra translation overhead or just want to avoid the work.

IMO this is really just a strong argument for shipping binary code and favoring languages with referential transparency and whatnot.

>Sometimes it's just death by thousand cuts. A for loop is not unreadable hand optimized mess it's one for the most common control flow structures in programming.
Only if your library is causing a significant bottleneck in the programs using it.
>If you can't read a for loop you're a spastic.
I think I should have made it clear by now that not understanding loops is not the issue I'm raising here

Isn't for each just a for loop though?

The future of the web is downloading 1gb of useless shit just to see a carousel of crappy stock images in a website that barely works and is really hard to use and ultimately useless.

Kill me.

I bet he loves ruby.

samefag lol

>I have never had to build a large scale project under a SCRUM cycle

That's all you had to say my friend.

Quality has little to do with competence and everything to do with time. The current working theory within business is to push out software as fast as possible then optimize if, and only if, the customer complains.

Sure management may want you to pay lip service to building the most efficient solution, but no one higher than your senior engineer could give half of a fuck about the quality of the code. They only care about hitting deadlines.