@jjshabado,
How does rolling your own solution cause more negatives? Do you not understand the nature of how the jquery chain of death works?

First you attach a dependency to jquery itself, then you probably add a dependency to jquery UI, then you likely get lazy and start adding in multiple plugins written by the community.

Now you have like 8 dependencies to work with and you're trusting that some random dude who wrote that image gallery you're using actually knows what he's doing.

How is this not a negative or less of a negative than doing it yourself? I think you have some of your points reversed. You say that writing your own solution means your site needs to stay the same. It's actually the reverse.

If you want to change your site and it depends on 8 different plugins and multiple third party frameworks then you have to make sure the changes you make still work with that entire dependency chain. Then you have to deal with versions too. What if x plugin requires jquery 1.x.8 but the newest and latest version is 2.4.x after 6 months and the person who developed that plugin stopped developing it but it's a huge part of your site?

Now you're completely fk'd or you have to live with only using legacy code.

I do not want to list any sites I've worked on because I don't want to mix that element of my life on these forums. I'm not some hot shot super coder though and I haven't worked on anything that's massive scale (google, facebook, etc.). I'm just your typical freelance web developer who has been doing this for a while.

@everyone,
If a dev can't understand regular javascript and how the DOM operates then I don't want him within 1,000 miles of my business/code. Why on earth would you hire a front end developer who doesn't know anything about what he's working with other than how to Google pre-built jquery solutions that were written by unknowns?

@candybar,
No, if such a situation happened to come into play I would tell them to just use flat files instead of a full blown database for persistence. If they needed to not only store their info but also query it too and their dataset wasn't massive I'd probably recommend they chuck it into redis and then write a tiny bit of logic in whatever back end language they are using to keep their files and redis in sync.

99% of the time it's about picking the right tool for the right job. Sometimes that tool exists and sometimes you do need to create it.

But why bother with redis? Seems like a ton of unknown risks. Any developer who knows what he's doing can implement a key-value in-memory data store in a day, right? And you have persistence through files already.

And how can you trust a file system? It's terribly inefficient, not optimized for your purpose and will try hard to not to lose data you care about, while losing data you do care about all the time! Do you need all the features it provides? Can you really afford all the additional disk accesses the file system forces you to go through? Or lose data due to the complex way it stores even the simplest data? Anyone who took a basic algorithm class can utilize a raw disk to write data much more efficiently than any file system can provide. And it would only take a day or so. Why would I want to hire programmers who don't even know how to store data in a raw disk, which is essentially a byte array with specific performance characteristics?

i'll set the o/u for the largest dev team shoe has worked on at 2.5.

I'm sorry to burst your bubble but whether you read some data from a file or from a non-memory datastore it's accessing the file system.

You'll encounter the same inefficiencies from storing it in a flat file or a db. The only way a db will handle it better is it it's been told to cache its results to memory but you could easily do the same for flat files.

@tyler_cracker,
I'll answer this one later to let some people take you up on your offer.

In that post, I'm talking about using a raw disk, not a db or a file system. In other words, why not use your own lightweight file system that doesn't result in any overhead from all the features that you won't need? It's not very hard to do raw disk IO.

Btw, I wasn't talking about anything along those lines, but this isn't true either - there are database systems that work on top of raw block devices.

i thought april fool's was only supposed to last one day

I'm perfectly happy using the pre-built linux FS and so are the hundreds of millions of people using it on hundreds of millions of servers.

I like the idea that the nitty gritty details of writing bytes to a HD are abstracted away from me. I just want to store files, I don't care how they are stored as long as a proven solution exists and has been accepted by the masses (and there is).

This is much different than the discussion about whether or not using jquery+its friends is a good idea.

We're not dealing with something maybe loading in 1 millisecond vs 2.47 milliseconds. You ever try to load a script-heavy page on your iphone when you're not getting the best service ever?

A page loading in 15 seconds is ridiculous. I was around back when dialup was the mainstream and also had dialup until 2000 so I know how insane it is to wait 8-30 seconds for a page to load fully and I'll tell you that it's unacceptable.

You would be surprised at how many people visit a page with an empty local cache.

Look at Twitter's site or Netflix's site. Both of those sites are absolutely a joke when it comes to performance. Ignoring load times completely, the performance of those sites on my C2D desktop is abysmal -- even in chrome I can feel a delay when scrolling around.

What do both of those pages have in common? Yep, jquery+a ton of lolisthisreallife scripts. Some of the performance issues on those sites is due to the css they decided to use but not all of it is related to css.

you guys see this: http://forumserver.twoplustwo.com/34...splay-1189250/

is it just me or did google completely whiff here?

Is it real or another April fool's thing? I mean, who doesn't want to be a gargoyle?

pretty sure it's real

I think a lot of people would say the exact same thing about the functionality provided by jquery and other javascript libraries. They don't care about the nitty gritty details and just want the functionality from a proven solution.

