The generator example has no error handling (at least not from what I can see).
Once the "callback hell" example was re-written with named functions, it is not much different than the generator example and depending on how you are testing, easier to test because it separates out IO from logic (Which you could still do in the generator example).
One thing callback style code has begun to make me think about is the nesting/IO complexity of the functions a I write. When you nest, the IO/event boundary is visible in the code (by the indentation). As you continue to nest, you can start to get a clear idea of the amount of IO being done and where a particular function may be doing too much. Anyhow, most of this is preference anyway :)
jQuery would be great if it broke up all those tiny little and completely orthogonal things it does into modules so that people could use them as needed. No one library is going to provide everything for every project but making everyone require your ajax code when all they wanted was an `offset()` function is equally backwards thinking. We have much better tooling now to work with modules and to reuse code.
Arguments about CDN caching are some sort of premature optimization (or I don't know what really). Most early projects don't need it and other projects can trivially use many of the free (or super low cost) CDN providers if they care that much.
My issues with jQuery are not at how awesome it has worked in the past or how well it has hidden/handled lots of browser quirks; it is that thinking in terms of "everything is dom manipulation" is the wrong abstraction for doing organized and maintainable front-end code. The things jQuery does well would be useful within smaller components or libaries but now we are back to the original issue of jQuery is one giant blob.
OMG, you should file a ticket for jQuery core to implement some kind of system for breaking up the source into modules!! Here's a link: https://github.com/jquery/jquery#modules
As long as every jquery plugin and other code that depends on jquery continues to require all of jquery, all this module stuff is useless. I am sure it helps you organize jquery Dev but it still doesn't help actually define real dependencies on a per component basis.
Personally, I don't think you can simultaneously use tons of plugins and also complain about being forced to include jQuery. If you don't have the time to roll your own, then you probably don't have the time to prototype Array ten times again for missing features in various clients.
So just ship your code along with the specific jQuery modules that you want to use. The fact that there isn't a better way to do this is a fault of javascript, not a fault of jQuery.
The natural way to code is that you sit down to do a task, and you set out to do that thing in the most direct way possible, then you are done. The insight that more advanced coding techniques can metaphorically collapse space entirely and make the sum journey shorter tends to be something only picked up after years of experience... if that.
Bashing DOM nodes together to do a task is merely one manifestation of this. Multi-thousand line functions, code that makes thousands of queries to a DB and manually performs some enormous task that could have been more easily done in three slightly more complicated ones, code that just flings open a socket every time it needs to do something on the network and just starts stuffing bytes at a remote service... it's all manifestations of this.
I don't have a good word for this. I wish I did. Probably something buried on C2 somewhere if I poke around hard enough.
> Bashing DOM nodes together to do a task is merely one manifestation of this.
I suppose that's what I was getting at originally. There's absolutely nothing that removing or adding jQuery will do to impact the larger problem of treating client-side development as software engineering instead of incoherent scripting. None of the advice on the originally posted site would change those organizational/logical problems.
These are the things that get cleared up by code reviews, break sprints, bug hunts, periodic refactoring… in many cases, YANGTNI applies. That's not an excuse for long-term sloppy code, but it's an excuse for developing good practice when making changes to an existing codebase.
Fuck the future. JavaScript was formed full and feature complete and these newfangled "improvements" are nothing but abominations atop its pure and perfect form.
I run a similar service for other schools (courseoff.com) and I have run into this before. I bet what happened was their site failed to cache the course data or seat information and was thus making lots of requests to the Yale servers. To Yale it might appear like a DoS from this site.
Obviously I don't know for sure but I would venture to bet this block was more an automated response than malicious intent against the site.
The issue isn't that Yale cut off the sites access to the school's servers. The issue is that Yale cut off their students access to the site. Furthermore Yale and the site were apparently in dialog before the block, and Yale raised copyright concerns (probably bullshit, unless they were copying course descriptions or something like that (I suspect course descriptions were involved initially): http://en.wikipedia.org/wiki/Sui_generis_database_right#Unit...).
It's not DoS, you don't present a splash page for offenders in that regard. I know the platform (PAN-OS) very well and that page is a URL filtering profile splash. It's actually a custom URL category (shown at bottom) that they can update via white and black lists.
> Over 2,000 students out of a campus of 5,000 were using it as of today noon, when the Yale administration began censoring it using traffic inspection. They had contacted us warning that we were using copyrighted data.
It doesn't seem automated, and if there was a DoS wouldn't they just go out and say so?
This is very unfortunate that they are doing this if the data was scraped and not hitting their servers. Is it that some part of the data they think is copyrighted (like grades) versus just courses?
You don't have to trust anything. If you want to NIH everything yourself, nothing is stopping you. It is however more likely that many packages on NPM are better than the ones you or your team can create if simply for the fact that they may have been created by a person very versed in the particular domain the package is for. Or maybe it will be shit but whatever :)
I have no such reservations about the NPM/CPAN style, but your assertion that the only other choice is "NIH" isn't quite true. With Python for instance, you can choose SQLAlchemy for your ORM. It has no depencencies. In JavaScript, Mongoose (a good comparison) depends on "hooks, mongodb, ms, sliced, muri, mpromise, mpath, regexp-clone, mquery". Who knows what those in turn depend on. In a strict place, you need to get every one of those things approved, and each represents a moving target if you want to upgrade Mongoose later. Those shops begrudgingly let open source in as it is, so it's a tough sell.
IMO bug bounty payouts are a more effective use of funds for a project. Paying per commit is like paying per line of code. At least with a bug bounty you (the giver) can specify which particular item interests you. If you want to donate money to the project as a whole, then it seems easier to just communicate with the project owner/maintainer and send them funds directly.
Because writing plain javascript is simpler for the majority of people to understand and will run in more places without the need for custom setups. Module authors will not write to these custom implementations since it would greatly limit the audience for their module.
(Full disclosure: I am, in fact, using Node now, and there is nothing quite so painful as the lack of coroutine or fiber or thread support. Cluster is cool, but only if you want to make a bunch of processes.)
I don't necessarily want threading in Node.js, but it would be nice to have coroutines/green threads...something simple that scales across CPUs, at least. Unfortunately with JavaScript I think the best you're going to get is Node's cluster module, because of the threading limitations with V8 and other JavaScript engines. Realistically, it's a trade off - Node.js is easy and quick to work with, but the only way to take full advantage of the machine's processing power is through forking processes.
Seriously, green threads with yield() and autoyield on blocking operations would be great. Sometimes the easiest way to write a program is to present it as a logical flow of events, and let the machine/operating environment hide the async nature of life from you.
Then again, that would mean reinventing (again) core OS functionality in Javascript. Le sigh.
Lots of problems can be solved with one language depending on the language. And I have worked on several single language stack projects. Having a single language stack has many benefits. Right too for right job is only relevant if the right tool doesn't do many jobs good enough.
