3 ms·

I agree completely. My first thought after reading this article was that while 99% of users may not view the source of a page, the 1% (web devs) that actually c

I agree completely. My first thought after reading this article was that while 99% of users may not view the source of a page, the 1% (web devs) that actually create additional pages find View Source, Firebug, etc. extremely useful. When I'm helping any new web developer out one of my first steps is to have them use and understand Firebug. Preaching to the choir here, but it cannot be understated how important access to and readability of source code was to me when I first began. Compiling and delivering in an unreadable format is possibly the worst solution to this problem. Who ends up benefiting from this? The end user who saves a minuscule amount of time loading the page? Is hampering innovation and progress really worth that amount of time? Below, the author makes a point that viewing the actual source is unreadable anyways. Very true, but tools like Firebug and Chrome Developer Tools help combat that problem to an extent by nicely formatting HTML, CSS, JS, etc. And while many large sites (Gmail, etc.) have compact and utterly horrendous source, I would argue that novice developers are not looking there first for help, instead they look at less complex sites that are not minified (because they don't need to increase page loading speed).

kls 15y ago
I would argue a lot of what was called "mash-ups" a few years ago, came about because people could view the underpinnings. Long before companies started documenting official API's developers where pulling apart their code and adding and mixing and matching features from various web app providers. I think there is a culture of openness on the web and part of that I believe is due to the readability of the underpinnings. That being said, the web has felt like technology soup for some time now, shortly after getting away from CGI, it just felt like we where doing it wrong (at least the apps part). The newer JavaScript / CSS / HTML front-ends communicating to a REST back end feels a little more right to me over all the proprietary server pages mess (ASP, JSP, PHP) that we contorted the document language with, to make pages, apps. But it does still feel like there should be a better way to deliver apps. I think this is why IOS apps are doing so well, the use a common REST back end with the web, yet make development of the UI a lot less complex. I think the web could learn a lot from Apple's successes on the mobile platform, but there is just so much inertia behind web technologies that a radical departure is just not in the cards.

kls 15y ago

I would argue a lot of what was called "mash-ups" a few years ago, came about because people could view the underpinnings. Long before companies started documenting official API's developers where pulling apart their code and adding and mixing and matching features from various web app providers. I think there is a culture of openness on the web and part of that I believe is due to the readability of the underpinnings. That being said, the web has felt like technology soup for some time now, shortly after getting away from CGI, it just felt like we where doing it wrong (at least the apps part). The newer JavaScript / CSS / HTML front-ends communicating to a REST back end feels a little more right to me over all the proprietary server pages mess (ASP, JSP, PHP) that we contorted the document language with, to make pages, apps. But it does still feel like there should be a better way to deliver apps. I think this is why IOS apps are doing so well, the use a common REST back end with the web, yet make development of the UI a lot less complex. I think the web could learn a lot from Apple's successes on the mobile platform, but there is just so much inertia behind web technologies that a radical departure is just not in the cards.