Slashdot Mirror

You don't even need to store it in a variable: jQuery is chainable so the following will work:

$('.someEle').addClass('class-1').addClass('class-2').addClass('class-3').addClass('class-4');

And, of course, if the developer knew CSS in the slightest, or bothered reading the addClass() documentation, this works too:

$('.someEle').addClass('class-1 class-2 class-3 class-4');

Wish there was an easy way to block all YouTube videos from Google results.

search string: jquery tutorial filetype:html

Unfortunately, that omits anything that's a .php or .htm or .jhtml etc., as well as any result that happens to be served up as a DirectoryIndex. For example, your search will not return https://learn.jquery.com/ in the results because it has no .html extension, but it's the authoritative source and probably the best place to be looking.

Ok, cowboy. Listen, I'm not here to give random strangers complete details about things [for free]. I provided an example and gave a link for further information. You should be thankful, pedantic prick.

Wish there was an easy way to block all YouTube videos from Google results.

search string: jquery tutorial filetype:html

Unfortunately, that omits anything that's a .php or .htm or .jhtml etc., as well as any result that happens to be served up as a DirectoryIndex. For example, your search will not return https://learn.jquery.com/ in the results because it has no .html extension, but it's the authoritative source and probably the best place to be looking.

- "However the browser simply should not know, and does not need to know, with what it is scripted. Be it Python or PERL. You only need a way to load a script instantiate the correct runtime environment / VM and expose the DOM and browser API to the script"

Yes, I agree. We should stop pushing JS and make a byte code standard so that any language can be supported. JS in production is currently akin to byte code anyway. I mean, try to read that https://code.jquery.com/jquery... it's a machine language in ASCII.

- "Probably try another JavaScript VM?"

How can I try another JS VM for Firefox?

- " alone is full with articles about the super fast JS implementations: since years."

Why doesn't Firefox use them? Again, every JS demo or production site needs to max out my CPU for the most basic tasks, whereas a native app would use maybe 5%.

One more thing:
> Need to do advanced event handling by manipulating the bubble/capture phase? jQuery can't do that.
http://bugs.jquery.com/ticket/...

Or he could be the type that needs to worry about low powered mobile devices (like the type that Firefox OS initially targeted). Those devices would choke HARD trying to load jQuery.

Don't get me wrong, I definitely see the value in jQuery since it even fixes bugs in modern browsers. But lets not assume that just because someone is shying away from it that they are some newb that doesn't know better.

If I am writing a few line script for something then yes, I will spend the extra few minutes to first try to avoid using jQuery when I can. Adding a 100 kb (just guessing, I have not checked it lately) JavaScript library so that I can write what I want in 10 lines of jQuery rather than 60-100 lines of vanilla JavaScript just doesn't seem reasonable in my eyes.

$ is just an alias for the jQuery function, which is the "selector" at the heart of the jQuery philosophy.

It's the same thing as JQuery(). It searches through the DOM for any elements that match the provided selector and creates a new jQuery object that references these elements. Here's a very simple example:

$("div > p").css( "border", "1px solid gray" );

finds any div wrapped paragraphs and puts a solid gray line around them. Docs here: http://api.jquery.com/jquery/.

$()

Congratulations on piquing my curiosity about something completely ungoogleable. That looks more like a Perl or shell thing than a Javascript thing. What is it, and what does it do?

I am not the original AC, nor do I know JQuery. However, I was also curious, and according to a related item, it is shorthand for $( document )

For many years code.jquery.com actually to Google itself. It wasn't until about a year ago that they got support from a different CDN to host it from code.jquery.com directly again. They still list alternative CDNs on their instructions, and say you can use which ever works best as long as you don't mind alternatives being possibly a couple days out of date on updates.

jQuery hardly qualifies as a "huge ass" javascript framework. The gzip minified production version of the script weighs in at under 34kB. Worst case scenario if you're hosting jQuery yourself, this is a one off download. This is hardly going to cause problems, even on a mobile data connection.

On the other hand, jQuery does make code a lot neater. Especially with judicious use of selectors

.

p.s. Nice going trying to pin the Obamacare fiasco on jQuery. I don't think I've heard that one before.

Hi, Thanks for trying the tool out. I tried http://code.jquery.com/jquery-... (from here: http://blog.jquery.com/2012/03...) and it worked fine. best, Martin

