4

I know some Javascript, but just realized I know very little about cross-browser issues. Nasty little things like the this object in event callbacks in IE (as in xhr.onreadystatechange = function () { ... }) not referring to the object the function is applied to, but instead to window, which is not exactly useful.

There's an impressive and comprehensive-looking list of differences here on SO.

Is there also a library that covers these nasty cross-browser issues without selling you a whole lifestyle plus round corners with slide effects? I know jQuery is great (and modular, I know, UI coming as an extra; and I bet others are great, too), but I'm looking for something lean, closer to the roots. Just doing the minimum and eliminating the nastiness. Doesn't have to wrap the DOM in sugar.

Update

Thanks everybody for your suggestions. I'm going to take a look at MyLib, microJS, Ender, and Sizzle. GWT, while certainly being cross-browser, is not, I think, a lightweight approach, but definitely an interesting one.

Community
  • 1
  • 1
Lumi
  • 14,775
  • 8
  • 59
  • 92
  • What you want most is a highly supported and documented library because without either of those, you will have trouble using it and it's usefulness will fade over time. IMO, that is going to lead you to the market leaders such as jQuery, YUI3 and a few others even though they may offer more than you think you need. There are caching reasons for using a popular library loaded from a popular CDN too that will help your page load quicker. – jfriend00 Aug 02 '11 at 23:34
  • @Lumi Could you elaborate why jQuery is not close enough to the roots for you? It looks like it's as close as it gets to me... – Šime Vidas Aug 02 '11 at 23:49
  • 1
    @SimeVidas jQuery is a large bloated library. You only use 20% of it. – Raynos Aug 02 '11 at 23:51
  • @Raynos But since the dependencies are linear, cant you go into github and essentially cut off the dead weight by only including code up to module X? – Moses Aug 02 '11 at 23:58
  • 1
    @Moses no. jQuery is not modular. It's all, sizzle or nothing – Raynos Aug 02 '11 at 23:58
  • @Raynos You're right. Those 31KB are totally slowing down my 4Mbit flat connection. Not to mention those 20ms required to execute the code. Why am I putting up with this?! `:)` – Šime Vidas Aug 03 '11 at 00:05
  • @SimeVidas jQuery from cache 400ms. jQuery no-cache 1.3s. That's _HUGE_. – Raynos Aug 03 '11 at 00:13
  • @Raynos Loading from Googleapis: 40ms from cache, 80ms no cache. Execution on my machine: ~20ms. TOTALS: 100ms for first page, 60ms for subsequent pages. – Šime Vidas Aug 03 '11 at 00:29
  • @SimeVidas we don't all have great internet connections. Please don't take Mbit connections for granted. This should be thought of as a developer. – Raynos Aug 03 '11 at 00:35

6 Answers6

3

What do you want?

Just check microJS and download the libraries you want.

As mentioned already you can use Ender to bundle them

Raynos
  • 166,823
  • 56
  • 351
  • 396
3

jQuery is not modular - it's all or nothing. If you want a solid, cross browser library that you can trim to the minimum you require, it's hard to go past MyLibrary: http://www.cinsoft.net/mylib.html.

The name "MyLibrary" means that when you download and customise it, it becomes your library.

It is absolutely solid, fast and extremely modular. You can use just the bits you want and remove anything unnecessary.

BTW, many libraries like jQuery aren't really "cross browser", they are multi–browser — they have a limited set of browsers that they support and don't care much about the rest. On the other hand, MyLibrary is written to be genuinely cross–browser. It also provides excellent feature detection shortcuts so you can easily write robust code with fallback.

