Slashdot Mirror

1) Sharepoint works in FireFox. Quite well in fact.

2) If you want to use some of the IE-only features, just install this extension, and add Sharepoint to your IE-only whitelist, and you can use the "IE-only" features from within Firefox.

3) Microsoft's official recommendation for Web UIs is now to use JQuery (and they're also contributing code to the project!). Assuming they eat their own dog food, Microsoft webapps should start being a lot more friendly toward non-IE browsers.

Go and listen to the Official jQuery Podcast from 12/18/2009.
It features, Rey Bango, the Head jQuery Evangelist. He explains the how/why/what of evangelism for the jQuery project.
Excellent stuff.
http://blog.jquery.com/2009/11/13/announcing-the-official-jquery-podcast/

JQuery 1.4 alpha 2 just came out and the final version is scheduled for Thursday.

I like jQuery more because... um... well, actually, I just like it more. Feels easier to use. MooTools has a steeper learning curve, and I can do what I want to in jQuery without that learning curve.

Incidentally, although it is highly dependent on the browswer running the test, jQuery often feels faster. But run the tests yourself. And while speed is one thing, accuracy is another, and it all depends on what kind of work you do.

It gets really irritating, though, when I see a web site using both MooTools and jQuery on the same page, just because the designer/developer liked a particular plug-in for that page. I'm sure the client never notices.

One really simple way of doing it is (as a previous poster suggested) having the client send an AJAX call signifying that the document is still open. So, when I click "Edit" on "shopping_list.txt" it's database entry gets it's "edit_by" set to my userID and "ts_editing" field set to unix_timestamp() (for mysql or time() for php). The edit-page sends an AJAX request every.. say.. 30 seconds to a file that updates the timestamp.

Now, when you list the available files, you will see that I am editing "shopping_list.txt" because it's current "ts_editing" is larger than (unix_timestamp() - 60). At most 1 minute after I leave the editing page, either by saving or by closing the window, the document will become available for editing again.

If you are uncomfortable with JavaScript, check out jquery. In fact, check it out, even if you consider your js skills to be badass. The code for updating the editing-timestamp can be as simple as follows:

function updatelock()
{
$.get("updatelock.php");
}

$(document).ready(function() {
setInterval("updatelock()", 30000);
});

