Edit:

And to all those thinking "but that's the browser", that's my point. We have the browser and while it works, it's incredibly broken in a lot of ways. I'm proposing a system designed from the ground up to do the job that the browser has currently been hacked and add-on'd into doing.

You mean like a browser?

tl;dr you are making the point I refuted in my original post.

...could be worse. At least it's not E-mail.

Honestly, I don't think the browser is so bad. And once wasm takes hold and tooling catches up, you'll have lots of options.

It would mean the end of the web, not a return to its beginnings. You wouldn't be dealing with marked-up text, you'd be dealing with binary files (text markup, of course, being a subset thereof). The internet (and whatever emerged on top of it to replace the web) would then be concerned with content, sharing, and identity management only, and applications would be built on top of that.[1]

The trick, as you said, is how to securely run untrusted code. That's what the web (well, I suppose more technically, browsers) are trying to solve; the problem is that the same origin policy, which is at the core of web security, just doesn't work very well. There are a lot of examples where this breaks; here are three off the top of my head:

1. Tracking using javascript to look for unique browser identifiers

2. XSS, CSRF, etc

3. Legitimate cross-site communication

So clearly our existing solution to the "how do you securely execute dynamic, untrusted code" problem isn't cutting it. There's a lot of research (and production code, for the record) going into potentially better approaches though, so I think it's likely we'll see change, if we can get past the inertia behind today's hairball.

[1] Incidentally this is exactly the approach we're taking with implementations of the Muse protocol (https://github.com/Muterra/doc-muse), which uses encryption to provide private content/sharing/identity management on untrusted servers.

[1]: http://links.twibright.com/user_en.html#ap-javascript

Good luck with that. You should bring back Gopher while you're at it.

Not sure why it's so hard, probably because it's in nobody's interests but the users (as every major just wants to promote their own platform and have the web play second fiddle to it).

Then again, a top tier BMW doesn't sound so different than an Edsel either. They both have internal combustion engines, 4 wheels, a steering wheel, and they take you from place A to place B in similar speeds (in orders of magnitude).

That's because you're focusing on the similarities which don't say anything -- what's important in all cases are the differences.

Which in this case are mostly about the implementation. - the UI wouldn't be a part of a page, it would be THE page. - it shouldn't be an over-engineered mess of a GUI toolkit like Swing. - it should offer modern and capable widgets, instead of the bizarro, limited and uncanny value one's that Swing offers (if you don't get into intricate customization of your own). - it should be faster than the web app it replaces -- applets were often slow to load AND slow to run. - it shouldn't be controller by a single company. - it shouldn't be proprietary. - it should, if possible, cater to many programming languages. - it should play natively with the HTTP model, AJAX etc.

In other words, like a canvas element which has a full, comprehensive, standard UI library with tons of standard, pre-built widgets (not just the meagre web form controls), including a full featured text widget with all the trimmings, plus a free drawing component of its own (for totally custom UIs and controls).

However I started to feel the same way a few years ago when the HTML 5 wave started, after several years of doing web development as well.

And yet they never achieved a fraction of what "the current mess" has achieved.

Except it's horrifically slow. It was never designed for widespread dynamic update, and to work around it we have to go to great lengths like having a virtual DOM. Combine that with the widespread incompatibility of different implementations, and I have trouble seeing it as a good UI framework at all, let alone a superior one.

http://www.javascriptkit.com/javatutors/closuresleak/index3....

The last example is a good demonstration that. Sure, at the end of the day it's all about not cleaning the references. All I'm saying is that it is super easy to accidentally not clean the references. In other languages or even in javascript itself without the DOM, it's not nearly that easy.

Back in 2005 Gecko (Firefox) had issues like this too, but a cycle collector was added in 2006 that handles this sort of problem.

For DOM nodes issues like this basically don't happen in modern browsers.

There _are_ still some existing bugs of this sort in browsers for objects other than DOM nodes (especially WebKit and Blink; modern IE and Gecko are way ahead here, though Blink is actively working on fixing this in their implementation). But you typically have to work quite a bit to hit these cases; all the common cases are handled correctly because otherwise pretty much any web site you left open for an hour or two would use up all the RAM on your machine.

I do agree that if you have to worry about compat with old/unpatched browser versions then you run into some serious problems with this sort of thing. If you have to deal with that, you have other serious problems too, of course.

And, again, the source of all the "leak while the website is live" behaviors I have seen recently is websites doing things like sticking more and more stuff in global arrays. That's just a basic no-no in a garbage collected language, obviously.

https://github.com/pypyjs/pypyjs/issues/145

1) "For addons only" is an important qualification. It means you don't have to worry about sandboxing at all, since addons are already all-powerful (or at least were at the time).

