We Need To Reboot the Culture of View Source (wired.com)

theodp writes: Back in ye olde days of the information superhighway," begins Clive Thompson in It's Time to Make Code More Tinker-Friendly, "curious newbies had an easy way to see how websites worked: View Source." But no more. "Websites have evolved into complex, full-featured apps," laments Thompson. "Click View Source on Google.com and behold the slurry of incomprehensible Javascript. This increasingly worries old-guard coders. If the web no longer has a simple on-ramp, it could easily discourage curious amateurs." What the world needs now, Thompson argues, are "new tools that let everyone see, understand, and remix today's web. We need, in other words, to reboot the culture of View Source." Thompson cites Fog Creek Software's Glitch, Chris Coyier's CodePen, and Google's TensorFlow Playground as examples of efforts that embrace the spirit of View Source and help people recombine code in useful ways. Any other suggestions?

Comments

The JavaScript on most sites..

[intellitech]

..is intentionally incomprehensible. Whether indirectly through minification or directly via obfuscation.

I know it's hard for some people to accept, but there is a serious amount of interest (and, rightfully so) in preventing the reverse engineering of website code, or at least, hindering efforts to do so.

Re:The JavaScript on most sites..

[Anonymous Coward]

But why? A competent developer can duplicate the functionality of most webpages easy enough, so what does obfuscation gain apart from putting off curious newbies?

Re:The JavaScript on most sites..

[digitalchinky]

If you kill off Javascript, you also kill off medial image imaging (my line of work) or a thousand other things you depend on but don't realize. Be careful what you wish for. The web is much bigger than the sea of annoying cookie notices, calls to action, and responsive design. Javascript, like or not, gets crap done :-) It's not perfect, but it's not so terrible either.

Re:The JavaScript on most sites..

[AHuxley]

To hide content thats DRM. A huge image or movie thats displayed but only a low res version will save with the web page.

Re: The JavaScript on most sites..

[guruevi]

Most JavaScript is minified for bandwidth reasons. Most things a site uses are also open libraries with open extensions or plugins, think jQuery and *shudder* Angular.

You can decompile everything on the web pretty easy. Developer mode in both Chrome and Safari will reindent most minified code to readable scripts and the rest isn't really that important, most things you want to do are better done not the way Google does it (you really don't want another MVC layer in your "View").

Re:The JavaScript on most sites..

[CustomSolvers2]

A competent developer can duplicate the functionality of most webpages

This statement is highly misleading, because it doesn't apply to all the back-end part which is completely hidden. For example, a website consisting in plain HTML pages which are generated dynamically cannot be emulated. You might go page by page and store all the HTML (or any embedded code), but this task might be too difficult or even impossible; additionally, this would be a mere collection of the results outputted by the current version of the functionality, rather than a duplication of said functionality.

My two sites are 100% dynamic (written in PHP). You can try to collect the HTML of quite a few of their pages, but certainly not of all of them. Bear in mind that one includes a ranking of web domains whose size right now is over 9M. I have enabled a URL-friendly access which allows visitors to list chunks of that ranking starting at any position and including up to 250 elements. Additionally, these records are being regularly updated (at the moment, once every 24 hours).

Open source not view source

[James Carnley]

View source is a relic of how the internet used to be. It's not coming back and I would argue should be hidden by default in browsers. It's akin to decompiling the source of an .exe file to look at the code (which some people do) and learn how it does things. Not a good method.

What you really want for learning and teaching techniques is to view the real source code. The source code with comments, with context, and with reproducibility in full. This is what open source projects and those demo websites do. They intentionally format the code in a readable way for the purposes of learning.

Someone learning to code on the web should not be looking at production code in a scalable web app, they should be following tutorials and using demo projects like you do in every single other language. The web isn't special it just had the quirk of the View Source button that was neat at the time but is now out of date and a relic of a bygone era.

Re:Open source not view source

[Anonymous Coward]

View source is a relic of how the internet used to be. It's not coming back and I would argue should be hidden by default in browsers. It's akin to decompiling the source of an .exe file to look at the code (which some people do) and learn how it does things. Not a good method.

It's a great method if one wants to look at the output of a compiler. It's also useful to look at the internals of a web page as far as just how much it's generated on the fly in javascript vs baked in by a server-side script/app.

What you really want for learning and teaching techniques is to view the real source code. The source code with comments, with context, and with reproducibility in full. This is what open source projects and those demo websites do. They intentionally format the code in a readable way for the purposes of learning.

