How the fuck can a single web page take up 1GB RAM?!?! Optimise that shit please

Only 1 GB....

*hrhrhrhr*

@IntrusionCM yeah, for a page that is purely text based, like a simple blog post

You can't optimize that.
Throw the whole thing into the trash and start over.

Easy. It's called appDynamics

The average frontend dev is a completely incompetent idiot as proven by the average website. The average frontend dev is probably even too stupid to hit the toilet bowl when shitting. Really, no other dev domain has the norm level that low.

@Jilano 211MB without js

@shoop to expand on that, there should at least be some tutorials on how to write optimised JS as the web is effectively written in it

@shoop The problem is not them writing HTML. OK, partly it is because they're too stupid to even understand the point of HTML.

The problem at hand however is them being JS junkies who replicate native HTML/CSS functionality in JS.

**cough** jQuery **cough**

@Fast-Nop I am particularly mad at a library called "posed". Look it up, and knowing your stance, you'll be mad too. Just guess what native CSS functionality it replaces.

@kescherRant
https://github.com/Popmotion/...
?

@IntrusionCM Precisely that one.

It is often used to create transitions that could be made in CSS. Those usually bring my pretty good PC to its knees, framerates under 60 are unacceptable. On a fucking webpage.

@Fast-Nop exactly the reason why I tell people that web development is one of the lowest forms of development there is. Everyone is completely happy with throwing absolutely everything in a website without considering optimization. There is no point in having a completely battle tested backend made with the fastest tools available like Swoole, Rust, whatever the case if they are just going to throw a mountain of shit into the frontend

@kescherRant dear lord I didn't know this existed. I tend to dislike working with CSS, but this is an entire library made to do something relatively simple

@AleCx04 I love CSS, and on a note related to that, IE11 is much better than iOS Safari.

@AleCx04 web development is not a low development part. Developers are.
À good web dev knows how to optimize things. The problem is that : 1. Many newcomers start with web dev, lowering the average quality of everything.
2. Managers don't care about performance. They care about profit

Back-end devs can mumbo-jumbo managers about performance : they don't understand anything anyways. Front-ends cannot do that so easily

@react-guy lol.... Seriously?

If you are a good frontend dev, you shouldn't push a 1GB shitton of files out.

You should know your asset generation by heart....

And No. We cannot mumbo jumbo managers. We have to Butt Kiss, Powerpoint and Excel the shit Out of them so they don't let shit burn totally down with the nice comment "oh I didn't think it would be thiiiiss bad"

It's not so much the dev's fault, as it is the cut-throat culture of companies where applications are developed.

Apps, whether they're web, mobile or native desktop based, must be developed fast, and the feature-set must stay "agile". Companies want to rapidly experiment.

This requires languages and frameworks which are suitable for creating a huge fat mess.

While the API offered by browsers has become more elegant over time for developers (ES6+ is kind of sexy), the ever-expanding feature set also means that browsers have become heavier -- from talking to GPS and Ambient light to websockets and WebGL, browsers have become operating systems.

@AleCx04 I don't think it's fair to turn this into a webdev only thing though...

Why the fuck does every random mobile app require a 200MB download these days? Why is VSCode using 300MB ram when there are no open files?

Oh wait. EVERYTHING is made using web tech these days...

*cries in Javascript*

*seeks comfort in Rust*

I'm with @react-guy on this. A lot of the crap that comes out is due to shitty development process more than shitty developers.

One of the guys I worked with is a full stack who literally get's paid everyday to add new features to clients projects. There is never any reduction, or optimizing, or anything. The clients only want "more stuff", and he actually can't do anything about the shit load of crud that builds up without working for free.

With that said, not optimizing your assets and dependencies is lazy, and poor practices and a lack of code review is rampant in both front end AND back end web development.

@Jilano it started long before js came to desktop apps. Did you ever look at the size/perfs of Java apps?
Ever heard about python3 vs python2 and the whole depency mess it creates?

Web dev suffers the same disease. It is just more apparent because of download times and the newcomers effect I mentionned earlier.

@IntrusionCM I agree, if you are a good developer in general, you should care about your dependencies.

My point is that the ratio good dev/bad dev is, I believe, lower in the web dev industry than any other in IT. Simply because the entry barriers are fewer, many junior devs start with web dev. Some hobbyist may even create libraries that professionals will use, sometimes not even knowing it.

This lowers the average quality, but I also suspect that the variance is higher than anywhere else.

About the mumbo jumbo thing: from the economical point of view, improving the backend makes sense, because it lowers the operational costs (fewer servers). Improving the perfs of your web app will not lower your costs. At best, it will improve your conversion rate or user satisfaction. Much more complicated to anticipate and justify.

Frontend dev is so lousy also because it doesn't really matter. Sure, your average frontend shithead will cost his customer some 30-50% of turnover because the website is slow, bloated molasses infested with shittons of useless JS garbage and other crap.

So what? Right now, economy is demand driven because there are more goods for sale than people can afford to buy. If not for crappy websites, suppliers would take hits for other reasons.

Dev work like infrastructure is a totally different game because if say money transfer stopped working because telco broke down, the whole economy would grind to a halt.

It’s all well and good learning web development to begin with as it’s a good starting point with each part segmented, but there needs to be considerations about payload sizes. I have left websites because they have been too bloated, too spammy or they take too long to load.

As we move to more and more interactive websites built with JS, there will be a point where optimisation will become a necessity.

I’ve recently started optimising a website, stripped out all unnecessary JS and optimised existing, removed duplicate CSS and thinned out the DOM, and page load times have dropped significantly and Time To Interactive have gone from >2s to ~150ms, which should help lower bounce rates and increase revenue

@react-guy nope.

Fewer servers or lower costs isn't interesting at all.

At least I never had it this easy in nearly >10 years.

It's almost always more like a battle of provocation, insanity and dumb number fuckery.

We need developer time for refactoring...
NO.
Server performance will decrease Till possible crash... (Another Excel file)

How much would hardware cost?
Shortterm solution, the server performance will still decrease, the downtime costs much more and the necessary time for refactoring will increase (Another excel file)

But WE cannot loose, customers need more features bla bla bla.
WE will loose customers when the server performance and stability leads to customers not being satisfied. (Powerpoint folio)

Maybe WE can spare 5 % of developer time, but this is really all WE can manage.
Another Excel file, calculated number of hours vs resource increase vs possible gain.

YOU are far too greedy, what's the worst what can happen?
Possible calculation of scenarios based on the current situation, dead locks and resource usage.

Still... This is only one possibility... Maybe WE can find time after WE landed all the current features...

...

This can go on for weeks.

Seriously. Weeks.

@IntrusionCM I know! Right?

Now try to convince the same idiot that you are going to do that for the server AND the front end.

99% of the time, after a long fight, you'll get "okay for the backend part, and maybe (which means never) we'll invest time in front end when everything is done"

Also, it's easier hide stuff not done in backend than frontend. Ask a frontend how many request for small changes he get per week. Now compare with a backend... It speaks for itself.

Things can look done in backend. By experience, it never feels done in frontend.