Hacker News new | ask | show | jobs
by m_fayer 3387 days ago
Then again take a step back and look at what's being achieved. You are delivering, nearly instantly, a sophisticated and responsive fat client application to the user without any installation process. This fat client is running in a nearly universal and quite safe sandbox that is provided by several vendors across different os's, form factors, and architectures. With a good amount of backwards compatibility. Backed by a backend that's almost infinitely scalable. And developers are constantly feeding new features into this system without bringing it down or interrupting anything.

From that perspective, you would expect the tooling and stack to be complex. We really are doing way way more than we were in the "old days." "Write once run everywhere" has arrived and we're doing it, it's just not as simple as it sounds.
1 comments
Klathmon 3387 days ago
And to just pile on with this comment, "run everywhere" means much more than it ever did.

This isn't just the big 3 desktop OS's, but laptops, tablets, phones, TV's, game consoles, car navigation units, hell my goddamn watch can run websites now! X86, ARM, SPARC, PPC, it doesn't matter.

And on most of those platforms, you have more than one choice of browser.

It's a level of cross-platform that really only simple C programs can even begin to reach. And it's not exactly simple to setup that environment from scratch either.

link
laumars 3387 days ago
Except it is simple:

    <html>
        <head>
            <title>Hello World</title>
        </head>
        <body>
            Hello World
        </body>
    </html>
It's responsive, works on every HTML-compatible platform and is even backwards compatible to a degree that none of the other aforementioned solutions even comes close.

We make it more complicated for ourselves because we choose to make it more complicated. I'm not against modern frameworks but quite often I see people justifying them rather than using them when they become a requirement.

Worse yet, I'm often disappointed by the number of web developers I've worked along side recently that haven't understood how data is serialised in HTTP response and request headers (so they inappropriately use GET and POST methods), don't know even the basic few HTTP status codes, don't understand browser caching, etc and I end up having to handhold them through the basics while they're advocating complex frontend frameworks because "it does the logic for you" (or similar arguments).

This isn't a dig at all web developers by any means. I'm talking about a minority here. But it's a trend I've observed growing and I do think there is a correlation between the rise in popularity of bloated abstractions and the number of inexperienced developers using them as a crutch for their lack of understanding about the core principles of the web. The problem is the moment something misbehaves they're completely incapable of effectively problem solving it. And in the era of everything being a web browser, we have more low end devices than ever that we need to support - which often gets neglected when you have developers constantly opting for their shiny new toys resulting in cumulative page sizes of megabytes just to display "Hello World!".

So going back to my original point; yes I do think it can be simple to set up the kind of cross platform support you describe. I think it's often us who choose to make it complicated for ourselves. Often far more complicated than it ever needs to be.

link
seanp2k2 3387 days ago
+1 on developers not knowing how HTTP works. I'd add to that with server-side devs (the ones writing the APIs that the single-page apps talk to) not knowing how CGI works. You can literally learn both in an afternoon if you have reasonable networking and OS-level knowledge that I'd expect anyone with a CS major to have down cold. Sadly, well, you know.

In my experience, devs knowing how it really works are the small minority. Most of them seem to know "I put /foo in my Rails router, run `rails s`, hit 127.0.0.1:3000/foo in my browser, and it does the good stuff", which is consequently enough to get by in many development positions at many places.

link
laumars 3387 days ago
CGI isn't really something I'd expect many people to be using these days though. These days language web frameworks fire off their own web server and the few exception usually bypass CGI (eg PHP has a mod_php C++ API that hooks directly into Apache bypassing CGI).

Sure you can still run Perl, Python or even Go via CGI on Apache, or PHP using FastCGI on nginx, but the difference in performance between even FastCGI and a language-native web server isn't negligible. So there isn't really much reason to recommend people using CGI barring niche use cases where, hopefully, the sysadmin / devops as purposely chosen CGI acknowledging it's pitfalls (not just in terms of performance but also security) and thus understanding how it works.

This is one of the few areas where I think the additional complexity in modern frameworks is a real benefit.

link
ezequiel-garzon 3387 days ago
Don't forget my proprietary pet peeve for proper mobile rendition: <meta name="viewport" content="width=device-width, initial-scale=1">. Don't get me started :)
link