Which goes to show you how the big complaint I had about the way the web was going came true. Sure, we bypassed having Flash hell. But we've replaced it with HTML5 and javascript hell. The fact that you don't think it's actually possible for a web site to have comments with context and such and that one can only get that in demo websites is precisely the problem. If I want to make a web site like Amazon, what better framework is there than to literally see how they do it?

Someone learning to code on the web should not be looking at production code in a scalable web app,

Actually they should, in part, to understand exactly what their framework is outputting to get an idea of just how scaleable said web app really is in production. More generally, developers of web pages need to look at the code to have an idea of why stuff isn't working right.

they should be following tutorials and using demo projects like you do in every single other language.

Another major part of learning another language is seeing actual production code, not just demo projects. And debugging programs, possibly even without the source code. It's actually a necessary step to get into the mindset of "what could possible be causing this problem".

The web isn't special it just had the quirk of the View Source button that was neat at the time but is now out of date and a relic of a bygone era.

No, it was special. For a long time, a web page really was something that could be intelligible in "view source" because html was merely a markup language. Page generators could simplify the boilerplate production, but even then the output was still readily human readable. Honestly, the move to CSS didn't kill this. Javascript itself didn't kill this either. What mostly killed this was that Google (and others) intentionally obfuscated their code precisely to make it so people COULDN'T learn from it. Any claims about code size? That's what gzip (and other) in-line compression is for.

Oh, and, btw, you should really look up the history of LISP machines to get some perspective on just how consumer interests turn an open platform into a shithole.

It still works exactly as before

[somenickname]

The "View Source" functionality still works exactly as before. Except better. In Firefox, when I mistakenly hit Ctrl-Shift-C (which I do often), it brings me into an interactive "View Source" like functionality that is essentially a debugger. It's not [completely] the fault of webpage makers that the stuff under the hood is effectively gobbly-gook: That's just how the web looks now.

I'm not really sure what this summary is implying. That we should roll back the web to hand written HTML with blink tags so that kids can understand it? Fuck that. Get your kid a Raspberry Pi and as many $5 peripherals as they want. That's WAY more interesting than web programming and leads to understanding how things work instead of copy/pasting shitty HTML.

View Source for circa-1999 Google.com

[theodp]

Google.com Apr 22, 1999
<center>
<img src="/web/19990422191353im_/http://www.google.com/google.jpg" alt="Google! (Beta version)">

<table border="0">
<tr>
<td>
<form name="f" method="GET" action="/web/19990422191353/http://www.google.com/search">
<center>Search the web using Google<br></center>
<center><input type="text" name="q" value="" size="40" framewidth="4"><br></center>
<center><input type="submit" value="Google Search">
<input type="submit" name="sa" value="I'm feeling lucky"><br></center>
</form>
</td>
</tr>
</table>

<a href="more.html">More Google!</a><br>

<p><font size="-1">Copyright ©1999 Google Inc.</font>
</center>

Re:View Source for circa-1999 Google.com

[gustygolf]

Three <center> tags when a single one would do.

Google was as bloated as ever back then too, I see.

Re:View Source for circa-1999 Google.com

[thegarbz]

It was in Beta

Re:View Source for circa-1999 Google.com

[Lost Race]

Google.com Apr 22, 1999

That is a thing of beauty.

Compare to 2017: view-source:https://www.google.com/

We need to go back to simplicity.

[green1]

If you want "view source" to be useful, you need to go back to coding with simplicity in mind.

The original post talks about viewing the source of the google homepage and getting an incomprehensible slurry. But why? What does that actually accomplish? The page is one text entry box, and 2 buttons, plus a graphic above it. There is ZERO excuse for it being over 47,000 characters (not counting all the other stuff it pulls in). But this isn't at all rare on today's web. This is also why so many pages are so horrendously slow to load, it's all scripts and links to other files and domains, even the simplest websites use absolutely incredible amounts of bandwidth, and yet do no more than could be done in 1/100th the size or less, and be human readable.

99.99999% of these sites aren't huge for any good reason, they're just horribly inefficient.

Re:We need to go back to simplicity.

[somenickname]

99.99999% of these sites aren't huge for any good reason, they're just horribly inefficient.

99.99999% of all software "isn't huge for any good reason". Except for the fact that the developers decided to not use assembly so they could actually, I dunno, complete a project in a sane amount of time.