Assuming you set the flags mentioned earlier upon opening the file for edit, updatelock.php really only needs to do a
UPDATE `files` SET ts_editing = UNIX_TIMESTAMP() WHERE edit_by = $_SESSION['userid'] AND ts_editing > UNIX_TIMESTAMP() - 60
(updating the timestamp on anything you temporarily own that hasn't timed out) or something like that. =P

I largely agree, although for an internal application I think JavaScript can be an assumed capability. It's actually not a lot of work; it could probably be implemented in a couple of days with some investigation into jquery and some minor DB changes ;).

What browsers need is a workable CSS and DOM interface (although the DOM interface has improved in recent years).

Jquery makes working with the DOM incredibly easy. It completely changed and radically simplified nearly all of the Javascript that I write. If you haven't explored it, you should.

You could make casual games about as easily with javascript libraries like jquery or prototype/script.aculo.us as you can with flash these days. Its probably preferable considering there is no need for proprietary tools or learning actionscript...

Most of the pain of the DOM can be circumvented by using JQuery. Try it, grok it, and never think of Javascript the same way again. It makes it more of a declarative thing, like SQL. Super small and short code. I wouldn't want to write everything like this, but it's amazing for what it's designed for.

Actually, I'll mildly disagree with you on this one: It *would* be nice for CSS to be able to do simple math, although JavaScript is perfectly adequate for the task.

Of course, JavaScript has more than a few of its own irritating deficiencies, although JQuery makes the language considerably more tolerable, and makes CSS manipulation a breeze. JQuery should have been part of JavaScript from the start!

Of course one of the reasons is because I'm using text compression to about 5% original size, whereas javascript/executables barely compress at all.

Nope, I don't buy it. jQuery is an extremely popular "big" JS library. The current version is 120KB uncompressed and 19KB compressed. A common sortable table library is 9,544 bytes uncompressed and 3,242 bytes compressed.

Slashdot itself embeds small amounts of JavaScript in the comments page so you're downloading those whether or not you have JS enabled. It additionally includes jQuery, but if your browser is fetching that more than once, something is misconfigured.

In short, there's no way JavaScript should have a perceptible impact on download speeds, even over dialup.

Note: first modem was 300 baud; I'm keenly aware of slow downloads. This just isn't one of them.

That completely breaks the OSS model, though. That is: Sometimes, I see a project I like, but it needs a little work. If it's a tiny patch, I'll just do it all locally and send it in. But if my patch is rejected, or it's likely to be a bigger contribution, I'll create a public fork -- easy to do with something like Github -- and publish my changes there.

This also has the nice side effect of simplifying the problem of finding a new maintainer, for a smaller project -- you've already got at least one fork, probably several that might even be sharing patches, so if the original developer goes AWOL, the project is still alive.

All of these work whether I'm doing purely open source stuff, or whether I'm working on a proprietary project and contributing back.

If it's MIT, BSD, GPL, etc, all of this is possible. If I've had to license it commercially, then I can no longer share my changes -- we're now back to the bottleneck of the original creator, in this case, of exactly one person. And adding money to the equation makes it even less likely that these changes will make it back in.

In fact, I'll give an example: extjs was under a more permissive license. It switched to GPL, and tried to claim that the GPL applied to the server, and not just to the JavaScript client. Although we had paid for a commercial license before the GPL switch, we dropped that thing in a matter of weeks -- we just didn't need the uncertainty of a framework tightly under the control of an asshole. Instead, we use jQuery, which is dual-licensed under MIT and GPL, isn't going anywhere, and ended up being closer to what we needed anyway.

And while I don't know of any patches we've sent back to core, we did publish one or two extjs plugins, and there was a fair chance of publishing jQuery stuff.

Browser incompatibilities are not the fault of javascript. And no, it's not Java or C and that's a good thing. Get yourself a javascript library and quit complaining.

I'm sorry but I just can't stand developing in Javascript.

Why write in Javascript when you can use a library like jQuery or toolkit like GWT that spare you the messy details of working in straight JS and take care of cross-browser compatibility?

I guess one answer would be, "because they don't support HTML5." Anyone know the status of HTML5 support/compatibility in these JS libraries and tools?

seriously, RTFM . This code registers an onclick callback to objects with css class cat. Try doing that with the built in dom methods in less than 10 lines of code.

You really think I was gonna fill in the guts of a sample function? .click() hooks the onclick event.

There is already plenty of Javascript in use with free licenses, such as GPL and MIT. The main practical advice from TFA is to make it easier for users to see which license Javascript code is under simply by putting the license terms in a comment, which sounds great to me. Are you saying more transparency is a bad thing?

learn jQuery.. one of the best lib ever made for javascript! http://jquery.com/

I can't help but think that all of these JavaScript/AJAX libraries keep reinventing the wheel over and over again. How many grid widgets written in JavaScript do we really need? How many toolkits for a progress bar or a div-based dialog box have to be developed? Is one of them really that compelling over the others. Consider:

http://dojotoolkit.org/ - DoJo Toolkit
http://www.activewidgets.com/ - ActiveWidgets
http://www.prototypejs.org/ - Prototype
http://script.aculo.us/ - Scriptaculous
http://jquery.com/ - jQuery
http://extjs.com/ - Ext JS
http://developer.yahoo.com/yui/ - YUI
http://code.google.com/webtoolkit/ - Google Web Toolkit (GWT)
http://www.sproutcore.com/ - SproutCore

Those are just the ones I have used personally. It's getting ridiculous. Personally, I like the approach GWT has, but of course that's only relevant to the java developers of the world. I'd love to see all of these "widgets" be compatible with one another.

I was recently looking for a javascript library to help solve cross browser issues with accessing ASP.NET based web services. The main interest was DOM traversal, simple GET/POST/SOAP requests, and XML parsing. I looked at a bunch of different frameworks, but finally settled on jQuery. It had everything that I needed in a small package with excellent support for plugins and add-ons. We ended up using an XML to JSON converter plugin since parsing arbitrary XML can be a pain to do in a cross browser world. Keep in mind that we did not use any of the UI or effects portions of the libraries, but if you are looking for an easy way to create javascript that will work in most major browsers I suggest jQuery.

That's why he said the purity of it is debatable. Were it a "pure" functional language there would be no first-class objects but functions. Obviously that's not the case in Javascript, but it is a functional language in that it can be used in that style. Also, neither Python nor Perl count because you cannot define anonymous functions in either one.

This is an important distinction. In Python you can say "lambda x: 2 * x" and what you've got there is a lambda, but it is not a function; it's just an expression. In Javascript you can define actual, for real, bona fide functions and pass them as arguments inline, like so:

foo.prototype.bar = function (baz) {
do_something(baz);
do_something_else(baz);
return something(baz);
}

In Python you'd be restricted to kludging that all into one function (yes I know you can use boolean operators to trick it into doing multiple statements in the same lambda expression, but that's cheating and won't work all the time because the boolean operators short-circuit on a false return value).

Check out jQuery to see what it looks like when Javascript is written the right way.

Kinda obvious (no more obvious than php.net being the best reference for php I suppose), but: http://docs.jquery.com/

Jquery makes it easy to work with different frameworks.

http://docs.jquery.com/Core/jQuery.noConflict

- A well defined way to say "The page is loaded, all your variables and objects are loaded, Time to execute!" rather then "You can only see the variables and objects that are defined 'above' you and not 'below' you in unloaded portions of the page".

jQuery's $().ready( function() {...} ); method has been a fantastic help in my Javascript development. It executes after the DOM has been initialized, but before all of the images have been loaded. window.onload() waits for the images to load, which delays your javascript from running until after the page has been rendered. jQuery doesn't do that; your code will often run before the page is rendered, so you can use javascript to enhance/replace elements that work without javascript too. For example, I often have UI controls which will refresh the entire page to perform their function when javascript is not enabled, but they'll use AJAX and refresh only the necessary elements if javascript is enabled. Using jQuery, I can attach events and alter CSS classes before the user sees the page, so javascript and non-javascript users get somewhat different looking, somewhat different behaving, but always fully functional views of my application.

For those who think the Selectors API is a nice addition: It's already possible, cross browser, with the jQuery javascript library available at:
http://www.jquery.com/

Besides combining XPath with JS it allows for chaining commands, various typical DOM actions such as .remove(), .after()/.before() (insert HTML before and after), .attr(), .html(), .hide(), .show() and others. The frontpage of the site quite nicely demonstrates how to use it.

I have yet to see a project where I don't find jQuery useful. It's small it's lean and it gets the job done.

JQuery

I spent a month using it to build something in April 2007, and it was a big ol' pain. Getting something that roughly worked wasn't too bad, but there were a number of bugs and quirks that cost me time and headache.

Also, their rendering components generated an awful lot of hard to manage HTML and CSS. There were several display issues I never got quite right, and when I asked a front-end whiz to help me out, he had some very unkind things to say about the generated code.

My end impression was that it was about 0.7 in quality, needed a lot of polishing, and was really only useful for Java people who didn't want to understand what was actually going on in the browser. Were I to do that project over again, I'd instead just use something like JQuery, and learn how to do JavaScript properly, rather than hoping a framework would save me from my ignorance.

The USL/BSDi suit was settled in 1993. At that point Linux was still merely an interesting toy. It then caught up with and surpassed BSD's huge head start--because almost all work on Linux actually benefits the entire community, while the best work on BSD and SysV was entombed behind the walls of Solaris, HP-UX, and AIX.

Which big companies are contributing to jQuery, and how much? The Contributors page names a grand total of just eighteen people, and doesn't say where any of them work (who had to be convinced to let them contribute).

The photo gallery demo on SproutCore.com fails to work on Opera - the right photo pane not even rendering. Although Opera isn't widely used, with its exceptional standards-compliance it's a great barometer for how compatible something may ultimately be.

It's an interesting idea, and maybe I'm missing the "awesomeness" of it, but I don't find a compelling reason to switch to this over a standard development stack. It just seems as though it's a highly widgetized javascript framework, running on ruby.

I develop in Rails and C#, and I'd just as soon use jQuery and it's host of extensions to build my own application like widgets that I could use across any backend.

I've looked through the documentation and I'm hoping I'm just missing something about SproutCore's awesomeness.

Actually this is a better example.

And if you still want to use jQuery for other JavaScript interface joy, it can handle JSON natively. (Other frameworks probably do too, I just happen to be a fan of jQuery.)

Seems odd to use languages that weren't really designed to be embedded in a browser. One of the nice things about Javascript in the past couple of years has been the great DOM support. Add a library like JQuery and you have full cross platform goodness and a sane way to write code. Getting Java or Ruby code to interact with the DOM seems like it would be a huge pain compared with JQuery.

Why does everyone hate Javascript so? If you're going of cut-n-paste examples from the web yes it looks like an ugly language. Check out how the OO stuff works, or some JQuery code, and you'll be pleasantly surprised.

FYI, I've done ajax file uploads using jQuery. Works in IE6/7 and FF2/3. See jQuery and the jQuery form plugin.

For what it's worth... by starting off web design projects with Yahoo's reset.css and fonts.css (customized if necessary), by relying on cross-browser JavaScript frameworks like jQuery for any JS that modifies the DOM, and by being really careful about creating clean code that's easy to debug, I've reduced my IE5/6/7-specific coding headaches down to maybe 20-25 lines of IE-specific CSS.

I don't do that for every site, but this process makes cross-browser differences only mildly irritating, rather than showstopping.

If you run the MooTools Slickspeed tests in different browsers, you find something interesting:

• jQuery is the fastest JavaScript framework in IE6 and 7, and the slowest in FireFox, and middle-of-the-pack in Safari.
• MooTools is the fastest in Firefox and Safari, and slowest in IE.
• Prototype is generally slower than the others, particularly in Safari, and frequently doesn't perform the tests correctly.

jQuery also claims to be the most accurate, though who knows for sure.

Ok, point me to a place where I can pick up all the knowledge I need to use it, I've got a free afternoon.

Here are few options using my choice for a JavaScript library:

• Simplify Ajax development with jQuery
• API/Ajax - jQuery JavaScript Library
• Tutorials - jQuery JavaScript Library - Ajax

Ok, point me to a place where I can pick up all the knowledge I need to use it, I've got a free afternoon.

Here are few options using my choice for a JavaScript library:

• Simplify Ajax development with jQuery
• API/Ajax - jQuery JavaScript Library
• Tutorials - jQuery JavaScript Library - Ajax

Prototype and mootools suck, use jQuery.

Try the jQuery framework.

...or going to compatibility libraries (which is insane...

1. They trivialize tasks that developers use on a day-in day-out basis (hopefully to improve usability and accessibility).
2. They are (generally) well tested and have active support groups.
3. Less code!
4. In general easier to debug and/or maintain (in part due to reason above)

Try this instead of getElementsBySelector(): http://jquery.com/.
[code] var element = $('#some_id .some_class').get() [/code] would do the trick.
Not to mention the other really usefully things that you can do other than ".get()"

Sounds like you want Jquery. I've only been using it for a few weeks (I've been working on the Drigg javascript), but it's pretty damned cool.

For instance, to remove a particular class from all <p> elements:

$('p .someclass').removeClass('someclass');

To send each element through a javascript function:

$('.someotherclass').each( functionName );

You use CSS-like selectors to target actions.

If you add a class to an element, the browser correctly[1] displays the element with the new class applied. Remove a class, and the style associated with that class is removed from the element. It all behaves exactly as you asked. It's easy. It's intuitive, especially for folks familiar with both the DOM and CSS.

I have no association with Jquery. I just started using their library a couple of weeks ago. I've just been very impressed with their library, so thought I'd spread the Gospel to one who seeks.

[1] Except for IE 6, at least. There's a huge-ass bug in IE 6 multiple-class handling, such that multiple-class CSS selectors ('.class1.class2') don't work. Check out this writeup for more information.

What exactly is "bad" about JQuery?

Bad GUI standards? What does that have to do with JavaScript? If you can name a GUI standard within a single language that it better, please let me know. Certainly you don't mean Python's GUI since there's no standard there at all. It's the same story with C, C++, Ruby, Perl, Pascal, and all of the others. A notable exception is Java (aside from the AWT/Swing duplication), and a large number of people hate that. Name something better.

What's wrong with DOM/CSS, especially when there is nothing about JavaScript itself that's intimately tied with DOM/CSS. There's no reason within the language's constraints that an applications programmer couldn't integrate JavaScript with GTK+ or Qt.

As for debuggers, have you even used Venkman? Or are you still using alert() calls for your debugging?

I feel that DOM should be tossed and replaced with a relational equivalent

You mean some sort of method of accessing it via flexible symbolic queries describing attributes and relationships between nodes? One that retrieved arrays of matching results?

If only someone had invented such a thing. ;)