RobG
  • 142,382
  • 31
  • 172
  • 209
  • "genuinely cross–browser" feels like a waste. Who cares about NN4 bugs – Raynos Aug 03 '11 at 08:48
  • Thanks, @RobG. You typed more characters than others, so I've accepted your answers. :-) Seriously, I realize my question has triggered a couple suggestions that I need to study further. Thanks all for sharing your experience. – Lumi Aug 04 '11 at 20:55
  • @Raynos—dealing with bugs in old browsers is an excellent way of ensuring your code is robust. You can't predict future bugs, but if you've dealt with all the old ones, you can approach the future with much more confidence. – RobG Nov 23 '11 at 02:21
  • @RobG ... So hacking around really obscure, old and broken behaviour actually increases future proof-ness? I doubt it, highly. There is nothing wrong with multi-browser libraries. – Raynos Nov 23 '11 at 02:34
  • `So hacking around really obscure, old and broken behaviour actually increases future proof-ness?` Yes, not because of the "hacks" but because the code is thoroughly tested and usually provides highly compatible fallbacks. The problem with multi-browser libraries is that they need constant updates for new browsers and they randomly decide it drop support for old ones. – RobG Nov 23 '11 at 04:52
3

"Minimal cross-browser Javascript library" + "I'm looking for something lean, closer to the roots"

I immediately thought of MyLib.
You can even build your own custom version using this online tool.

Knu
  • 14,806
  • 5
  • 56
  • 89
1

I think you should have a look at Ender By Dustian Diaz and Jacob Thornton working at Twitter.

Ender is not a JavaScript library in the traditional sense. So don't rush out and try to replace jQuery or MooTools with Ender... It just wouldn't work.... But! you can build a library from Ender which will. And you should. right now.

That's because: Ender is an open, powerful, micro-to-macro API for composing your own custom JavaScript library; it wraps up application agnostic, independent modules into a slick, intuitive, and familiar interface so you don't have to.

Alfred
  • 60,935
  • 33
  • 147
  • 186
0

Well the problem with this in JavaScript is that it can be a bit confusing to people which are not accustomed to the fact that it always gets a contextual value or in other words it will always point to the object which is in the current context of the executing code.

In case of some events, intervals etc. its absolutely normal that this points to window because a LOT (perhaps too much) of properties in JavaScript are attached to the window object.

As for which JS library to use for your work...Well if you don't want to use jQuery as a whole there is always the most important part of it which handles selection of objects inside DOM and is pretty much important for cross browser compatibility.

Its called Sizzle and can be found here. It doesn't offer fancy stuff like jQuery does but it is small and offers a great cross-browser way to select stuff on pages.

  • The comments on *this* are incorrect and misleading. It is not "context". What confuses those new to javascript is that it is set by how a function is called (and can be set to whatever value the caller wants) and not by the function's declaration or initialisation. So its value may not be what is expected for those who don't know how it works. – RobG Aug 03 '11 at 02:03
  • @RobG I don't know about your understanding of the word "context" but I am pretty sure that every book you'll find out there on JavaScript refers to the state of the currently executed code as context. It a completely different thing how context changes are made, either through function calls, closures etc. –  Aug 03 '11 at 02:12
  • there is an execution context described in ECMA-262 that includes many things, including the scope chain, execution/variable object, variables and parameters and so one. One item in that context is the *this* keyword, it is essentially a reserved local variable. To say it represents context is misleading, it is one component of a much larger concept. It's value tells you nothing about the function, its context or even how it was called. – RobG Aug 03 '11 at 14:02
  • @RobG How about you read my post again (thoroughly this time) and tell me where I even remotely said that **this** points to the "context" of anything? I said `"it will always point **to the object** which is **in the current context** of the executing code"`. If that doesn't sound different enough than sorry I can't make it any more clear. –  Aug 03 '11 at 14:29
  • @holodoc, @RobG, it's not `this` per se which is confusing to me. I know that stuff. And also the JS funkiness provided by `apply()`. What's confusing to me is that given `xhr.onreadystatechange = function () { ... }`, unlike FF, which behaves as expected, IE does not apply the handler to the `xhr`, but to `window` instead. I think you can see why it isn't expected. This is something you'd want evened out by a library. – Lumi Aug 03 '11 at 14:59
-1

You can look at GWT.. but it does sell you a lifestyle as well - a Java dev environment. But that also brings in a debugger, a proper IDE, easier OO, it compiles to optimized cross-browser javascript etc. And you can always mix and match native JavaScript where you see fit.

filip-fku
  • 3,265
  • 1
  • 21
  • 19