Hi, Thanks for trying the tool out. I tried http://code.jquery.com/jquery-... (from here: http://blog.jquery.com/2012/03...) and it worked fine. best, Martin

Honestly, I don't have a problem with jQuery. It's Panasonic who doesn't want it.

Your example is invalid though. You'd use Math.sin(). and Math.pow(), which are already included in javascript.

For actual jQuery problems, he could go straight to the jQuery library, and copy&paste the necessary functions. View the not-minified version, so it looks nice.

http://ajax.googleapis.com/aja...

And you can use it. You just have to keep the jQuery license in place, at least where that function is.

https://jquery.org/license/

So something like: /* This function, foo(), is from
  * jQuery JavaScript Library v2.0.3
  * http://jquery.com/
  *
  * Copyright 2005, 2013 jQuery Foundation, Inc. and other contributors
  * Released under the MIT license
  * http://jquery.org/license
  *
  * Date: 2013-07-03T13:30Z
*/

http://code.jquery.com/jquery-1.8.2.min.js (compressed, for production)
http://code.jquery.com/jquery-1.8.2.js (uncompressed, for debugging)

http://code.jquery.com/jquery-1.8.2.min.js (compressed, for production)
http://code.jquery.com/jquery-1.8.2.js (uncompressed, for debugging)

http://code.jquery.com/jquery-1.8.2.min.js (compressed, for production)
http://code.jquery.com/jquery-1.8.2.js (uncompressed, for debugging)

I appreciate the insight, genuinely, but I have to comment on this:

They have detailed api docs at their website. If you're a developer and can't read api docs then you've got other problems.

You mean this thing, right: http://api.jquery.com/

Saw this once posted in a Gentoo/Linux discussion here on /. back in ~2001, posted to a self professed 'noob' who wanted to learn about Linux,

"Hi, I used to be like you and I suggest trying Gentoo. Gentoo/Linux is very well supported with all the necessary documentation online for you to download"

You can't **make** JQuery be 'easy for a geek off the street to use' just by referring me to some website and telling me any developer will find it useful in using JQuery.

I'm trying to make a website that lets users design their own tshirt. Yes it's been 'done' and examples are out there (customink.com, zazzle.com, etc) but they all suck.

I know basic HTML and CSS and have ALOT of CLI experience from my academic and IT work.

I get the concepts.

Now, given what I know, what would this 'API docs that any developer could read'...what would they tell me about *IF* I could even use JQuery to make what I want?

I can't believe the old 'read the docs' trope is still around....

Yeah, we know about document.querySelector(). It's still limited and more of a pain in the ass to use than jQuery's $().

Here's what you're going to do, son. You're going to go through these lists of library functions, and you're going to list the native equivalent, and how well it's supported by the major browsers:

http://api.jquery.com/

http://underscorejs.org/

http://mochi.github.io/mochikit/doc/html/MochiKit/index.html

We're even starting easy, and just giving you three JavaScript libraries to cover. Remember, you have to do this analysis for each and every one of those functions.

I sure hope that you don't give up once you realize how wrong you are with your bullshit claim that "every feature has a native equivalent that works across browsers".

Oh, and if you don't prepare this comparison and have it ready within a few hours, we're going to know that you're wrong and that you're full of shit, son.

If you just need to call getElementByID once or twice then you're better off doing that rather than loading jQuery. If you need to do some more massive JavaScript/DOM manipulation and querying then calling getElementByID and the others repeatedly will lead to extremely long code. It will also lead to unmaintainable code if you just put everything in one big code block. To keep your code short and to enable easy reuse, you'll need to encapsulate this code into functions. Once you start making functions whose purpose it is to manipulate the DOM in a similar way across many different browsers, you are better off going with jQuery. You could wind up essentially rewriting it, but chances are it won't be shorter/more efficient. As a bonus, if you link to jQuery using the code.jquery.com URL, people's browsers will likely have it cached.

As for jQuery breaking code when they release new versions and/or dropping support for IE 6/7/8, you don't need to upgrade. I used jQuery extensively for an Intranet site and stayed on 1.4.3 for a long time. Recently, I decided it was (long past) time to upgrade so I reviewed our code, upgraded jQuery little by little, fixing things as they broke, and finally went live with jQuery 1.9.1. We'll likely stay with this (or another in the 1.x branch) until IE8 support no longer matters. (IE6 and IE7 support has been dropped already.)