(To be fair, most of the other libraries have something similar as well.)

Mootools is simply faster, smaller, and more modular (read: well written) than the competition.

Faster, smaller and more modular? Firstly, if you are worrying about the speed at which your JavaScript executes, you are almost certainly either prematurely optimising or using way too much JavaScript. Only a minority of developers need to worry about that, even assuming older clients. Having said that, the release notes for jQuery 1.1.3 have some interesting notes regarding the benchmark you refer to:

• We're over 800% faster than we were in jQuery 1.1.2.
• We're the fastest framework in the most popular browser, Internet Explorer 6.
• We're the only framework that doesn't give incorrect results.

As for smaller, well jQuery is 26kb after packing, and the link you provide says that mootools is 34kb after packing, so I don't see how your link backs you up there.

As for more modular and well written, in what sense do you mean this? I skimmed over the website, and was struck at how mootools' site itself abuses JavaScript (major annoyance: don't use <div> s and JavaScript to badly emulate links when a real <a> element would do). I find it hard to believe that a project that makes basic mistakes like that would be well written, but if you would care to go into detail perhaps I might change my mind.

somebody is gonna ask.
 
  jquery This seems like a good place to start.

The great irony is that all the things that made LISP useful in the 50's now make it a near perfect language for today. Great abstraction, objects, super efficient compiled code, libraries. And yet ...

