Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Programming The Internet Communications Network Software

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

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?

We Need To Reboot the Culture of View Source

Comments Filter:
  • by intellitech ( 1912116 ) on Tuesday July 11, 2017 @11:34PM (#54791191)

    ..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: (Score:2, Insightful)

      by HornWumpus ( 783565 )

      Newbies have no business looking at web pages. It's too much of a fucking mess, it will only scare them off.

      Find something interesting and simple for them to learn on. Yes it will have to be contrived, but so what?

    • Re: (Score:2, Interesting)

      by 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?

      • by AHuxley ( 892839 )
        To hide content thats DRM. A huge image or movie thats displayed but only a low res version will save with the web page.
      • 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").

        • by Rei ( 128717 )

          This. It's very common to have separate "development" and "deployment" versions (the latter often with a title like ".min.js"), the latter having been run through a program that mangles it not to "hide" things, but to minimize bandwidth. Part of the mangling can be undone on the client side. Part of it can't.

          Honestly, I think it'd be best for everyone if we'd finally get around to standardizing Javascript compilation, with servers being able to request both compiled and uncompiled versions. Then everyone's

        • And yet they send bloated multimedia files. Optimizing a commonly used graphic and you will save a lot more in bandwidth. I've seen some places where they could have the files sizes of their images cut in half without impacting quality.

          • I've seen some places where they could have the files sizes of their images cut in half without impacting quality.

            Until you view the picture on a high-DPI monitor, at which point the images become a blurfest compared to the adjacent text. To work around this, some sites send photos at double resolution in case the user is on a Retina display or in case the user chooses Zoom. The srcset attribute [css-tricks.com] is supposed to fix this but still doesn't work correctly in IE or Edge [caniuse.com].

      • 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 functionali

        • by AmiMoJo ( 196126 )

          The raw source code of a web page is kinda like raw assembler code. Sure, you can understand and read it, but most people don't because there are better tools. The vast majority of web developers don't bother with most of that stuff.

          At the high level end you have CMS packages that you install and then do 99% of the work in a browser via the tools that the CMS provides. Then in the middle you have people who use frameworks and libraries to do all the hard stuff and then write some wrapper/logic code around t

          • The raw source code of a web page is kinda like raw assembler code

            No, it is not. As explained, my two sites are fully written in PHP and generate all the HTML code dynamically. You cannot access this PHP code because it runs on the corresponding server; you can only see some of the outputs generated by that code (e.g., HTML). On the other hand, you can have access to the client-side scripts like JavaScript, but my sites have just a tiny bit of that. Web-based programming is formed by two parts: client-side (visitors can see the code via "view code") and server-side (visi

            • by AmiMoJo ( 196126 )

              I meant they are similar conceptually, not in terms of accessibility.

      • by SQLGuru ( 980662 )

        The biggest gain from obfuscation (in the form of minification) is improving speed. Sure, we all have broadband, but web sites have gone from a single file that was self contained to a file that pulls in so many other files (multiple CSS, multiple JavaScript files, tons of images, etc.). So minification is basically compression......sure, it's not saving gigs, but it DOES improve the load times. And a fast page is a visited page.

        • by Hentes ( 2461350 )

          Compressed http will help you a lot more in terms of size than "minification" ever can.

          • by tepples ( 727027 )

            Minification then gzip saves more size than gzip alone, as minification allows more of the code to fit into gzip's 32 KiB back-reference window.

    • by houghi ( 78078 )

      How does making code hard to read prevent reverse engineering. This is like saying that changing the port of ssh makes your system safer.
      To me it just sounds like security through obscurity.

      And the code you see is generated by a database anyway.
      Car example: it is reverse engineering an engine of a car by opening the doors.

    • When there are better programmers. And based on prior experience reading code, testing job candidates, reviewing my own. code etc. that will probably never happen. Most of them are barely better than scary. The smart ones are overly clever. The honest ones quit when they realize they are at best mediocre (such as myself). That does not leave many to choose from.

    • An autoformatter in the "view code" option would be a great help, indeed. All that javascript without line breaks could be made so much more readable if it'd be reformatted with sensible line breaks and indentation, ideally with keyword highlighting and so. Of course still no comments but at least it'd make the stuff somewhat readable.

  • by James Carnley ( 789899 ) on Tuesday July 11, 2017 @11:38PM (#54791209) Homepage

    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.

    • I would add that the "view source" is not a way to learn to code the "under the hood" functionalities. It is a way to see how the site integration is done. Back in my days, I learn how to build proper TABLES, TR, TD. Now I have learned to work with DIVs to organize my containers.

      I find the "Developer tools" to be now way more useful than "view source". First it does not require a new page load, so you can see the markup after a POST for example. And you can just point at the element of interest, and it sh
    • by Anonymous Coward on Wednesday July 12, 2017 @12:52AM (#54791505)

      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.

    • I read the jist of what he's saying not so much as "we should be able to view source" but "we need a way for newbies to get online". To some extent I agree with him - the webdev I've ever done has been so unintuitive and tedious I can't imagine why anyone would ever want to be a webdev.

      To elaborate, I find HTML pretty straight forward. It's pretty clear what you're supposed to be doing. However, once you start needing CSS, then things get considerably less intuitive. CSS means that the ordering in HTML is s

    • 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 might come as a surprise to some, but decompiling .exe files to learn was actually a very decent method at some point in the past.
      Specially at a time (e.g.: older DOS era, speaking of EXE files) when when lots of these software were mostly written in (not too much optimized) assembler.

      Decompiler where mostly re-formating the code (indentation), inserting useful comments (regarding the IO-ports used and the parameters passed to software interrupt) thank to some dataflow code tracking, and giving meaningf

  • They don't seem to have established that we've actually lost anything. This basically just sounds like old people going "things are different and therefore bad."

    I can't help but think they're just schilling the sites they link to. Glitch "hosts hundreds of simple web apps—everything from Tetris clones to databases and to-do lists—written using Javascript. " Wow, hundreds? Github and npm will be so jealous.

    • by AHuxley ( 892839 )
      To find the data. That big image or media file that is displayed but might not always save.
  • You can't make it work with javascript. You can write a simple language, like HTML, that is meant to handle most cases of the net. You can then add to that language whenever a new thing becomes needed.

    But instead, if you insist on having a general purpose language that you write your fucking webpages in, of COURSE it will end up being as complex as code. Because it IS code.

    As long as javascript is tolerated, this will become more and more of a problem. Webpages aren't just "apps": they are, on average,

  • In 2002 I was working on improving the performance of our demo web site.
    I started doing what came to be called AJAX. One of my co-workers did a view source of the website I developed, and got 3 lines with the launch of the .js file.
    He stared in astonishment as the site ran on generated html from the javascript. The page loads were blindingly fast, because there wasn't actually a server request. All the work was being done in the browser with javascript.
    The world has come a long way since then.

    You c
  • by somenickname ( 1270442 ) on Wednesday July 12, 2017 @12:08AM (#54791349)

    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.

    • by Trogre ( 513942 )

      The most excellent Style Editor tab lets you play with the style and have it change whatever page you're looking at in realtime. A great way to learn CSS.

    • Right click then choose the "Prettify Source" option. It nicely reformats the code to be more readable.

      If cntrl-shirt-c doesn't work (hello OS/X) then Tools -> Web Developer -> Debugger

  • by theodp ( 442580 ) on Wednesday July 12, 2017 @12:21AM (#54791399)

    Google.com Apr 22, 1999 [archive.org]
    <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>

  • by green1 ( 322787 ) on Wednesday July 12, 2017 @12:28AM (#54791421)

    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.

    • Agreed. The reason they're horribly inefficient is because programmers don't understand how to use javascript, so they end up using massive frameworks and libraries to do even the most basic things. http://vanilla-js.com/ [vanilla-js.com]
      • by green1 ( 322787 )

        The vast majority of the time, there was no reason to use javascript, or ANY script.

        Most pages are still static content. Static content doesn't require scripts.

    • by AHuxley ( 892839 )
      Todays web has to push the ads.
      Ensure the ad is displayed.
      Ensure the click gets paid for and that no user is even thinking of attempting to "surfing" for free by blocking some scripts or the ad.

      If the browser is not showing the ad, the user is informed that they have to whitelist the site.
      Try and turn off or block scripts in the browser and the content will not show.
      Older browsers are told how to find a new browser that will support ads been displayed.
      The hard part is to get the site to demand wh
      • by tlhIngan ( 30335 )

        If the browser is not showing the ad, the user is informed that they have to whitelist the site.
        Try and turn off or block scripts in the browser and the content will not show.

        It's gotten so bad that some sites aren't referencing 3rd party scripts anymore - the ad scripts are pulled by the webserver and incorporated into the page before it's sent to you. So whitelisting the site, automatically pulls in all the ads.

        Ir's probably the reason why our malware block on the firewall blocks more and more sites - bec

        • by AHuxley ( 892839 )
          How long before users have to select or paint over ads per site to try and get ads removed?
          Some powerful new code will be needed to get browsers working as they should on users computer to display only what a user wants.
    • Re: (Score:3, Insightful)

      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 on

      • by green1 ( 322787 ) on Wednesday July 12, 2017 @12:56AM (#54791519)

        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?)

        • If you're writing a few lines of static content

          When was the last time you saw a few lines of static content on the internet?

          All of this talk is the metaphorical equivalent of pining for running a computer where the UI consisted of "C:\>" with a flashing cursor underneath.

          Google is a great example. Anyone who thinks it's a picture, a text form and two buttons, hasn't actually looked very closely.

        • by Kjella ( 173770 )

          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 t

          • Having to manually specify soft-hyphens is insane. Hyphenation rules are standardized and should come for free. A very small developer tool in the browser would then allow the developer to see which words on the web page are not in the standard dictionary and provide hyphenations as a resource file for their site (or specify in their head element).
            • by Kjella ( 173770 )

              Having to manually specify soft-hyphens is insane. Hyphenation rules are standardized and should come for free. A very small developer tool in the browser would then allow the developer to see which words on the web page are not in the standard dictionary and provide hyphenations as a resource file for their site (or specify in their head element).

              Actually doing it for hundreds of languages is non-trivial, mixed-language texts are a giant pain in the ass and you might want historical texts to use historical rules and for all copies to look exactly the same. This would require all clients to dynamically update language rules as they're adjusted to present a consistent final result, even offline renderers without online access or else the text would look different. In my opinion this should be done by the development tool/CMS/web server and the client

    • by imidan ( 559239 )

      Tangentially related, the needless complexity tends to make sites more fragile. I used to work at a place (during this decade) where we periodically had to go on a web site and fill out a form related to our work hours. The form was super simple in concept: it had a radio button array, a text box, and a submit button. It also didn't work in Chrome, and there was a big warning at the top advising users to use Internet Explorer or FireFox to access the page.

      This is content that has been supported by HTML for

    • 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).

      WTF, when was the last time you visited Google.com. I see a portal to the Google account, logins, view settings, access to calendar and apps, i also see a dynamically generated logo that can be interacted with.

      Look more closely.

    • by gweihir ( 88907 )

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

      Simplicity needs skill. In today's world, "web developers" often do not even understand the basics and have the lowest skills that just about will get the job done to some degree. Hence they rely on frameworks that may make some things "easier" to accomplish, but increase complexity massively and hide what is actually going on. The worst case I have seen is 2.5MB (!) of JavaScript to render a simple table that plain HTML would have done just as well.

  • For 3D design, all projects that are "customizable" also have the source available. I've recently started teaching myself 3D design and being able to view the source on thingiverse brings back memories of when I learned to code by using the logo turtle and viewing the source of Oregon Trail.

  • In a small way, Thompson is correct. But a modern web developer wouldn't view source, they would right-click Inspect the element.

    There are many reasons for this but the most basic thing a novice (or out of date old-timer) should understand is that the code you see through View Source is not necessarily what you are seeing on the rendered version.

    This is due to several reasons but the most obvious are CSS and Javascript. CSS can modify the positioning, colors, size, and general layout parameters of an item.

  • We need to reboot the use of the word "reboot".

    "... You've had ELEVEN REBOOTS, people! When are you going to get a stable system?"

    - Bruce Sterling, closing remarks at Reboot 12

  • We literally have countless web based documentation, tutorials, and editors. "View Source" is no longer needed. All of the good information is readily available without needing to dig into some half-assed "dev" tool that is literally just showing the raw text without any annotation whatsoever.

    Other than testing to ensure the contents sent from the server are exactly what I expected them to be, I've never used "View Source" otherwise in years. If you REALLY want to tinker, then the modern F12 dev tools like

  • I would not want any budding programmer to learn from commercial, especially website, source code.

    Cases in point on this very website:

    Inside its own javascript tag for one line:

    var _gaq = _gaq || [];

    Further down:

    var _gaq = _gaq || [];

    inside a larger tag.

    Literally... wtf? From variable naming to why are you doing that, to why is it in twice and re-using the same name, to why is it wrapped in a tag for ONE line, and not in a header/js file rather than THIS page's (i.e. the submit form's) source?

    Not only that

  • Who is being discouraged? Web developers and coders coming to fact the the world isn't static text and that coding should be learnt properly and given respect?

    Certainly not content creators which have an easier time than ever to generate content now.

  • We do not need the return of the copy/pasted cargo-cult programming webpages. They were cute back in the day but today, they would present a security nightmare.

    Wanna make a webpage? Effin' learn how to do it right! It's not 1990 anymore, there's literally thousands of pages dedicated to teaching you how to make your own webpage, from the basics of HTML to the intimate details of JSON and REST APIs.

    It is all there. And for free. There is literally no need anymore to copy/paste code, fiddle with it and hope t

  • Those of us who are really "old guard" laugh at the notion that anyone who cut their programming teeth in the age of the web browser would consider themselves "old guard". Let them eat core dumps.


  • A really simple page like the plain old Google (http://www.google.com) is now 30,000 + bytes of crap.

    That's why we all need gigabit to the home. Web Content providers are asshats who don't even think for a second about how much totally unnecessary garbage they ship with their pages.

    Want to make yourself feel sick, analyse how much of a typical webpage is absolutely unnecessary, redundant, unused HTML (or JS, or whatever). Count how many times the font is specified, or how many times duplicated c
  • Corporate interests wish to turn the 'web' into a series of apps... it's sad, really.
  • Bad news: most web content has outgrown the simplistic 'view source'.

    Good news: As javascript has matured, technologies like java, flash, and activex in the browser that was used in the 'good old days' to get around how useless it was have gone away, and javascript is at least source (more to come)

    Better news: Browsers now have developer tools that can enable far more capable tinkering than was dreamed of in the 'view source' days. You can dynamically screw with html, css, and javascript, adding and dele

  • I can't really fault web developers for building incredibly complex pages that don't lend themselves well to interpretation. This is what happens when the industry says we can't have client-side applications anymore, and tries to shoehorn rich client functionality into a browser that wasn't really designed for some of the heavy lifting it's being asked to do. Browsers used to be thin clients back the the olden days, and JavaScript wasn't designed to replace the entire functionality of a rich client. Because

  • by PPH ( 736903 ) on Wednesday July 12, 2017 @11:50AM (#54794015)

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

  • Stack Overflow, Codecademy, Sitepoint, W3 Schools, JS-beautifier, and more besides, all just a click away in a Google search.

    I'm grateful for the huge progress in browser dev-tools, but why does anyone need to view-source to get into web programming anymore?

  • Know what I think is utterly rediculous? Having to enable gods-be-damned javascript for a site JUST TO READ THE TEXT! This shit has to STOP.

Imagination is more important than knowledge. -- Albert Einstein

Working...