You aren't even forced to upgrade if you use the code.jquery.com URL. This link has all of the jQuery versions from 1.0.1 to the current version.

For comparison we can paste the minified jQuery code into the excellent deminifier that was suggested in your link and compare the outcome with jQuery's open code; I can't directly paste snippets here because slashdot's lameness filter doesn't want me to.

For comparison we can paste the minified jQuery code into the excellent deminifier that was suggested in your link and compare the outcome with jQuery's open code; I can't directly paste snippets here because slashdot's lameness filter doesn't want me to.

But the average jQuery download per page is amortized across many downloads, making the average smaller than the file size. It's very common to link to, for example, http://code.jquery.com/jquery-1.9.1.min.js or http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js, which the client is likely to have cached already.

And don't get me started when you combine javascript with the DOM interactions that are still, to this day, largely a mess and in critical areas, undocumented. Take that times 5+ browser variations (and IE being the worst offender), Javascript in the browser sucks!

I'd like to introduce you to jQuery. They really took care of all the mess for you.

jQuery has said they will continue to support IE8 as long as it's a significant factor on the web. I.e. jQuery is not dropping support of it and ushering in its death, IE8's eventual dying will usher in jQuery's dropping support of it. And IE8's dying will only *begin* in a year and three months from now.

Far better than HTML5/Javascript.

I doubt it. Qt is nice but depending on what's being developed, HTML5/JavaScript can be the superior solution.

Besides, HTML5/JavaScript has so much momentum and is moving so fast that I'm afraid Qt will be irrelevant in a few years.

Check out this app.
https://moqups.com/
A native Qt app would have made the experience clumsy.

There are so many great JavaScript libraries in development that it's hard to pick one. Here are a few that you should keep your eye on though.
http://www.meteor.com/
http://angularjs.org/
http://emberjs.com/
http://dojotoolkit.org/
http://backbonejs.org/
http://jquery.com/

What is the difference between this and byte-code? There is none, because both are not human-readable.

Chuck Norris can read it. In fact, Chuck Norris compiles code in his head.

What is the difference between this and byte-code?

this

What is the difference between this and byte-code?

this

So can we finally have a specification that is not bound to a specific implementation? Why in all what is good and holy, do we need the limitation of JavaScript? Just make a byte-language specification, just like the CLR or Java Byte-Code for the DOM stuff.

Then everyone are free to use Python, Ruby, Java or what else as a language, the browser needs only to interpret the Byte-Code that the language-compiler is producing (just like with Java and javac, where you can use any language you like to produce the Java byte-code).

If you are really worried about open source, then answer me this: What is the difference between this and byte-code? There is none, because both are not human-readable. So why not just to agree to a byte-code that interfaces the DOM and html5 and then we can use any language we like to generate the byte-code?

Wouldn't it be nice to fire up your favorite IDE or editor and just write Python or Ruby (or insert here your favorite language) for your web-page? But no, we just have to use JavaScript until the end of the universe.

PS: most browsers are compiling JavaScript to a byte-language anyway nowadays, because then they can optimize the byte-code so JS will run faster.

It's not just developers and managers as groups. Remember, that these days Microsoft is a huge organisation and is full of many different divisions. There's Windows, Office, XBox, Windows Phone etc. amongst many others.

The guys that are responsible for this move are the "Web Dev Div", who are a sub-group within the "Developer Division".

It contains many people, including guys like Scott Guthrie, Scott Hanselman, Phil Haack (who recently left to join GitHub) etc., who have always done things that don't seem very Microsoft-like, like releasing ASP.NET MVC as an open-source product - albeit one that didn't accept outside contributions - back in 2009 along with such moves as bundling things like the open source jQuery library with Visual Studio and openly committing improvements back to the core project without trying the usual embrace, extend, extinguish tactics.

Within certain parts of Microsoft, they can, have done, and are continuing to do some very interesting, worthwhile and generally community-friendly (and not-so-evil) work.

I visited this rogue site that posts hostile code exploits and learned how to circumvent user privacy....

http://www.w3schools.com/jsref/met_form_submit.asp

Even worse, this malware generating site makes exploit code even easier...

http://api.jquery.com/submit/

