[klodolph]

I'm sorry, this is going to be a rant. Feel free to ignore if you don't care about my opinions on the subject.

The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier, it's a technical solution to a technical problem. It's why we use JSON or XML instead of ASN.1 for our daily work.

The open web is a web where no company is the gatekeeper. It's a web where we have multiple browsers, competing JS engines, et cetera. No one company can hold the web hostage. This is exactly why Flash, Java, ActiveX, and Sliverlight failed. Every one of those technologies was owned by a single company. Every one of those technologies failed because it's impossible for one company to be the gatekeeper for a technology that is supposed to run on billions of heterogenous devices.

So the lessons of Flash are this: don't put all of your eggs in the Adobe basket.

Meanwhile, you're fighting against WebAssembly because you are ideologically against black box software. Getting rid of WebAssembly does not actually achieve that goal. It's like you're fighting against condoms because they encourage promiscuity. The promiscuity is already there, and condoms just make it a better experience for everyone involved.

----

Footnote: JavaScript is on par with Python/Ruby/Lisp in a lot of ways, but there are some important deficiencies with respect to typing and static analysis, deficiencies which cause actual bugs in real world problems and cost developers time and money to deal with. It's why we've been inventing TypeScript, Flow, Dart, CoffeeScript, et cetera. You say that other people's problems with JS are "superficial", but that's exactly how I see your problems with WebAssembly.

People are going to write code in C++ because they can hit performance targets on platforms where they ship native code, and WebAssembly means a lot to the folks working with Unity, Unreal, or thousands of other existing projects which the new open web. The new open web, with WebAssembly, is an open web with more diversity than ever before, rather than a JavaScript monoculture.

[EdSharkey]