And yet ... a large chunk of those benefits are available in languages with a syntax much closer to C, and those languages are cleaning up. Ruby, Python, Javascript. Personally though, I'm starting to build programs in Javascript that coincidentally have a web-UI, simply because of tools like JSLint, and great libraries like Prototype (think doing Haskelly stuff in Javascript) and jQuery (think Web 2.0 without the pain).

We then use a standards-compliant well-documented library, jQuery, to add an onclick-handler to the link.

Absolutely, this design style, called Unobtrusive JavaScript (for those reading and learning something new) seems to have become a recent push since the whole AJAX thing exploded. It's well covered by the gurus of the field Jeremy Keith (talks about it in his book Bulletproof AJAX) and Peter-Paul Koch (ppk) of QuicksMode. I've not read his book, "PPK on JavaScript" but if it's half has good as his website, it would be a standard buy for any web person.

Speaking of jQuery, Jeremy Keith also lists the following JavaScript Libraries/Frameworks/Toolkits...

• Prototype
• Scriptaculous
• Mochikit
• jQuery
• YUI (Yahoo! User Interface)

The only way someone would be screwed with this solution would be if [...] I am not aware of even a single example [of a browser that could screw this up]

Right, while not all objects/functions are supported cross-browser, they usually work the same when they are supported. There's only one real concern about the world of "AJAX" and "Web 2.0" that Jeremy Keith pointed out in Bulletproof AJAX: screen readers. Apparently Screen readers are far behind in detecting dynamically updated content via JavaScript. JavaScript "could" be turned on and the page properly updated but the Screen Reader won't understand this and this is a big problem for those sites concerned with accessibility. In short, those who require screen readers should turn off JavaScript and allow the site (if properly designed with unobtrusive JavaScript) fall back to the full page refresh updates. However, I don't know if there's a foolproof (or bulletproof) way of making sure screen readers turn off JavaScript and it could be bad to assume one would be turned off (if your sites traffic has high accessibility needs).

Cheers,
Fozzy

For example, I've written a few web applications per client spec that required various effects, animation, windowing, and tab features. These are all things which are better left to Javascript, and in my preference, the jquery and interface libraries. In fact, there's no real way to accomplish most of those effects without client side scripting. Hell, even Slashdot uses Javascript in their comment system, Firehose, etc. Or look at Google Apps, GMail, YouTube. Not even possible without client side scripting. A well programmed client side script (like anything Google's coded) runs great on even a 500MHz Pentium 3.

Anyway, my point is that while I can understand minimizing client side programming, it shouldn't, and can't really be avoided completely. I personally love mixing client and server side programming to draw out the strengths in both methods. Just because the idiots at Digg can't program, doesn't mean the whole thing should be thrown out.