And yes, I used the most evil and corrupt search engine ever invented (past and future) to locate these hacker havens

1. Read everything Douglas Crockford has on his JavaScript website. Use his jslint program. Down the road, read the code of his jslint program, I suppose. Buy and read his book. It's also available for the Kindle. Read the whole book twice. Basically, the lesson is don't make JS try to be Java, it only causes headaches.

2. Get a good JavaScript book for the language itself, this listing of JavaScript book reviews recommends the Wrox book, but I haven't read it, I use the 6th edition of the Flanagan book. See the link.

3. It's a language that, along with HTML and CSS, needs you to have a great memory or a good IDE that will prompt you for the allowable names. You can get a version of Eclipse pre-built for JavaScript, and you can get the Active State Komodo Edit program, both free. They say the Komodo IDE is even better, but it's expensive and probably not as complete as the (free) Eclipse.

4. You can get a version that runs on your desktop like a shell or perl/ruby/python will, but it isn't necessary. I know you can easily get a version of Mozilla SpiderMonkey that will do that.

5. Don't use the double-equals comparison operator, it's too confusing. Use the triple-equals operator ( "===" ), it's a pain to type but it's more straightforward.

6. Be wary form whence you copy. There's a lot of terrible code out there.

7. Use jQuery after your first two or three practice web pages, and after you've got CSS under control. This means also get a good CSS book. I guess start with the 'Lie and Boss' book, even though it's old.

to minimize google's already too-effective data gathering... there's things like the refcontrol addon for firefox. https://addons.mozilla.org/en-US/firefox/addon/refcontrol/

you could also build your own repo and redirect the common cdn subdomains to it.. a bit of work but could be worth it in the long run for some.... have actually been looking for some way to automate at least the fetching and organization of all those files, but haven't found anything yet (and not quite to the point of rolling my own)

as for cdn's that host libraries... google isn't the only game in town...

http://www.asp.net/ajaxlibrary/cdn.ashx
http://code.jquery.com/

we use the last one (hosted by mediatemple) for the sites that we use a cdn for libraries.

Did you even visit http://code.jquery.com/jquery-1.7.min.js ? I would say that's byte code, with just happens to have some ASCII characters in it, instead of just byte tupels.

Yes I did. Bytecode is a lot worse than that. Try getting rid of functions, if/else and structured loops of all kinds and replace with gotos and memory or stack locations. The wikipedia page has an example of what you can expect in Java for example. Or start with the page on three address code.

The jquery example you point out is mainly designed to reduce code size and bandwidth costs, but if you want to learn how it does something and that file is all you have, then you can start with a well defined entry point and you can trace what's going on from there. It's painful sure, but an order of magnitude less painful than your typical VM bytecode.

Modern bytecodes are designed to be very regular because that actually helps optimizing compilers do weird transformations and reorderings that straddle several separate source code statements. If you want the gory details, read the dragon book.

Did you even visit http://code.jquery.com/jquery-1.7.min.js ?
I would say that's byte code, with just happens to have some ASCII characters in it, instead of just byte tupels.

In Java almost all important libraries are open source, but very few people would download the source code, they are just happy with the compiled .class (i.e. a jar) files. The same is true for all compiled languages, and for some interpreted, like python.

As long as the license is open, the original code available, and the common practice of using minimized JS will increase, I don't see any problem or difference with byte code.

What have that do to with your argument? Libraries like JQuery will still be open source.
I would rather think that Web exploded because it's build on open technologies and open source software.
And if the Byte Code is a standard, it's as simple as a editor or disassembler to use to see the code.
Also, I don't think you can read that code: http://code.jquery.com/jquery-1.7.min.js

Actually, jQuery provide links to a few free CDN servers for anyone to use. These include CDNs provided by Google, Microsoft and jQuery themselves. The main advantage of using public CDNs is that the .js file (whether minified or not) is usually already cached by the browser by the time the browser hits your webpage. And vice-versa, if someone visits your website before Google's (ok, maybe not so likely), Google will benefit because their website will load faster.

So, neither careless development nor cheap people. Just you forgetting to check the jQuery website and being off-topic.

OK. Let's look at http://code.jquery.com/jquery-1.5.2.js very quick. This isn't even a minified version; just the original source. Pretend like you don't know what jquery is doing. The first few functions with arguments here:

> function( selector, context )

What are the types of those?