Yeah ... blackbox blob binaries (BBBB's?) don't strike me as the parent commenter's problem. It's not having access to a software's _original_ sources that you can build and deploy yourself that is the problem. Ideally, there would be some nuclear-powered version of View Source that gave you nice access to the original sources for the code loaded on a page - sort of a formalized "Fork Me on GitHub".

When I am being philosophical, smoking a cigar and sipping tequila after midnight, I begin to understand that the only software I've written that has a chance of outliving me is my open source. Everything else I've done has just been to serve up fleeting amusements. There is literally nothing commercially closed that I have contributed to that shouldn't be utterly scrapped.

If I died tonight, my positive impact on this planet for its people now and in the future is probably just constrained to my kids surviving me. Not an inconsequential thing, I love my kids like crazy and they're going on to do greater things than me. I just have the sense I've got more to offer than procreation and raising good people.

In my opinion, any hairy audacious moonshot goals humanity chooses to tackle should be open sourced in every way possible - otherwise the efforts cannot be fully genuine and transparent to generations that follow. Perhaps the increased open-sourcing of code and designs we see from industry today versus 20 years ago is the best we can hope for in competitive capitalist societies; maybe what we have is good and is the most we can expect.

[Yen]

I agree with you on some points, and disagree with you on others.

> The open web is a web where no company is the gatekeeper.

Absolutely!

> The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier, it's a technical solution to a technical problem.

I think "view source" was essential to the web we have today. It's not just a technical solution to a technical problem - it's an accidental UI/defaults solution to a social problem we didn't realize we had.

(note that, in general, this applies to the web of maybe 15~20 years ago. Geocities, inline styles, table-based layout, the works)

The problem, namely, is how to educate the general internet-using populace on the means of content-creation, and encourage them to actually create. If different companies can put out their web sites or their technologies with slightly reduced barriers on innovation, sure, that's kinda nice I guess. But, the web reaches it's true potential when the average nobody uses it not just to consume, but to create, produce, and publish.

There's a very small subset of the population that can just read an HTML spec (or at best, a tutorial), and actually churn out a working web page at all. Most people like to learn implicitly, by example and by imitating. With "view source" available, any web page you see is an example to learn from - or a code snippet to take, edit, and make your own.

---

now-a-days, we're up to our ears in HTML/CSS/JS classes, tutorials, etc., reasonably priced hosting, code snippets, the works. And yet, a smaller percentage of the internet population (and, I think, a smaller absolute number of people) actually create their own website.

Sure, there's more technology to grapple with, and the bar has been raised on what constitutes a "good" website the author would be satisfied with, but I think the real failure is that it's pretty much impossible to read the source of any interesting, non-trivial website.

[bigger_cheese]

I learnt to write HTML files in the early 90's (The Geocities era as you refer to it - forget tables back then everything was frames). I learnt exactly how you surmised by using view source on existing websites.

As a 13 year old kid who was mildly curious I was able to build a web site for my high school by hand in 'pure' html code. It looked laughably simple compared to the web pages of today but it was easy. I can and did teach many other people to make websites the same way.

Nowadays it seems to me like you don't have a hope in hell of hand writing a website (maybe some people still do seem like an exercise in frustration to me). Everything is all frameworks and scripting languages.

Earlier this year 20 years after I wrote html pages for my school's web site I had cause to write some HTML again. I work as an engineer (the non software type) in an industrial plant. I needed to display some non critical data to our plant operators on a screen in the control room. I thought 'hey I'll put it on a web page'. It would save me from having to mess around with C which is what our HMI system is written in. So I built something using 1990's era HTML mostly from my memory (although I did move on to using tables instead of frames) It worked.

A few weeks later some one asked to make it possible to view historical results so I built a simple html form (also 1990's era technology) to allow user to input the date range he wanted to view results from. It worked but did no input validation was finicky about the format you enter dates into it etc...

A few weeks later I decided I'd modernise it - modern websites have things like popup calendars which allow the user to "pick" a date instead of having to type dates into a text field. I found a framework written in javascript which provided those sorts of things and attempted to use it. Seemed to work but a lot of subtle bugs kept popping up.

When you clicked on a date in the calendar such as 12th of January the framework passed it to the form in US style 01-12-2015 format I live in Australia we use 12-01-2015 as out date format. I could find no way to change the way the framework functioned. I searched google and a few other people complained about the same issue seemed to be no solution. I thought I'd dig into the javascript file try to edit the program to provide date in format I needed it to be in. The file was 'minified' impossible to read javascript. I gave up and modifed my script to assume US style date input instead.

Maybe I'm just to old to learn new tricks now but I miss the older simpler web sometimes.

[icebraining]

In some ways, the recent HTML specs allows the dev to go back to that old-school handwriting.

For example, instead of bringing in a JS framework, you could now just replace the input type with "date", and a modern browser would show the date picker.

[bigger_cheese]

That doesn't work in Firefox or IE - unfortunately my work has standardised around IE

[woah]

If you were using an open source framework, the source is available. The minified file is just to save space.

[devsquid]

Well said.

Its even built into the spec of WASM to at least try to make the bytecode convert into human readable code. https://github.com/WebAssembly/design/blob/master/HighLevelG...

But as you state, its not integral to a "open web". IMO WASM is a long time coming and I think it will drastically help the "open web" which is suffering from some library bloat. Next we need an open and better image format.

[wwweston]

> The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier.

This is about as true as the idea that the only use of seeing source code is debugging (or building/deploying your own version of the app).

Which, of course, every developer here knows is not true.

Reading source code is useful for figuring out how to do something you didn't know how to do. It's useful for discovering idioms you didn't know, even if you already knew another way. It's very useful if you're trying to do bookmarklets/extensions/mashups or even more significantly engineered interop.

I don't know if there's a formal gatekeeper out there with a list of all the things that capital-O Officially make the The Open Web(TM) great, so I guess there's no way to settle what's on it.

But I don't know how anyone could argue that these things weren't significant bullet points in a much longer list of reasons why the web has seen faster and broader adoption than any of the competing VMs and why it was/is often more useful and nice to work with despite more limited capabilities.

And I think it goes almost without saying that list is much bigger than the "no single gatekeeper" point.

> you're fighting against WebAssembly because you are ideologically against black box software

I am neither fighting against WebAssembly nor ideologically against any kind of black box software. My earlier comment makes it clear I think WebAssembly has a place (and, more generally, that transpiling does) as well as its hazards.

I am stepping in to point out that Flash and WebAssembly have significant things in common, some of which are tradeoffs against things that have made the Web an effective and proliferating medium.

> [JS] some important deficiencies with respect to typing and static analysis

See my aside about Elm. Given the fact that dynamic languages (including maligned ones like JS and even PHP) seem to be about as equally successful in terms of shipped software as statically manifest typed languages, whether or not even something like TypeScript is really going to give engineering teams an edge seems like far from a settled question to me. But I'm interested to see what happens where we're talking significantly augmented capabilities rather than the largely aesthetic differences that something like CoffeeScript represents.

(Speaking of which: "TypeScript, Flow, Dart, CoffeeScript"... at least one of these things is not like the others if you're invoking static analysis and typing as reasons for transpiling.)

> You say that other people's problems with JS are "superficial", but that's exactly how I see your problems with WebAssembly.

I can't tell exactly what you're saying here, but at a close approximation, it sounds like you might be suggesting that the readability of WebAssembly is going to be on the same order of difficulty that an experienced Python developer has reading idiomatic human-written JS (ie, aesthetic). This is potentially possible, I guess, in a world where everyone writing compilers that target WebAssembly is conscientious at/above the level that the CoffeeScript developers were (CS output is really fairly readable, arguably more so than minified JS). But then again, that's not what the name suggests WebAssembly is for. In practice, most of the time it's probably going to read... a lot like assembly language dressed in C-like syntax.

[spion]

> Given the fact that dynamic languages (including maligned ones like JS and even PHP) seem to be about as equally successful in terms of shipped software as statically manifest typed languages, whether or not even something like TypeScript is really going to give engineering teams an edge seems like far from a settled question to me

I'm always so frustrated when I read this, because I've worked on a few dynamic language codebases as well as seen a few open source ones on github. Very often I see the pattern of the project contributors losing control over the dynamic language project. They slip up, the tests become insufficient and now they refuse / are afraid to touch critical parts of the code. Soon development slows down to a crawl. Or rather, there are no more changes - only additions / grafts to the existing codebase.

When I first started using TypeScript, I feared that I'm going to lose the benefits of a dynamic language and that I'll have to write a lot more boilerplate. I had no idea how little of that was true. TypeScript really goes out of its way to model as many JS idioms as possible, including some really dynamic ones:

  * Structural types are formalized duck type checking. You don't 
    have to say your object implements an interface: if it has all 
    the right fields, and they're of the right type, it does. This is 
    similar to Go interfaces (but a bit more powerful in what it can express).
  * Unions types plus type guards can model dynamic function arguments
  * Intersection types can model record (object) merging

The entire type system in TypeScript is basically a formalization of the typical duck typing patterns that are common in JavaScript. As a result, TypeScript can model almost any common JS idiom. The loss of expresivity was very minimal - maybe 1% of the most dynamic code only. And even there, you can tell the type system "I know what I'm doing" (cast to `any`), turn it off, do your dynamic stuff and then tell it the resulting types (cast to whatever types are the result before returning).

Given the above, theres been absolutely no doubt in my mind whether TypeScript gave us an edge or not. Its been incomparably better than just plain JS.

[devsquid]

Hey incase you aren't aware, having WASM output a human reading version is part of the spec.

"define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality." https://github.com/WebAssembly/design/blob/master/HighLevelG...