Why the web sucks


  • area_can

    A while ago I posted a link to someone complaining about web browsers being slow, while their own huge bloated-ass site took forever to load because of megs of JavaScript.

    Here's a summary of things like that: http://developer.telerik.com/featured/whats-wrong-with-the-web/



  • You destroy basic usability by hijacking the scrollbar. You take native functionality (scrolling, selection, links, loading) that is fast and efficient and you rewrite it with ‘cutting edge’ javascript toolkits and frameworks so that it is slow and buggy and broken.

    It would have been in a quote if I could get that to work with either the " button or the Ipad keyboard, but I can't, so there it is.

    Also I remember having this conversation before.


  • Discourse touched me in a no-no place

    Sounds like Dickhorse, especially on the short bus mobile devices...



  • I knew I liked telerik. They actually know what the problem is. They're Infragistics' main competitor, and they have demos that work.



  • I posted this or a similar article in Quick Links.

    Agreed. Except:

    Perhaps, as she says, web development has just become a career opportunity – a paycheck. But maybe therein lies a solution to the malaise that is affecting the community. Maybe, the solution to the problems plaguing the web is to focus on what we want to build again – rather than how we are building it. Most of the debate has centered on how we build things – use a framework; don’t use a framework; use new APIs; there’s too many APIs. What if the problem lies in the fact that we aren’t building things we love?

    Call me a naive idealist if you want, but maybe if we get back to building fun and exciting things again, the rest will solve itself.

    You're a naive idealist.

    Web developers aren't any more or less paycheck driven than mobile devs.

    The problem is money. How do you monetize your thing.

    App can put a nice icon in an app store, and people are willing to tap on it and pay. Websites put up a paywall and no one's buying it. They just install add blockers or read from google cache.

    Solve that problem and you'll save the web.



  • @cartman82 said:

    The problem is money.

    And laziness (or time effiency) . Framework layer cake comes from wanting to avoid doing (hard) work.



  • @swayde said:

    And laziness (or time effiency) . Framework layer cake comes from wanting to avoid doing (hard) work.

    Yeah, that too.

    Frameworks give you efficiency at the cost of flexibility. Sometimes that's a valid tradeoff, but keep in mind that it IS a tradeoff. You just need to pick the right tool for the right job.

    Admin panel = perfect for angular or ember
    User facing site = you're better off being able to mess around with DOM elements, without bindings getting in your way



  • @Magus said:

    I knew I liked telerik. They actually know what the problem is. They're Infragistics' main competitor, and they have demos that work.

    I had the displeasure of having to work with both. The biggest reason Telerik's web stuff has improved to usable levels, is they rode on jQuery and jQuery UI's coattails. Yet like all RAD tool- and widget-suites they still heavily favor configuration over composition, which still means it's 'their way or the high-way' and any attempt at building something outside of the box will result in uphill battles.



  • @cartman82 said:

    Admin panel = perfect for angular or ember
    User facing site = you're better off being able to mess around with DOM elements, without bindings getting in your way

    Or you do both; MVVM-style bindings where applicable, hard-tied DOM manipulations from explicit mediator or controller classes where applicable. I'm using CanJS as an application framework on top of jQuery, which is really not too bad a way of doing both. (It also doesn't fall into the trap of using prohibitively expensive dirty-checking as a means to implement observable data models, like Angular does...)


  • I survived the hour long Uno hand

    @Ragnax said:

    Yet like all RAD tool- and widget-suites they still heavily favor configuration over composition, which still means it's 'their way or the high-way' and any attempt at building something outside of the box will result in uphill battles.

    I've used their UI for WPF and for the most part it is easy to work with. As long as you use static UI layouts, doing most of your design work beforehand in XAML, things work well. However, that isn't practical for the applications I work on. I don't know how many times I have had to search for "Do this thing programmatically" to recreate their examples in C#. That's not to say that you can't do anything you want, it's just that you normally have to put a lot of extra effort into it, which defeats the whole purpose. At least I don't have to use Reporting anymore, that was much worse.


  • Discourse touched me in a no-no place

    @bb36e said:

    http://developer.telerik.com/featured/whats-wrong-with-the-web/

    • web pages with actual content that takes up only 20% of the screen width.

  • FoxDev

    Responsive web design..... lol wut dat?



  • @accalia said:

    Responsive web design

    Remember the Good Old DaysTM, when 33k modems were new and we could afford to leave a web page that took more than five minutes to load, and when there was no JavaScript that took another ten minutes to load additional contents and then another five to render all that shitstuff?

    Btw, believe it or not, there are websites that don't need Discourse to be slower than a slug on barbiturates.


  • FoxDev

    @PWolff said:

    Remember the Good Old DaysTM, when 33k modems were new

    Alas i'm not that old.

    I do remember the days of the 56k modem though.

    @PWolff said:

    Btw, believe it or not, there are websites that don't need Discourse to be slower than a slug on barbiturates.

    i forget, is that faster or slower than molasses rolling uphill on a January morning in Nome, Alaska? because that's the speed of discourse on mobile.



  • @accalia said:

    I do remember the days of the 56k modem though.

    "56k" was a marketing statementTM. Actually, they were 33k modems. It was possible to transmit compressed textual information at a net rate of 56k over 33k lines.

    @accalia said:

    molasses rolling uphill on a January morning in Nome, Alaska

    They must have some impressingly fast molasses over there in Alaska. I'd love to visit a molasses race one day. I mean, on my mobile phone, the TDWTF pages render within 30 minutes.


  • FoxDev

    @PWolff said:

    "56k" was a marketing statementTM. Actually, they were 33k modems. It was possible to transmit compressed textual information at a net rate of 56k over 33k lines.

    nevertheless they were different to standard 33k modems. ;-)

    @PWolff said:

    I mean, on my mobile phone, the TDWTF pages render within 30 minutes.
    lucky bastard. my phone gives up trying after about ten minutes and just says "page cannot be displayed"

    interestingly if discourse is loaded when i'm on wifi and i roam to 3G (4g if i'm lucky) then i can use the site just fine.



  • I remember 9k6. Hell, I even used an asynchronous 1200 / 300 connected to a Prime 500 using a 20" Tektronix 4010 / 4016 graphics head to do Technical drawing / CADCAM


  • ♿ (Parody)

    @PJH said:

    web pages with actual content that takes up only 20% of the screen width.

    I think you're doing it wrong. Of course, you think I'm doing it wrong.



  • @PWolff said:

    "56k" was a marketing statementTM. Actually, they were 33k modems. It was possible to transmit compressed textual information at a net rate of 56k over 33k lines.

    Not true. 33.6k modems used V.34; 56k modems used V.90 and later V.92.

    There was indeed some on-the-fly gzip-like compression used in conjunction with both these standards (V.42bis and V.44) and in fact V.44 was built into every V.92 modem I'm aware of. Just like gzip, this made scarcely any difference to already-compressed data like jpegs. However, a V.92 modem absolutely could download a jpeg at a genuine 56kb/s given a good line, while a V.34 modem operating over the same copper would only get it to you at 33.6kb/s.

    The fundamental difference between V.34 and V.90 was that with V.34, the equipment in the exchange didn't do anything special with modem signals - it just treated them like any other phone-derived audio, using a general purpose PCM codec (G711a or u) to convert them back and forth between customer-side audio and network-side 64kb/s digital. No time synchronization was required between the PCM sampler in the exchange and the customer's modem.

    With V.90, your modem would actually negotiate with a counterpart in your local exchange to transfer a coded self-clocking digital signal over the wire. This digital synchronization allowed for more efficient use of the raw 64kb/s that the phone networks used internally.



  • @flabdablet said:

    However, a V.92 modem absolutely could download a jpeg at a genuine 56kb/s given a good line

    In the US, they were limited to 53kb/s download due to FCC regulations. ISP to customer traffic was digital as you mentioned, but customer to ISP was analog and limited to 33kb/s.



  • YLSNED. (Unless I knew before but had forgotten. All so terribly long ago.)

    But weren't the 64 Kib/s only on a digital line? An analogue line had a bandwith of about 3 kHz (ca. 300 Hz to ca. 3300 Hz) - at least where I live. But you could transmit as many different states as you could reliably distinguish on the other side.

    Anyway, it seems that the difference between 33k and 56k was in the firmware / protocol only, not in the hardware. (Of course that's more than a mere difference in name.)



  • @loose said:

    I remember 9k6

    I have a 300 bits/s Telstra modem sitting in my back shed. It's a big steel box about the size and weight of two house bricks. I was very pleased to acquire it, because it was far less subject to random dropouts than the acoustic coupler I previously had to use to connect to the computer club BBS.

    I once worked for an outfit that made a DMA-driven hard drive for the Apple II. We were really proud of the speed of that thing, which completely blew away all its contemporary competition. Using a hard drive sector interleave pattern optimized for FastDOS or ProDOS, we could read files into Apple II RAM at a smidgen over 90 KiB/s. One of our demos was a full-screen hi-res page-flipped animation at a little over 10fps, which was just outrageous at the time.

    The fact that I can now achieve download rates over 20 times as fast as that, over the very same telco copper that barely used to sustain a 30 bytes per second acoustic coupler connection, occasionally boggles my slow old mind.



  • @PWolff said:

    weren't the 64 Kib/s only on a digital line?

    Yes, which is what the telco networks were using internally by then to ship your phone conversations around.



  • @PWolff said:

    But weren't the 64 Kib/s only on a digital line? An analogue line had a bandwith of about 3 kHz (ca. 300 Hz to ca. 3300 Hz) - at least where I live. But you could transmit as many different states as you could reliably distinguish on the other side.

    V.92 was a protocol to detect when there was compatible hardware on the other end of the wire you were connected to and switch to digital. It was kind of like on-demand ISDN.


  • Grade A Premium Asshole

    @flabdablet said:

    I have a 300 bits/s Telstra modem sitting in my back shed. It's a big steel box about the size and weight of two house bricks. I was very pleased to acquire it, because it was far less subject to random dropouts than the acoustic coupler I previously had to use to connect to the computer club BBS.

    I once worked for an outfit that made a DMA-driven hard drive for the Apple II. We were really proud of the speed of that thing, which completely blew away all its contemporary competition. Using a hard drive sector interleave pattern optimized for FastDOS or ProDOS, we could read files into Apple II RAM at a smidgen over 90 KiB/s. One of our demos was a full-screen hi-res page-flipped animation at a little over 10fps, which was just outrageous at the time.

    You have a walker, don't you? Or perhaps a Hoveround?


  • area_pol

    @Polygeekery said:

    You have a walker, don't you? Or perhaps a Hoveround?

    That is not the best idea, as shown here https://what.thedailywtf.com/t/elevator-door-open-button/50458/26



  • @Jaime said:

    switch to digital

    It's digital, Jim, but not as we know it, not as we know it, not as we know it. It's digital, Jim, but not as we know it. Not as we know it, Captain.

    V.90 and V.92 use the same downstream format. At the lowest level it's pulse amplitude modulation: when sampled mid-symbol, the line will be at one of the 255 voltage levels (127 negative levels, 0 and 127 positive levels) that can come out of the analog side of a G711 DAC. The initial training sequence lets both ends figure out where the receive-side voltage boundaries are between transmitted symbol voltages, helping get rid of the quantization noise that limits a V.34 link over the same copper to about half the available raw G711 data rate. The symbol rate is fixed at a G711-compatible 8000 symbols/s.

    If you were to allow completely arbitrary symbol sequences and you had a perfect transmission line, you could transmit log2(255) × 8000 = 63954.8 bits per second this way. But the available cross-pair interference requirements and noise floor don't allow for completely arbitrary sequences, and you also need a discernibly periodic component in the encoded output to recover a sampling clock from, so V.90 defines a bunch of cunning DSP that happens between raw data-side bits and what ultimately gets fed to the DAC. All of it happens at the DAC's symbol rate (8kHz) and the net result is to limit the available bit rate to 56k under ideal conditions. Under less than ideal conditions as revealed during training-up, various DSP parameters get tweaked to reduce the required bandwidth and susceptibility to corruption by noise, and this also reduces the number of input bits encoded by each chunk of outgoing symbols.

    The receiver also needs to do a shitload of clever DSP (at rather more than 8kHz!) to compensate for cable artifacts like echo and phase shift before the received signal is anywhere clean enough to recover original symbols from via level sampling.

    The difference between V.90 and V.92 is that V.90 uses the same modulation scheme for upstream data transfer as V.34 does, while V.92 can use a similar scheme to the downstream one. It will fall back to V.34 upstream if echoes from the digital modulation scheme screw up the available downstream rate too much.

    @Jaime said:

    It was kind of like on-demand ISDN.

    Not really. ISDN's signal format is much simpler, using only three (Europe) or four (US) voltage levels, and its bit rate is higher. ISDN pairs don't share cables with analog pairs, so they can get away with generating more inter-pair interference; ISDN's vastly more robust quantization compared to G711 means that an ISDN pair can easily tolerate interference that would be annoyingly audible on a voice pair.



  • @flabdablet said:

    Not really

    Hence the phrase "kind of". I should have said baseband instead of digital, because that's a more accurate description.



  • @Polygeekery said:

    You have a walker, don't you? Or perhaps a Hoveround?

    https://www.youtube.com/watch?v=zy5rkw4SeP4


  • Grade A Premium Asshole

    I thought of the same thing when I said that.



  • @Jaime said:

    baseband instead of digital, because that's a more accurate description.

    Yep. A weird kind of baseband heavily constrained by the need to play nice alongside POTS audio.

    I dips me lid to whoever first thought of playing nice alongside POTS audio by just dealing with the insane degree of attenuation, interference and distortion you get from feeding RF over phone-grade multi-pair cables. xDSL really is an outstanding engineering achievement.



  • @PJH said:

    web pages with actual content that takes up only 20% of the screen widthcares about optimal line length for reading..

    FTFY

    The real question is why you'd think that to be a bad thing...


  • Discourse touched me in a no-no place

    @Ragnax said:

    FTFY

    No, you actually didn't.

    Just because your optimal line length for reading appears to be about 4 words of one syllable or less, it doesn't mean it's everyone else's, and they must suffer because of it.


  • area_can

    But is
    it
    resp-
    ons-
    ive?



  • @PJH said:

    Just because your optimal line length for reading appears to be about 4 words of one syllable or less, it doesn't mean it's everyone else's, and they must suffer because of it.

    I really don't see how the hell people prefer moving their eyes back-and-forth across the page for each line instead of just moving them down the page and having everything in their field of vision.

    Unless you have exotropia, I guess.


  • Discourse touched me in a no-no place

    @Maciejasjmj said:

    I really don't see how the hell people prefer moving their eyes back-and-forth across the page for each line instead of just moving them down the page and having everything in their field of vision.

    I really don't see how the hell people prefer moving their eyes up and down the page as they have to scroll every 20 lines they read on a desktop monitor.....

    I speed read, and this sort of "responsive design" hinders that ability since my eyes are quite capable of hitting the left hand side of the screen where they need to be when the page doesn't have to move, while scrolling the screen involves lost time while searching to find out where I left off, since that point can be typically anywhere between 10% down the page to 10% off the top of the page (the latter necessitating scrolling back up, normally because there's a banner at the top that hasn't been taken account of somewhere.)

    Having to scroll the screen every 250 words (from a random sample of that page at 100% zoom on my monitor) is slower to me than having to scroll every 1000-1500 words (similar sample after hacking at the CSS and resizing to a more sensible-to-me font-size.)


  • area_can

    It's annoying when I'm looking at an 1800-pixel wide line of text on my monitor because I keep losing track of where I am. I prefer moving my eyes down the page for each paragraph over moving my eyes back and forth over the entire monitor 😁


  • Discourse touched me in a no-no place

    @PJH said:

    web pages with actual content that takes up only 20% of the screen width.

    You wait until you see that combined with multi-column websites: three or four columns all squeezed into the central 20% and the rest just left blank.



  • @loose said:

    I remember 9k6. Hell, I even used an asynchronous 1200 / 300 connected to a Prime 500 using a 20" Tektronix 4010 / 4016 graphics head to do Technical drawing / CADCAM

    300/300 baud. I WIN CRAPPY MODEM CONTEST or whatever.



  • Have you thought about... making the window narrower?

    #Doctor Science To The Rescue!



  • @blakeyrat said:

    300/300 baud. I WIN CRAPPY MODEM CONTEST or whatever.

    I recall hearing stories about a modem of that vintage still being in service somewhere in one of our datacenters...

    Filed under: it works, why replace it?


  • Grade A Premium Asshole

    @tarunik said:

    Filed under: it works, why replace it?

    Because anything that it will attach to should have also been replaced over a decade ago?



  • @bb36e said:

    I prefer moving my eyes down the page for each paragraph over moving my eyes back and forth over the entire monitor 😁

    That's because you and I, along with 99.99% of the gross human population, are average normal humans with average normal brains capable of average normal spatial relational mapping and average normal eyes capable of average normal eye scanning. Thus we prefer a 75 to 80 character line limit that has been widely proven via usability testing as optimal for the average normal human at the average font-size for normal reading.

    Sadly we can't all be part of the 0.01% of super-human outliers like PJH...



  • @Polygeekery said:

    Because anything that it will attach to should have also been replaced over a decade ago?

    Chuckles We still have relay and even mechanical interlocking in places on the RR...



  • Well you are clearly 1337er than us. You win the absolutely nothing that was at stake, congratulations.


  • Discourse touched me in a no-no place

    @tarunik said:

    Chuckles We still have relay and even mechanical interlocking in places on the RR...

    At least, when they remember to lock the switch junctions, right?


  • area_can

    Is that like a 56k modem? We used to have a 60kbps connection a while ago, man that was slow.

    man, that pic must be from like the 70s or something


  • Discourse touched me in a no-no place

    @bb36e said:

    Is that like a 56k modem?

    I remember upgrading to that from my old 28.8k, which was itself a big step up from the 9600 I started with. All of which would have been great, except I'd encountered what 10base2 ethernet could do before that; I knew that the world could be better. And getting cable internet was a glorious day.

    Though going from pay-per-second to always-on was a bigger change in how things were actually used.


Log in to reply