> function( selector, context, rootjQuery )

And those?

> function( num )

And that one? Hint: the function expects it to be "null" or at least "undefined" sometimes.

> function( elems, name, selector )

And that? Note that the function itself is not sure what to expect in |elems| and has different codepaths depending on what it finds there.

The point is, going from name to type is not really that easy.

Worse yet, "type" in this context also means what JS engines variously call "shape" or "hidden type": two instances of Object are considered the same type if they have the same properties in the same order. Telling _that_ from a variable name is pretty hard.

I don't know how well this would actually work, but it would be nice to develop a web frontend using tools like glade or QtDesigner rather than what I do now with Haml and jQuery.

Then you want aspx with Visual Studio.

Or using traditional application development tools to build a web app?

I like the Web, but I have to admit, GUI toolkits tend to be quite a bit better. I don't know how well this would actually work, but it would be nice to develop a web frontend using tools like glade or QtDesigner rather than what I do now with Haml and jQuery.

I'm very skeptical, though -- there are ways the Web is currently better than many desktop apps. Even ignoring issues like bandwidth and performance, would this give me an app which properly supports things like bookmarking, tabbed browsing, and the back button? Is it just drawing to canvas, or does it take advantage of native stuff?

From the video, the answer seems to be "no, and it's just drawing to canvas." If that's the case, I take back everything I just said, and I hope this is never deliberately used to build a web app. Still a cool idea, though.

As a fellow web dev with little appreciable GUI (or at least graphical design) skills, I warmly recommend jQuery. It makes writing cross-browser JavaScript a dream. Also, jQueryUI is pretty damn awesome and lets you whip together a pretty smooth interface quickly and with very little code.

Is your browser cache smart enough to deduplicate between multiple websites?

Website A downloads jQuery
Website B downloads jQuery

The browser has no idea what the file contains except a filename. Since they are on different hosts, how would it know*?

It's not possible for the browser to know which is which. The only way the browser cache would benefit this case if you hotlink from the same domain which is incredibly dangerous (say https://jquery.com/jscript.js)

* One solution is to implement a 'web library standard'. Every library has a accompanying file, something like 'jquery.js.lib'. This is placed on the same server as the hosting website. Inside this file is a hash. If the browser's cache has the same filename with same hash, it can use that :-) Of course it needs a browser change.
 

Want rounded corners (like on this site)? (...snip...)

I sure do!

And when I do, all I need to do is this:

$(".things_i_want_to_round").corners("5px");

And it works. In IE 6+, Chrome, Opera, Firefox, etc.

That's great! So you wrote that cross-browser abstraction layer yourself, right? Hmm, ok, but it's already out there. So when IE9 ships and it's not compatible, you'll just jump in and submit a quick patch, right? Hmm, turns out the code is a little complicated. Ok, no sweat, just wait till those guys who maintain it release an update, right?

For all intents and purposes, this situation is the same as using Flash. You can't code to the browser "bare metal" because it is insanely fragmented and buggy. You have no choice but to use an abstraction layer that someone else wrote -- be it JQuery or Flash.

Actually, even the minified version is 72k, not 24k,

It's 24k after gzipping. You do serve text content gzipped, don't you?

It's possible that there's a different version in play here, but the 24k figure is what I'm getting from the latest version.

And of course the only way to verify that the minified version doesn't pull in more stuff

jQuery? It doesn't.

since the source script is, for all practical purposes, semi-obfuscated.

That's like bitching that you can't figure out what Firefox is doing, because you only have a binary. It's jQuery! The original, un-obfuscated source is available, along with full version-control history! Unless they've gone out of their way to be difficult, you should be able to verify (with diff) that the version they are using is actually a particular version available for download from jquery.com.

If the "only" purpose was to run the script, a simple body.onload() would have done the job,

Except that's not what jQuery does. If your browser supports it, it's actually onDOMReady. There's a world of difference between those -- onload requires everything to be loaded, including images, movies, everything. onDOMReady only requires the HTML DOM itself to be finished loading, which is going to be considerably faster -- but it's still enough that your script knows what it's dealing with.

If your browser doesn't support that event, I believe jQuery will emulate it via polling. I'm not sure if it ever falls back to load.

But no, body.onload() is not equivalent. You could certainly do onDOMReady yourself, if you were really determined not to have external dependencies, but that could be said of anything included with a library.

