Why browsers are bloated

https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/Scrollbar.cpp
https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/win/ScrollbarThemeWin.cpp
Let's reinvent the fucking scrollbar, which every goddamn platform with a UI already has, and make it behave subtly different from the native one!

Right-click a native scrollbar in some other app:
- Scroll Here
- Top
- Bottom
- Page Up
- Page Down
- Scroll Up
- Scroll Down

Right-click a scrollbar in Chrome:
- Back
- Forward
- Reload
- Save As...
...

Right-click a scrollbar in Firefox and Opera:
Absolutely fucking nothing happens!

What the fuck!? How did these terminally retarded idiots get involved in creating one of the most important pieces of software to the average user?

Here's a retrospective from the TermKit guy about the project:

http://www.reddit.com/r/programming/comments/137kd9/18_months_ago_termkit_a_nextgeneration_terminal/

It also underestimated just how much of the Unix world is built upon the standard in/standard out paradigm (which it rejected), which is kind of ridiculous in an asynchronous, networked world. With deeper research, it was revealed how Unix magic like nested remote subshells and remote privilege escalation works only by accident, because the programs in between are too dumb to mess it up, not because of anything deliberate.

I'm not sure if he actually learned the lesson that "too dumb to mess up" is a good way to design things.

>>161

which is kind of ridiculous in an asynchronous, networked world.

Is it?

>>161

reddit

Shalom, Hymie!

They're the same people who reduce Apple products to the specs on the side of the box, and never bothered to notice that the reason MacBooks dominate geek conferences is because they have features that actually make life easier, like say, reconnecting to wifi in under a second when resuming from sleep.

Or maybe they're just clueless pseudoprogramming "web designer" hipsters worshipping the Apple cult?

>>164
What about this guy? http://twitter.com/jonsterling

>>164
Or maybe they're people who are more interesting in getting shit done than wanking off to an extra tenth of a percentage boost from tweaking their CFLAGS for the twentieth time.

>>166
That's Windows

>>167
What's Windows?

>>167
An annoying percentage of Windows software is released as debug builds. VS compiles debug executables with slightly different parameters, leading to differences in the execution of release builds. If the programmers weren't shit, that would not be an issue and they would never expose the undefined behavior that would cause such differences to show, but alas, they are shit. And when release builds fail they instead just ship the debug builds.

>>169
The idea of ever having a separate "debug build" is stupid, precisely for that reason. (This is different from a debug-version which may contain extra logging etc.)

>>161,164
When the first paragraph already contains crap like "best development practices had not been established" you know you're reading the thoughts of a poser or - at best - a mindless sheeple (sheepson?) who wants to "innovate" in the worst possible way. It's like he's lamenting the lack of a religion, because he wants to follow one.

Today, this means you still have to abort SSH sessions by typing magic sequences (return, tilde, period) rather than using out of band signalling

That just means your SSH software is bad (and you should feel bad about it...?)

catting binary files into your terminal can mess it up permanently

Have done this many, many times, and never had to buy a new terminal, so "permanently" is gross exaggeration. (I bet he doesn't even know there's a "reset" command...!)

melding modern interaction design with the technological underpinnings that can support them

What the bloody hell is this even supposed to mean? "Turn everything into a web app"?

the reason MacBooks dominate geek conferences is because they have features that actually make life easier, like say, reconnecting to wifi in under a second when resuming from sleep

Go to a real "geek conference" (i.e. a demoparty) and you won't see many Macs at all. Maybe a few Apple IIs. Even the C64s and ZXs are going to outnumber them. And "make life easier"? Maybe it's easier if all you do is obey what Apple wants you to do... like buying a whole new machine whenever a new one comes out or when something that should be trivially replaceable like a battery wears out because it's "more convenient" and you don't know how to use something as simple as a screwdriver... "We know better than you. Trust our word for it and keep buying our products, consuming, and making more bloated software so we can sell you more of our products!" What a load of bullshit.

Combine that with the first paragraph above, and "hipsters worshipping the Apple cult" sounds about right!

I just don't know anymore... Shit going down on Syria, World's economy still stagnant, the kikes yet live, and in my retreat to my only place of confort I can't even find solace online. Firefox is going down hill, half of the websites I visit give me some Apache Mod error, other websites like Motherless reject my user agent, there are no decent browser alternatives. I just want to browse the web, I just want to be able to use links2 in Windows as well and not be tied down by retarded design majors and their inconsistent shit online.

>>171

motherless
windows

kill yourself you disgusting freak

>>172
I-I need to use windows at work

>>169,170
I don't understand why anyone would ever want to have separate debug builds for a general purpose program. Just strip symbols from end users' packages and make diagnostic features dynamically selectable and you eliminate the whole set of bugs that arise from differing build configurations.

>>174
Or just avoid undefined behavior that differs.

>>175
Even with good coding practices, mistakes will slip through from time to time. It's easy to say, "Don't shoot yourself in the foot" but it's better to just not point the gun there in the first place. You're always going to have to try to reproduce issues that appear in a production build on a debug build anyway, if the two are distinct - if they're not, it's just one less thing you need to worry about.

>>176
Even with good programming* practices

>>176-177
Even with good apping* practices

Just know, >>177, you deserve >>178

