1. 23

We are going to build native apps because it turns out, it’s cheaper. It’s cheaper to build multiple proprietary applications than one responsive web app.

  1.  

  2. 8

    We fix a layout bug on Safari and break something on Edge. We change font size on Chrome and now all you can see on Firefox is the letter F.

    What’s very sneaky about web development is all the tight coupling. Your layout code may not look to have tight coupling, but it does. It’s secretly interlaced with conditions.

    if (chrome)
        x = 1
    else if(firefox)
       y = 2
    else if(edge)
        y = x + 3
    else if (android)
         z = sqrt(9)
    

    Of course you can’t see that code because it’s actually hidden within each browser. You just see pure, elegant CSS.

    1. 1

      What’s very sneaky about web development is all the tight coupling. Your layout code may not look to have tight coupling, but it does. It’s secretly interlaced with conditions.

      Of course you can’t see that code because it’s actually hidden within each browser. You just see pure, elegant CSS.

      Could you be a little more specific? I have no idea what you’re referring to. Are you talking about vendor flags like -webkit-, -moz-, -o-, etc?

      1. 2

        The if statement is metaphorical, it’s not defined in code anywhere, but rather by what browser your user has. It’s another way of stating that the implementations of a standard are all different.

        1. 1

          Ah, I see. Isn’t this the same with different terminal implementations, OS’s, target platforms, etc? Is this in some way peculiar to the web?

          Also, the author is obviously exaggerating, most any modern browser displays things consistently, unless you’re doing something much more fancy than layout code.

          1. 1

            If I change the font in my iOS app, it doesn’t change the font in my android app.

            One might hope that changing a font would have a similar effect in all browsers, but this is clearly not true. Every change must be revalidated in every browser. That takes time and effort. Any savings from “single platform” development must be weighed against the cost of multi platform regressions.

    2. 13

      Moral of the Story:

      Stop Pixel pushing.

      If its well defined and standard in Ye Olde XHTML and CSS2. Use it.

      Else ignore all this stupid fancy useless javascripty dynamic crap.

      “There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way — and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.” C. A. R. Hoare

      As a user of web sites…. When I notice the page load lag of pulling in 100s of kb of javascript. I groan inwardly.

      I just know this is going to be slow, flaky, glitchy low on content, high on ad’s, glitter and frustration.

      JavaScript is the <blink> tag of the 2010’s.

      I look forward to the day it’s removed from all browsers.

      1. 9

        I look forward to the day it’s removed from all browsers.

        You’re going to be waiting a long time.

        1. 2

          Let’s dream a little. How might it come to be that JavaScript is removed…

          So let’s think about what JavaScript is useful for…

          • Kludging out the differences in behaviour of the various browsers. Well, that’s obvious. In A Better Future, all browsers are standards compliant.

          • Kludging out usability / feature omissions from the standard. (No decent date picker, no drop down menu support, ….) Ok. The solution to that is obvious as well. The standard needs to be extended to include all the common case usability needs leaving the browser devs free to implement these features decently in native code.

          • Things like https://d3js.org/ Now be honest. D3 is amazing, beautiful lovely…. But have you dug into the bowels of it? Have you seen what kludges it relies on to work? Have you managed to hold on to your lunch as you gazed upon it’s gory innards?

          Let’s face it. I worked with much better, cleaner, nicer plotting API’s back in the mainframe days. You really really really should be able to do things like D3 these days without having to tank up on anti-nausea pills whenever you look at the code.

          So how do we get from “Here” to “There”?

          • W3 org needs to be forked / revitalized and the corporate power grabs killed.
          • asm.js might be a phantasmagorical stepping stone towards something clean…. And then asm.js ripped out once we have it. Although my skin crawled as I wrote that sentence.
          1. 2

            How well do you remember the Schism of 2004 and the formation of WHATWG? How much UX programming have you done? Do you think all programs should be native, controlled by hardware vendor app stores?

            I worked with much better, cleaner, nicer plotting API’s back in the mainframe days.

            What were these APIs called? Where can I read about them? I don’t see those referenced in Bostock’s D3 paper and I wonder why they’re not.

        2. 3

          JavaScript is the <blink> tag of the 2010’s.

          I wouldn’t say that. As long as you’re just setting events, hiding and showing stuff, AJAX to make forms more friendly (but also making sure the button works with JS turned off), whatever, you’re fine. It’s when you buy into a framework that won’t render without JS, and start sticking business logic into the frontend that you kill yourself.

          I’m having a hard time understanding the angst about how much it costs to hire a good frontend developer. You can get a good frontend guy for $70k, if that’s too much for you then you probably have other problems worth addressing.

          1. 2

            Stop Pixel pushing. If its well defined and standard in Ye Olde XHTML and CSS2. Use it.

            I totally agree with this. There’s way too much crap being done on the client side these days. With a few rare exceptions (Google Docs for instance, which is fast and functional), I don’t think any websites should require JavaScript for anything besides cutesy visual effects.

            1. 2

              Google Docs is only fast and functional if you’re not comparing it to a non web-based word processor with more than a handful of large documents open at the same time.