as would calling the first function from an embedded script tag at the bottom of a demo page..

I'm pretty sure the only XHTML-compliant place to put script tags is inside the <head> tag, which makes sense. Progressive enhancement is good design.

Actually, even the minified version is 72k, not 24k,

It's 24k after gzipping. You do serve text content gzipped, don't you?

It's possible that there's a different version in play here, but the 24k figure is what I'm getting from the latest version.

And of course the only way to verify that the minified version doesn't pull in more stuff

jQuery? It doesn't.

since the source script is, for all practical purposes, semi-obfuscated.

That's like bitching that you can't figure out what Firefox is doing, because you only have a binary. It's jQuery! The original, un-obfuscated source is available, along with full version-control history! Unless they've gone out of their way to be difficult, you should be able to verify (with diff) that the version they are using is actually a particular version available for download from jquery.com.

If the "only" purpose was to run the script, a simple body.onload() would have done the job,

Except that's not what jQuery does. If your browser supports it, it's actually onDOMReady. There's a world of difference between those -- onload requires everything to be loaded, including images, movies, everything. onDOMReady only requires the HTML DOM itself to be finished loading, which is going to be considerably faster -- but it's still enough that your script knows what it's dealing with.

If your browser doesn't support that event, I believe jQuery will emulate it via polling. I'm not sure if it ever falls back to load.

But no, body.onload() is not equivalent. You could certainly do onDOMReady yourself, if you were really determined not to have external dependencies, but that could be said of anything included with a library.

as would calling the first function from an embedded script tag at the bottom of a demo page..

I'm pretty sure the only XHTML-compliant place to put script tags is inside the <head> tag, which makes sense. Progressive enhancement is good design.

The official site recommends you load it from google. Why? Cause the fine folks at jQuery make a kick-ass javascript library, not a global content distribution network.

If you hotlinked the library from the official site, you'd basically be a leech and worse, your visitors would probably not get any of the benifits that come from loading jQuery from google (namely the fact the visitor probably has the google version in their cache already).

in IE 8, what's the recommended way to specify that a script shall run once the DOM content is ready? Or how do you attach multiple event handlers to an object, such as multiple things to run on load?

Exactly identical as in IE7, IE6, Firefox, Safari, Opera and Chrome. jQuery or Prototype.

For example, in IE 8, what's the recommended way to specify that a script shall run once the DOM content is ready? Or how do you attach multiple event handlers to an object, such as multiple things to run on load?

$(function() { /* do crap here when the DOM is loaded */
});

$(function() { /* do a second set of crap here when the DOM is loaded */
});

http://www.jquery.com/

It is trivial to have not a singe line of Javascript in your HTML, other than the link to the external Javascript file.

See, for instance, http://api.jquery.com/category/events/ for a set of jQuery methods for attaching events, using css-like selectors. (Most of these methods are special cases of "bind".)

To avoid mixing HTML and PHP, you can use a templating engine like Smarty (http://www.smarty.net/crashcourse.php). (I prefer those that use a different syntax from regular PHP to help enforce the distinction.) I do understand that PHP was originally a templating language itself, at a time when most hard-core back-end logic might have been in C/C++ and the PHP was for gluing that to the markup. But now that PHP is used for that same back-end code, it makes sense to separate it out of the HTML, so front-end coders don't need to wade around in back-end logic, programmers don't need to worry about markup and presentation, and each file to edit is clear and understandable in itself, partly by consisting of a single language and sticking to a single task. (The template language is designed to be as simple as possible, and only has the limited capabilities necessary to include dynamic content - generated elsewhere - in HTML markup.)

At the least, SQL should be in a separate data-abstraction layer. That layer may also be in PHP, but at least it's a special-case set of code just for accessing the data store (partly so that it can be replaced with a different data store if needed, without affecting any other code). Many frameworks use an object-relational mapping layer so you don't need to touch SQL at all.

It's also pretty easy to keep CSS completely out of HTML, and if well-designed, the number of special cases to apply to single paragraphs can be very minimal.

Yes, it can seem like all this is a lot of trouble when you're starting out or working on a very simple project, but as a project grows, it can very quickly become unmanageably complex otherwise. These are all tools for managing complexity and scale so that medium-sized projects are easily workable and large-sized projects are possible at all.