>>176
If you can't deal with the minute differences between debug and release builds, then your shitty code is broken. And you've locked it into a single compiler, because it is too fragile to switch to another.

Crashes are good. It is the computer's way to warn you that the programmer was an idiot.

>>180
You're missing the part where not having multiple build types... means not having to deal with multiple build types. If all your builds have diagnostic features that can be enabled if necessary, you never have to tell users that are seeing a bug you can't reproduce to please install a debug build just to get some logs. If all builds have logging you just tell them to enable it and get on with solving the real problem.

Diverse compilation is good, but a good static analyzer is a better tool for catching the sorts of bugs an optimizer is likely to break. If you just build with a bunch of different compilers, you have no way to reliably ensure that at least one compiler will be aggressive enough to break the code that's bad.

other websites like Motherless reject my user agent

just fake it

http://limpet.net/mbrubeck/2014/09/17/toy-layout-engine-6-block.html

I wonder how big his binary is.

>>183
size queen.

Random idea time... configurable relayout/repaint intervals.

Those pages full of blingy animated shit are horrible for power consumption because the browser is forced to constantly relayout/repaint stuff. There's even whole JS libraries to batch DOM updates to avoid this for the stupid apps that can't do it right themselves...

How about the browser itself throttling things - you don't need to compute and repaint as fast as the scripts are trying to make the browser do, and since up to ~100ms is not so noticeable, by default script-driven repaint intervals could be limited to one every 100ms. Those wanking "web designers" aren't going to like this since it makes animations look jerky, but who gives a shit... that's why this should be configurable - if you really, really want to play some inane JS game or something else that needs ultra-fast repaints, then you can turn it up (and see that your power consumption goes up, and battery life goes down as a result.)

Ditto for "smooth scrolling" (one of the worst ideas ever conceived) - unless I'm grabbing a scrollbar and dragging it, I'm not scrolling one pixel at a time, so why the fuck do they think I want to see the window repainted every time it scrolls 1 goddamn pixel!? If I'm scrolling by 10 pixels then just move the existing content by 10 pixels and repaint that 10-pixel gap. What a ridiculous waste of (GPU mostly) power.

(I could rant on and on about the idiotic trend of making UI elements behave like physical objects - with the exception of "inertial scrolling" which is genuinely useful on a touchscreen but only without that annoying "bounce-back" or "friction" - but that's not so browser-related....)

>>185

configurable relayout/repaint intervals.
Ditto for "smooth scrolling" (one of the worst ideas ever conceived)

I love you so much, Cudder-sama. You always bring logic to our irrational world.

I've used a trackball with inertial scrolling and I think it's an amazing mechanic that should be implemented in normal mouse wheels as well, but at the moment it's not very configurable and I don't like the sharp acceleration curve. Can this be done with software alone?

No Material Design for Cudder, so are you going to use iOS or Windows for mobile?

>>185
Something like this already happens for inactive tabs. Sorry to burst your bubble.

>>188
Where can I tweak this parameter? Please expand on this, I'm interested.

>>185
Why is it called smooth scrolling when it makes the scrolling laggy and jerky?

>>186
You might like greasymouse, available in the contrib directory of x.org's ftp server.

>>186
The whole idea of inertial scrolling is that you sense when the user takes the finger off the screen/touchpad and then continue scrolling at the same velocity; how do you propose that be done with a mouse wheel?

>>187
Android, but I'd rather not use a mobile device if I don't need to.

>>188
Inactive tabs (or minimised windows for that matter) shouldn't need any repainting.

>>190
It's "smooth" if you have enough GPU/CPU power to waste moving the existing contents and drawing each new line of pixels separately, but it still feels laggy because you're forced to scroll only as fast as the machine can keep up. There's no snappy ultra-responsive multi-pixel jumps when you scroll (which the "UX designers" seem to abhor...)

>>191
You can ``flick'' a mouse wheel same as a touchscreen.

>>192
Some mice have smooth wheels and it might make sense for them. Most use clicky wheels and it makes no sense because X clicks should result in 5X (or whatever the constant is for your setup) lines scrolled.

your cock is in it

>>193
It depends on how fast your X number of clicks are input.

>>127
I agree, that shit is terrible.

However,

visit the page
open javascript console
var img = document.createElement("img");
img.src = "http://i59.tinypic.com/uliti.png";
document.body.appendChild(img);

then scroll down

>>130
It redirects to some shitty html page.

>>147

ribald strcat

>>196
If you don't want to use JS, this also works:

wget -U 'Mozilla/5.0' --referer='http://anus/get.html' http://i59.tinypic.com/uliti.png

Note: The redirect happens if you're using the HTTPS version of progrider. Since HTTPS strips referrer.

If there's no referrer, tinypic redirects to their shitty html/js piece of shit page.

>>198
$ nc i59.tinypic.com 80
GET /uliti.png HTTP/1.0
Host: i59.tinypic.com

臼NG
(bunch of binary data here)
$

>>199
$ nc example.com 80
GET /doubles HTTP/1.0
Host: example.com
X-Dubs: checkem
User-Agent: netcat

HTTP/1.0 200 CHECKED
Content-Type: text/doubles

<html>
<body>
<h1>nice dubs!</1>
</body>
</html>