2) It added a _lot_ of complexity throughout the DOM. There are tons of places in the web platform that basically assume you have a "JS value" and things fall apart if that's not the case. Most simply, what happens if python code sets document.body.onclick and then JS code reads it, or vice versa? It's possible that this complexity and the resulting performance impact is worth carrying around if the use cases are compelling enough, but they just weren't.

3) The python implementation in question did not have a good solution for the problem of cross-language cycles. Those were solved for JS and C++ in Firefox by creating a cycle collector that tightly integrates with the JS GC and the refcounting system the C++ side uses. But that was only possible due to full control over the JS GC implementation (and hence the ability to change it to flag objects as "only owned by C++ stuff" and whatnot). Doing the same thing with Python would be a nontrivial undertaking, just for the C++ and Python bits. Dealing with cycles that involve all three languages would be _quite_ hard.

    <script type="text/vbscript">
       Sub link_onClick
          ' Do some processing!
       End Sub
    </script>

Closest I've come to JS client and server was with ActionScript via Flex/Flash and VB.Net on the server... having XML literals on both sides was really nice, though I prefer JS on both ends... I don't miss C# much at all.

Edit: rfk addresses this directly around 46:00 in the interview. Paraphrased: "The big trade-off Brython does to get good performance is the number model. Things there map pretty directly to JavaScript. But if you overflow or do something different, you suddenly won't get Python's semantics. If you're writing new code for Brython, it's a good set of trade-offs, and in some ways you get tighter integration with the browser and the DOM. But if you're trying to take some existing code off the shelf and run it... you're more likely to run into issues."

Abstract:

> PyPy.js is an experiment in building a fast, compliant, in-browser python interpreter. By compiling the PyPy interpreter into javascript, and retargeting its JIT compiler to emit asmjs code at runtime, it is possible to run python code in the browser at speeds competitive with a native python environment. This talk will demonstrate the combination of technologies that make such a thing possible, the results that have been achieved so far, and the challenges that still remain when trying to take python onto javascript's home turf.

> We'll cover: an overview of PyPy and why it's a good fit for this type of project; an introduction to asmjs and the rise of javascript as a compile target; what it looks like when you smoosh these two technologies together; a comparison with other approaches such as brython and PythonJS; and some concrete suggestions for how the result might be useful in practice.

The short of it is that I wouldn't trust Brython to handle edge-cases that PyPy.js will, and that PyPy.js is at least as fast for me when warmed up. That said, I've lots of praise for the Brython project, and it's a way lighter dependency (both in size and warm-up times).

[1] https://www.reddit.com/r/Python/comments/33m7io/comparing_th...

https://github.com/WebAssembly/design/blob/master/README.md

Why do so many people hate the DOM? You need some kind of representation of the page, and the DOM is just a tree representation of it. It's not hard to access or modify from a program.

And why this sudden enthusiasm for running programs in the browser? Is it because Java applets and Flash have finally been removed from most browsers, and people needed those capabilities?

In the end, people are learning what works best... In the end it depends.. I think it comes down to being that people want cleaner application development targetting the browser.. I think modern node/babel/webpack apps are much better as a workflow (I also like React). However, I don't begrudge people wanting to target other environments.. I think source maps go a long way to making it nicer to do in practice.

I'm also appreciating the resurgence of more FP concepts over OO everywhere... Outside of controls/components, I don't think classes work well for most JS needs.

[1] http://www.scip.ch/en/?vuldb.12180 [2] https://www.mozilla.org/en-US/security/advisories/mfsa2015-2...

Imagine you're a scientist, and you have a large, pure python codebase - let's say for intelligently predicting the number of foos in a bar - and you want to make that available via the browser, in order to visualize the progress of your foo-hunter.

This makes it a trivial task - and means you can use cool web-based visualization tools (D3, etc), and combine with other useful APIs.

Ruby, Python, Lua are in term of language design way superior. Coffeescript and co emerges because it was more reliable to have a complex stack than to use the JS language directly.

That's the only high-level language that produced this situation. Python/Ruby & co are not perfect but good/reliable enough. You don't program in a another language that compile to python to avoid its verbosity and its traps.

If python had been choosen for the browser, we would have used for the last 15 years : module, sane scoping rule, classes, iterators, etc. Yep, that's something that it ecma6 without the ugly baggage.

15 years, damn it.

So no, please give at least Python in the browser and let people experiments with other language design choices and let them find something superior to Python. At one moment, it will be obsolete like any other tool. I don't want to be forced to use it because it is the only choice.

No!

Languages (and language implementations) have different strengths and weaknesses. No one language may hope to serve all needs equally well. While for what you do your single language may be sufficient, there are people and use cases where it's better to use something different.

I'd rather embrace the diversity than try to artificially limit available choices.

Tech demos/toys are an interesting distraction for a minute. Deep efforts to build a full execution environment warrant deeper attention.