As an industry, we have the same conversation everyday about any number of technologies or abstraction techniques. I'm sure we did 20 years ago about many that you take for granted. Most abstractions start out with questionable performance characteristics. There's no shortage of DOS programmers with an extensive knowledge of hardware knowledge and x86 assembly who used to feel smug and point fingers at those pathetic, wasteful Windows programmers who wrote slow, memory hogs of applications that relied on a slow, memory hog of a runtime called Windows. They knew they could write a much faster, leaner GUI for their app in DOS, utilizing their wizardry. They may have been right at that point in time, but did that matter?

Even among those who wrote GUIs in DOS, those who wrote them using popular toolkits would've fared better than those who wrote them in an ad hoc manner, because it's easier to port code written on top of a popular library than code that encompasses multiple levels of abstraction simultaneously. That is, unless you wrote your GUI widgets as a well-designed library in the first place, a highly doubtful prospect.

Widely-used abstractions improve by themselves, while a manual solution stagnates without your help. Ecosystems matter. Unless you want your own solution to become a widely-used abstraction, you should prefer someone else's solution to your own, when you're dealing with a common problem.


What's insane is a 40K library having much to do with a page loading in 15 seconds in 2012.


There's no shortage of websites that use jQuery that have perfectly good performance. And I never had any client-side performance issue on either of those sites. Optimizing for the few people who have performance issues on those sites seems silly, given that rolling our your own "simple" solution will certainly lead to more problems for people with esoteric setups, or resulting in a similarly bloated code base that now you have to maintain.

Simply saying that jquery is bloated and everyone should write their own library is a copout, unless you can point to your own, better solution to the problems jquery is aimed at.

my favorite part about this discussion is how i presaged it like eleventy posts ago but shoe just didn't grok it. thx for doing the dirty work, candybar.

@candybar,
With my script-heavy page loading in 15 seconds example it wasn't just a single 40k lib. Jquery here, jquery UI there, slap in a few jquery plugins, maybe throw in twitter bootstrap too and the next thing you know you're serving 500k+ of scripts/css but your page probably only has 10k of content.

For what purpose? So you can load some content into a div with ajax or blend in a menu animation?

You think someone on a mobile device wants to wait 15+ seconds to load your page when 50 other sites probably have the same/similar info that might load in 2 seconds?

When you have a limited/non-superb connection you become really conscious about load times. Just because most people have great broadband at home doesn't mean you should ignore your page weight.

You don't even have to make your own solution either. Just google around for the specific parts of the DOM you want to work with and chances are you'll find a micro framework that offers flawless cross browser compatibility. If you don't know what you need then you shouldn't even be in this field tbh.

Over

http://en.wikipedia.org/wiki/Straw_man

Have a separate mobile-only site. You shouldn't be using GUI plugins/widgets designed for desktops on your phone anyway.

Besides, it's disingenuous to blame jquery for being bloated and talk about how easy it is to roll your own, basic lean library, while pointing out performance problems that have to do with a lot more than basic jquery. If you were to roll your own jquery UI, UI plugins, etc, you're talking about a lot more development, testing, maintenance, etc. Why on earth would Twitter write its own GUI widgets when all their needs are easily met by existing solutions?


jQuery is such a micro framework by almost any standard.


Again, this sounds like a DOS programmer saying that if you don't know how to handle interrupt requests, you shouldn't be programming computers. Or an OS programmer saying that if you don't know how to write your own file systems, you shouldn't be programming computers. Any such statement can be true for a brief period of time, but with specialization, some people will be removed away from the nitty gritty details to focus on other problems.

LOL, touche

Saw this via NoahSD twitter. For someone like me with no sense of direction it looked promising..

Hmm... I feel like the answer has to be either 1 or >500. When you inhabit his crazy town you either work by yourself or in a big enough team that nobody realizes you don't actually do anything productive.

I mean his arguments are basically arguments against every layer of software abstraction that makes modern development possible.

For certain applications, 120ms is non-trivial. http://www.google.com/search?q=google+latency+studies

That said, the vast majority of people are probably better off optimizing for developer effort. Premature optimization and all that.

Absolutely real. Early prototype was surprisingly workable, way better than I expected. That said, I'd characterize the video as "optimistic". I do wish that video had been released on April 1st though.

Also, LOL at the idea of cross browser compatibility being easy. I don't know anything about jquery myself, but I can guarantee that I'd use it before trying to roll my own solution, if I didn't have more experience with other frameworks. In other words, I think candybar's nailed it in this thread.

Obviously, but:

I also find this whole jquery thing hilarious because there are lots of really ****ty frameworks/libraries out there for almost anything/everything - but jquery has to be one of the best ones in terms of what it does.

Everybody saying cross-browser compatibility is easy clearly doesn't have to support IE 6 anymore.