While I’m not a fan of tracking, the bloated bit of pages was that it loads megabytes of transpiled javascript. Trackers / ads can be done in less code and asynchronously to make for a less bloated web experience where we all “win”.
I’d call a less bloated Internet a win. Did we win everything? Certainly not, but I don’t believe any of us believe there will ever be a singular motion to absolve all of our qualms with the Internet in one fell swoop.
Unless if I’m mistaken, the article we’re replying to is against a bloated Internet in favor of a more slimmed down version where we aren’t downloading megabytes of data to read a blog.
Now with that in mind, this thread was about how we cannot attain this from the perspective of running ads / tracking software. So my proposal is that megabytes of JavaScript is not needed to serve ads / track users, which brings us closer to the win of “a less bloated Internet” where a pivot to handle the finances of websites through ads / user data is not needed.
I’m not advocating here that ads or tracking is good, but rather it’s something many sites are using and the current state of the web makes those sites bloated, which this article is wanting to encourage the reduction of. So if we could have those companies provide less bloated scripts, this would be a win for “a less bloated Internet” (and not “a no tracking / ads Internet” that it appears you and ben are considering to be the only way to win here).
The current state of the Internet is you either lose money hosting a site, you have some paywall / sell content on the site, or you run ads on it to fund the site. So if you want to not charge your users but still find a way to keep the website online, you’re probably using ads (e.g. most of the Internet). What I’m saying is that the path of least resistance to making the Internet faster is to remove the bloat from ads, not to tell everyone to just bleed cash for their sites on principle by removing ads from their sites.
If your opinion is that a faster Internet is not a win in any way, shape, or form; I think we’re at an impasse.
I don’t want remote execution of untrusted code on my machine either that spies and/or tracks me. However, that has nothing/little to do with making the Internet less bloated, which is what I was originally discussing in terms of wins/loss.
By remote execution I thought you were referring to remote code execution the security vulnerability, not JavaScript as a whole.
In any case, my argument is that if people stopped transpiling / browserifying client-side projects and just wrote what was needed we wouldn’t be pushing down megabytes of JavaScript down the pipeline, and if this was done it’d be a win for the Internet as it’d be faster / less bloated.
This is not always the case, some companies (mine included) work to making things that work well at the cost of being a bit more premium than the cheaper alternatives and business is still running good for us.
too real… but try explaining that to the marketing departments…
“what do you mean we can’t track our customers’ every move?”
While I’m not a fan of tracking, the bloated bit of pages was that it loads megabytes of transpiled javascript. Trackers / ads can be done in less code and asynchronously to make for a less bloated web experience where we all “win”.
heh i wouldn’t call that a “win” but yes there are many better ways to do it.
I’d call a less bloated Internet a win. Did we win everything? Certainly not, but I don’t believe any of us believe there will ever be a singular motion to absolve all of our qualms with the Internet in one fell swoop.
A less bloated spying apparatus is still a spying apparatus. Just one that hides itself better.
That’s not a win in any fashion.
Unless if I’m mistaken, the article we’re replying to is against a bloated Internet in favor of a more slimmed down version where we aren’t downloading megabytes of data to read a blog.
Now with that in mind, this thread was about how we cannot attain this from the perspective of running ads / tracking software. So my proposal is that megabytes of JavaScript is not needed to serve ads / track users, which brings us closer to the win of “a less bloated Internet” where a pivot to handle the finances of websites through ads / user data is not needed.
I’m not advocating here that ads or tracking is good, but rather it’s something many sites are using and the current state of the web makes those sites bloated, which this article is wanting to encourage the reduction of. So if we could have those companies provide less bloated scripts, this would be a win for “a less bloated Internet” (and not “a no tracking / ads Internet” that it appears you and ben are considering to be the only way to win here).
Better, and more efficient spying on people isn’t a “win” in any way, shape, or form.
The current state of the Internet is you either lose money hosting a site, you have some paywall / sell content on the site, or you run ads on it to fund the site. So if you want to not charge your users but still find a way to keep the website online, you’re probably using ads (e.g. most of the Internet). What I’m saying is that the path of least resistance to making the Internet faster is to remove the bloat from ads, not to tell everyone to just bleed cash for their sites on principle by removing ads from their sites.
If your opinion is that a faster Internet is not a win in any way, shape, or form; I think we’re at an impasse.
You can run ads, without javascript, and without bloat, have a faster internet, and not spy on your users.
Sure, but not all ad companies adhere to that standard of running without javascript/bloat, which is what I was proposing.
Sadly, almost none do. And that’s the problem.
I don’t mind ads. I mind remote execution of untrusted code on my machine, that spies on me and tracks me.
I don’t want remote execution of untrusted code on my machine either that spies and/or tracks me. However, that has nothing/little to do with making the Internet less bloated, which is what I was originally discussing in terms of wins/loss.
Um, not sending 30MB of client-side executable scripts has everything to do with a bloated internet.
By remote execution I thought you were referring to remote code execution the security vulnerability, not JavaScript as a whole.
In any case, my argument is that if people stopped transpiling / browserifying client-side projects and just wrote what was needed we wouldn’t be pushing down megabytes of JavaScript down the pipeline, and if this was done it’d be a win for the Internet as it’d be faster / less bloated.
Now everything you wrote here, I can agree with :)
people get paid to do something “that works” as fast and as cheap as possible, not “something that works well”
This is not always the case, some companies (mine included) work to making things that work well at the cost of being a bit more premium than the cheaper alternatives and business is still running good for us.
I gave up on that.
also holy shit jira is 30mb to load a page
“if it works for us, it must be working for everyone, right?”
i’m not sure if they cache stuff properly, but it sure doesn’t load quickly!
jira is a notoriously bloated system…
“Jira is a great tool like a Finochietto retractor is a great tool. You just don’t ever want to have it used on you.”
… from: https://twitter.com/bitfield/status/723869664829284354