baconjs / bacon.js

Functional reactive programming library for TypeScript and JavaScript
https://baconjs.github.io
MIT License
6.47k stars 330 forks source link

IE8- events not supported? #327

Open rassie opened 10 years ago

rassie commented 10 years ago

I'm maybe mistaken, but using Bacon.fromEventTarget fails in IE8 (and probably lower), since attachEvent is correct for pre-addEventListener IE. attachEvent is also nowhere to be found in source, so I wonder whether IE8 and lower is supported at all (at least IE8 would be nice).

raimohanska commented 10 years ago

You're probably right in that fromEventTarget fails with legacy browsers, because it was never meant to be compatibility layer. It only works with event targets that support either bind/unbind or addListener/removeListener.

Personally I prefer using jQuery to get compatibility right.

rassie commented 10 years ago

Hmm, I prefer not using jQuery whenever possible, but mileage differs for everyone :) I also understand the hesitation to introduce legacy compatibility quirks. So I've solved the problem from the other side (for now): I've taken one of the numerous addEventListener polyfills for IE8 and everything seems to work fine.

But thinking further: since you've got #319 in the pipeline, do you think asEventStream or fromEventTarget belong to the Bacon.core? I've had the impression that Bacon is for the most part runtime independent (which core should probably stay), so the parts which are not are probably pretty small and could be implemented for different runtimes. The idea is to have an implementation for Node, jQuery, vanilla DOM, IE-compatible DOM etc. I have no idea about the complexity of factoring this out, but I would happily use Bacon.core with a custom adapter for asEventStream while everyone else can continue using Bacon.jQuery or Bacon.YUI or whatever framework gets used instead of jQuery in any particular project.

philipnilsson commented 10 years ago

I think a polyfill is a great choice here, and it would definitely be nice to be able to link to a library that would contiain any polyfill needed for bacon to run on legacy browsers without jQuery (what else is missing?).

Still, it's important to help the adoption of Bacon that you can easily start playing around with it, and the jQuery integration is a good way to do that since it's so familiar to many. There's of course also data available that shows jQuery's extremely wide adoption across the internet, so I'd argue it deserves its special place in Bacon core under current circumstances even if it's not needed by everyone. It's not many lines of code.

On Thu, Jan 23, 2014 at 10:59 PM, Nikolai Prokoschenko < notifications@github.com> wrote:

Hmm, I prefer not using jQuery whenever possible, but mileage differs for everyone :) I also understand the hesitation to introduce legacy compatibility quirks. So I've solved the problem from the other side (for now): I've taken one of the numerous addEventListener polyfills for IE8 and everything seems to work fine.

But thinking further: since you've got #319https://github.com/baconjs/bacon.js/issues/319in the pipeline, do you think asEventStream or fromEventTarget belong to the Bacon.core? I've had the impression that Bacon is for the most part runtime independent (which coreshould probably stay), so the parts which are not are probably pretty small and could be implemented for different runtimes. The idea is to have an implementation for Node, jQuery, vanilla DOM, IE-compatible DOM etc. I have no idea about the complexity of factoring this out, but I would happily use Bacon.core with a custom adapter for asEventStream while everyone else can continue using Bacon.jQuery or Bacon.YUI or whatever framework gets used instead of jQuery in any particular project.

— Reply to this email directly or view it on GitHubhttps://github.com/baconjs/bacon.js/issues/327#issuecomment-33173768 .

Philip Nilsson, +46 2922 4651

antris commented 9 years ago

So jQuery is a required dependency now?

On "Dependencies" section it says:

Runtime: jQuery or Zepto.js (optional; just for jQ/Zepto bindings)

If jQuery is optional, I would assume that fromEventTarget works cross-browser.

In "Browser support" section of the docs:

Bacon.js is not browser dependent, because it is not a UI library.

I have personally used it Bacon.js with Chrome, Firefox, Safari, IE 6+, iPhone, iPad.

Automatically tested on each commit on modern browsers and IE6+.
raimohanska commented 9 years ago

fromEventTarget supports a few method pairs, and jas never been tested on IE8 before. Jquery is not required as you very well known, having run the lib on node.js already. Personally I've used jquery if legacy browser support is needed. Pls post PR to add IE8 support.

RyanAtViceSoftware commented 8 years ago

Hi all, I'm just starting to play around and evaluate BajonJs as a tool\approach to recommend to my clients, some who are very large, but I'm currently stuck on this JQuery dependency. I realize that JQuery isn't required but my experience so far with trying to evaluate this tool has been very slow because the tutorials all favor convenience methods that don't work if you don't start with a JQuery selector object. I also don't align well with this sentiment.

Still, it's important to help the adoption of Bacon that you can easily start playing around with it, and the jQuery integration is a good way to do that since it's so familiar to many. There's of course also data available that shows jQuery's extremely wide adoption across the internet, so I'd argue it deserves its special place in Bacon core under current circumstances even if it's not needed by everyone. It's not many lines of code.

Virtual DOM frameworks are becoming really popular and I think creating these APIs using pure DOM methods would be beneficial to that rapidly growing group. I don't want to have to pull JQuery into my react app just for BaconJs. So I would benefit greatly @rassie recommendation

I've had the impression that Bacon is for the most part runtime independent (which core should probably stay), so the parts which are not are probably pretty small and could be implemented for different runtimes. The idea is to have an implementation for Node, jQuery, vanilla DOM, IE-compatible DOM etc.