search

cemerick / austin

The ClojureScript browser-REPL rebuilt stronger, faster, easier.
510 stars 31 forks source link

Eliminate use of CrossPageChannel #50

Open cemerick opened 10 years ago

cemerick commented 10 years ago

This would address #17, #49, and #47, and beyond that, likely make any remaining mysterious connection/stalling problems either go away or be much easier to diagnose.

Implies writing a full replacement for clojure.browser.repl, though that's hardly onerous.

Options include:

  1. SSEs + XHRs
  2. websockets, e.g. https://github.com/tomjakubowski/weasel

Personally leaning towards (1) (easier to debug, accessible to more tools, etc), but that's not a done deal yet.

Biggest impact of this is Austin will cut its last connection to the stock ClojureScript browser REPL. Probably a wash in terms of maximizing stability vs. inheriting bugs / compiler API changes.

cemerick commented 10 years ago

Currently leaning towards "just use weasel". It seems to work nicely, websockets are supported in all JS environments that we care about (AFAIK), and it would keep me from having to implement another browser REPL environment :-P This turns Austin into little more than a set of convenience / ease of use utilties, but I'm quite okay with that.

ghost commented 9 years ago

I have been looking at Austin actually as an alternative to Weasel, as I seem to have occasional issues with websockets, the Chrome console spits out odd websocket-related errors and so I found myself wondering if Austin was instead using the more stable and old technology of Ajax (xhr). I can't find specific mention of the technique Austin is using and don't have the time to poke through its code just yet. This is not a question or anything other than a comment, that XHR browser repl is a valid need in the clojurescript world since websockets are still relatively new.

cemerick commented 9 years ago

Austin's current browser REPL env implementation is based on ClojureScript's "stock" browser REPL, which uses GClosure's CrossPageChannel for transport; this is based on XHR, but has other characteristics (including fallback mechanisms, IIRC) that make it compatible with very old browsers, even IE 6. The problems with it are significant, though, including subtle security context violations in some browsers/applications, as well as hard failures due to certain browsers' installed plugins/addons (see above-linked issues).

I see no reason for Austin's current browser REPL environment implementation to go away, it'll just not be the default anymore. So many others simply have a better experience and fewer problems with websockets, especially if the browsers being used are "modern".