Have a look at MenuetOS. It's written completely in assembly, fits on a single floppy and provides a lot of the useful functionality that a modern desktop does. It's insanely fast and easy to understand (if you don't mind jamming 100 lines of assembly into your head to grok an if statement). Yet, no one (probably not even the developers) uses it as their primary desktop. It's an awesome project but, it's certainly never going to overtake any other OS in users.

You can stand on the shoulders of giants (or, in the case of the web, Trolls) or you can re-invent the wheel over and over. Thankfully, the modern software industry has mostly chosen correctly on this point. We are able to build nice things because the people before us have built nice foundations for us to build upon.

I'll let you get back to writing your custom XML parser...

Re:We need to go back to simplicity.

[green1]

We're not talking assembly here, we're talking HTML. HTML is far easier to understand than the garbage most "developers" use these days, while keeping the page TINY by comparison. Assembler on the other hand is much harder to understand and program in.

If you're writing a few lines of static content, there's no excuse to take as much as a few megabytes of code to do it.

This is actually the opposite of your example, all the extra code makes it more difficult to write, not easier, and it has the added issue of providing ZERO benefit, and often major drawbacks. For instance, if you just put raw HTML text on a page, it will format to every browser ever made, it will nicely fill the window, regardless of the size. But instead, developers put in all sorts of extraneous code to format it to specific window sizes, and the end result tends to be that it looks horrible on all of them (don't you just love the pages that only allow you to use 1/4 of the width of your screen for content with the other 3/4 being vast empty space, and yet you have to scroll for days to find the bottom?)

Re:We need to go back to simplicity.

[Kjella]

This is actually the opposite of your example, all the extra code makes it more difficult to write, not easier, and it has the added issue of providing ZERO benefit, and often major drawbacks. For instance, if you just put raw HTML text on a page, it will format to every browser ever made, it will nicely fill the window, regardless of the size. But instead, developers put in all sorts of extraneous code to format it to specific window sizes, and the end result tends to be that it looks horrible on all of them

Bullshit. It will flow, but not "nicely". For example /. is all but unreadable at 100% on my 3840x2160 monitor, I have my web browser to 300% zoom, I could read it fine at 200% too but the lines just get uncomfortably long. There's a reason newspapers invented columns. Creating anything more complex than a single flow (like header, footer, columns for menus/other items) with tables or early CSS and mixing static/dynamic content like raster graphics with flowing text was total hell from the dawn of the web to the death of IE6.

And not because the web site designers were incompetent, I've gotten my share of gray hairs trying to make it work and it was like doing layout with oven mitts. For example, simple things like one fixed sized graphic or a single long word exceeding the dynamic column width and some browsers would go ballistic overflowing or re-flowing everything rather than clamp it. Hard-coding and testing was the only way you could make it work and even then I had mysterious deviations showing up not only in IE but Netscape/Firefox/Safari/Opera too.

I don't want to shit on what Tim Berners-Lee did because the concept of the web and hyperlinking is brilliant. But layout was never a topic in the initial design and the crude attempts to retrofit it later would have given those who did paper layout ulcers. And not even the big layout issues, simple things like soft hyphens where you write "hyper&shy;linking" to say that hyperlinking is normally one word but hyper-<br>linking would be an acceptable way to do a line break were missing or broken until way into the 2000s.

Re:... is copy-pasted using View Source

[Dog-Cow]

What web server doesn't gzip the HTTP stream these days? Concatenating into a single file makes sense to avoid multiple connections or requests, but minifying doesn't.

Explanation about Medical Imaging

[Texmaize]

In a few posts, there seems to be some confusion about the use of java in medical imaging. What the above poster is likely talking about is a program released by the NIH called ImageJ. https://imagej.nih.gov/ij/ It is a wonderful application that is useful for image processing and even microscopy. There is a user community that has made many add-ons to increase functionality. It is written in java because macs are thing in the medical research world, and it was easier to support one java version than separate mac and PC things. That said, it was a little disingenuous to include that in this discussion about web programming. ImageJ is not used as web plugin, but more as an on local machine program. I think his point was, if you wish away all of java, you will wish away some things people use. The thread is about wishing away java for HTML purposes. Hope this helps.

Most HTML source is simple

[PPH]

<html>
<script type="text/javascript" src="actual_page_content.js">
<body>
<h1>Please turn on Javascript to view this page.</h1>
</body>
</html>

Re:because the web owes newbies.....what exactly

[Junta]

On the flipside, while these people *think* they are making expertly crafted sites, they've in practice poorly duct taped a bunch of stuff that looks fancy at a glance, but behaves crazy and is damned near impossible for anyone to figure out what's going on.

What's happened here is we have a whole ton of people who can do the equivalent of drywall, paint, and decoration work, but can't build foundations or framing. Complicating things is the decision makers frequently can only judge the superficial, so teams that are good at doing that structural stuff but can't make attractive front end will be passed over for teams that can make something attractive, but works terribly.