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?
..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.
vos nescitis quicquam, nec cogitatis quia expedit nobis ut unus moriatur homo pro populo et non tota gens pereat.
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.
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.
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, each a program larger than DOOM I, on average.
And this problem isn't just limited to javascript- any time you want to treat the web like it hosts programs for you to run instead of data for you to view, you will hit this barrier.
In 2002 I was working on improving the performance of our demo web site. .js file.
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
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 can't learn javascript with view source.
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.
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>
Da fuk is this article about? View source and more importantly Inspect lets me rip most websites fully apart, see how stuff works, steal their code, and often send posts bypassing their client side scripts because it IS so tinkerable. Anglular sites in particular with the controllers exposed, you can see everything. When I see something cool on a sight I look at the source and see how they did it, it's never hard. Pretty print helps.
If you view source on a site I wrote and the javascript looks like gibberish to you, tough tits, you can learn how to code on pluralsight or stack exchange. If you like my jQuery go to Github and download my repo.
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.
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.
Not only can you view source (in living color), you can make source...
“He’s not deformed, he’s just drunk!”
The SeaMonkey suite still includes a Composer component. And you can cut and paste from the browser window to the composer and preserve the underlying markup.
There is also an 'edit' menu choice in the browser that pulls up a local copy of whatever page you are on in the Composer. The composer has view tabs to look at and fiddle with the source and snap back to the wysiwyg view.
Seriously, do none of you even know SeaMonkey still exists? I keep wondering, because it feels almost criminal how easy it is to drag and drop and save web content using it.
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.
it's stupid because the on ramp is easier than ever..
if you bother to make one google for it.
its just an advertisement
world was created 5 seconds before this post as it is.
Really, they can add comments back?
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
PHB's want shiny bouncy things.....besides tits
Table-ized A.I.
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. Javascript can modify the DOM, which in plain English means it has modified the original HTML file. These modifications may well include inserting or removing parts of the original HTML document.
The browser dev tools show how things are, not how they came across the wire. It's a major mindset change from the 1990's web.
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 the DOM inspector are significantly better. Being able to inline edit DOM and CSS with real time changes is far more beneficial than simply reviewing flat source files.
But if you find anything you can easily read, you know you picked a lousy site to crib from, because a GOOD site will minify the JS, often into a single file.
OR you found that rare gem of a site that uses just enough JavaScript to get the job done rather than piling layer upon layer like a cargo cult just to call one function.
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, literally 95%+ of this page is similar nonsense related to ad-blockers and Google Analytics. I wouldn't want to learn from that at all.
I could confidently program any program you could suggest. I'm not saying it would be any good, or perfect source, but I can program, and in a number of languages. Not once have I ever used a commercial store of source code, or someone's live production code to do that, because it's often just a mess.
You learn from nicely-made libraries, where the structure is amazingly well thought-out and clean. You learn from code snippets. You quickly learn from your own mess becoming unmanageable. But you rarely learn from just random code on random websites built for the purpose of obfuscation, easy compression, and automated generation that literally nobody ever sees. And, no, having more eyes on the code won't shame people, bad code propagates, it doesn't get shamed. "Even Slashdot has a mess of shit in its source, so why am I bothering to keep my tiny 1-page website clean, nobody will care"
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.
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
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 that it doesn't break despite not even remotely understanding what it does. Yes, I can understand that cutting corners and being lazy is comfy, but I also understand that these are the pages that cause enormous headaches because people not understanding why something works are also the people who create the worst security problems.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
Concatenating into a single file would be the worst design decision you could make. It would cause All libraries to be reloaded for every page of the site. You should learn about web development rather than pretending you know about it on Slashdot. Start with finding out about HTTP2 and how it works, for example.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
No, keep them as different files, but use a CDN. That way, your browser doesn't have to reload jQuery each time it goes to a new page or a new site. Even for private libraries, each file can be cached but one really large file that is specific to a page doesn't help when you go between pages of your site.
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 meaningful names to some of the variables and subroutine (if tracking reveals that a sub end-ups being registered as some hardware interrupt handler, "irq_7_audio_handler" is a bettername than "sub_146_i").
Learned quite a few trick back then by doing exactly that (e.g.: kicking the PC speaker into PWM-mode to play digital samples).
Not as good as having the real original code (e.g.: looking how FRACTINT did kick the VGA into Tweaked mode / Mode-X), but still quite useful.
Though much more straight forward than looking at even earlier code (self-modifying code from the heights of 8-bit era, spilling over to some early PC era when programmer got hired there).
Or more modern/later code (written in higher level languages then optimized the shitout of by the compiler, or carefully hand-optimized SIMD code), where only the fully commented source could make some sense.
And the web is slowly going into that direction :
the ting that the web designer write isn't that much related to the thing that browser sees.
they have nice modular tree of numerous JXL object using 3rd party libraries, that will be compiled into a single flat file,
then minified (though it's not that much useful in the modern era where everything is compresed on the flight)
then obfuscated (that is plain mean).
Nobody writes directy plain HTML,
and thus you won't see human readable HTML neither.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Pretentiously so, IMHO.
Come on. Not everything needs to be Turing-Complete.
(as PostScript, PDF and C++'s templating engine are).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Most of the new features in HTML5 (like templating) require JS. I guess you could bake template processing into the client but per the spec you need JS to clone and use templates. What about "data-" attributes? You don't "need" JS, but you they were put in with the idea that you would use JS to access them. I don't think a declarative language like HTML can provide the interface we want. Like it or not, JS or some programmatic language will be available. Otherwise you'll just be wrapping C/C++ in keywords which is practically the same thing.
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 code is used (instead of a function call). It's just slop, lazy, stupid. That's why I don't consider Web Programmers to be programmers at all.
Corporate interests wish to turn the 'web' into a series of apps... it's sad, really.
There is no XUL, only WebExtensions...
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 deleting and trying things and reverse engineering a web site in incredible ways. See how it interacts via the network tab, look at the stack trace to discover the code that is trying to interact with that server side call. Look at any piece of thing visually on the page and look at the event listeners t ochase down code, etc.
Discouraging news: The tendency to minify will mangle code in terrible ways. The whitespace removal is reversible, but the name mangling and globbing all files together and other things are hard to overcome.
The real terrible news: The use of 'framework of the week' tends to screw up the debug capability of those developer tools. The event listeners on a DOM element are inscrutible and the stack trace of a network call can be very tall and magically not even include the 'real' code that arranged for that interaction (hidden behind some trick like scheduling request with setTimeout to get the good stuff out of the stack for BS reasons).
Now one could lament that it is no longer acceptable to have plain-old, unstyled, static HTML, but 'view source' doesn't factor in there, and there is at least some refreshing resurgence of static content, albeit with styling to make it 'look pretty'.
XML is like violence. If it doesn't solve the problem, use more.
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.
"Liberalism is a very noble idea, currently controlled by some very bad people. Be sure you do not get the two confused.
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.
putting the 'B' in LGBTQ+
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 is supposed to fix this but still doesn't work correctly in IE or Edge.
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 of this, you have FrameworkOfTheMonth, and often multiples of them, layered on top of the DOM and JavaScript parser, and the result is unreadable client-side pages.
I think that in general, the level of abstraction and the constant jumping around to the newest shiniest stuff make it very hard for anyone who's a total newbie to come up to speed unless you really start with first principles and work your way up. Back when applications were simple, it was reasonably easy to look at source code and understand how things fit together. It still is at the abstract level, but now the Legos being glued together look more like Duplo blocks. If you are a new web developer and start your education at the framework level, you miss all the under-the-hood stuff about HTTP, network communication itself, and how the browser actually interprets your high level calls.
What I worry about is that the industry is going to shift to a point where the only people who actually know what's working under the hood work for software companies and cloud providers. As this continues, more and more of the low-level stuff is going to get cemented down below a layer of abstraction such that you can't change anything underneath. You might say this happened with assembler, etc. and I agree, but there should be a way for new entrants in the field to actually get to the first principles rather than starting them up 10,000 levels above it.
or you could just develop clientside software that does the same thing
Good luck installing a client-side .dmg on anything but a Mac. Or good luck installing a client-side .msi on anything but a Windows PC.
No, keep them as different files, but use a CDN. That way, your browser doesn't have to reload jQuery each time it goes to a new page or a new site.
And the CDN can track viewers' behavior through the Referer and If-Modified-Since headers that browsers send to the CDN when checking whether jQuery has been updated.
<html>
<script type="text/javascript" src="actual_page_content.js">
<body>
<h1>Please turn on Javascript to view this page.</h1>
</body>
</html>
Have gnu, will travel.
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?
Only if you don't make use of the well-supported caching mechanisms inherent in HTTP. Or fail to create a single page application (e.g. if all pages of your site are loading the same libraries, is it really a site or just a web application?). You throw a lot of stones for someone who doesn't seem to understand modern web development techniques.
Caching doesn't do shit when each page is a concatenation of unique content plus common conent. That's the whole point. Did you even think before you posted?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I didn't give much thought to my post, because my years of experience making applications to serve millions of weekly users through a global CDN means this is all second-nature to me. In many cases, one minified file can serve all the JavaScript dependencies of your entire site while doing client-side templating and dynamic content retrieval from external HTTP/REST services. A page is a dead concept on the web.
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.
You should have given it some thought. You would realize how stupid you sound right now. I said the idea was stupid. You agreed with me. Eventually, you'll figure that out.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
But unless every site uses that same concatenated minified file you get no caching benefit. That's the part you seem to be missing.
Today's developers are bunch of lazy code monkeys who doesn't know anymore how to optimize/organize code.
Yes it's the developer's fault if : ..........
- he use bloated framework;
- he produce shitty code
- he doesn't know how to do a proper SQL query, handle the transaction and close the connection after
- he's not able to write clean HTML code
- he doesn't know how to use a semaphore in concurrent programming
-
No it's not "the fault of the industry" or anyone else!
It's YOUR/OUR FAULT!
It's YOUR/OUR MESS!
Programming since 1988...
Will $CURRENT_YEAR be the year of the Linux Desktop?
Why would you need an account for a search engine?
To save your search customizations, such as which domains to exclude from results and whether to default to verbatim mode.
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.
XML is like violence. If it doesn't solve the problem, use more.
Your reading comprehension is so poor you think I agreed with you when I did not.
That's one of the tradeoffs that goes into deciding whether you want to use a public or private CDN as well. Do you accept the downtime of hosts not under your influence or control or do you not? Do you accept that their content which you reference will always be what you referenced at the time you created the dependency (think defacing or just loss of data due to incompetence)? Do you want to be pushed around if the maintainer of the content starts pulling it due to a legal battle or a petty disagreement?
The post I was replying to originally said:
It would cause All libraries to be reloaded for every page of the site
Which is an absolutely ridiculous statement. Whether I want my caching strategy to improve the load time of unrelated sites on the Internet is strictly my business. Being too dumb to set up caching on your own web site is an entirely different matter.
You heard it here first folks! trg83 thinks making caching impossible by concatenating page content and support libraries together so the libraries get reloaded every time is a great idea!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
A single file makes it harder to use noscript also, as your choices are then to allow it all or allow nothing.
If they are suggesting that people need to view the source of the back-end (php, python, java, etc.) then that could lead to some security concerns. Knowing exactly how a site works could make it easier for some unscrupulous individual to hack into said site.
We need a reasonable place to start. Look at HTML5 and then run your code through:
https://validator.w3.org
I like to code my stuff to that.