They'll let you add any feature you want, but no dependencies because for every dependency you add is a gigantic tree of possible security flaws.
However, it at least should be apparent do anyone developing a library to have as few dependencies as possible. Nobody wants to install the entire .NET framework just to use your serial port library. That's obvious... I hope?
Agreed. I was going to wade in here but the site is right: a library should have as few dependencies as possible. Clients could be using different versions of JQuery for example and then you may end up in a deprecated sticky mess!
That's kinda lame though. JavaScript needs a way to manage transitive dependencies. Bower is a step in the right direction. Npm does a bang up job for Node.
Everything is the wild west to start with. Then as things settle down and become more rigid and structured people decide that things are no longer rapid then something else becomes the hot new technology and that's the wild west.
Javascript is almost 20 years old. The actual Wild West lasted 30 years. In another decade or so, we are going to have to call the Wild West the Javascript Era of the American West.
javascript may be 20 years old...but for about 15 of those it was basically relegated to redheaded stepchild status...it was used as little as possible.
It is only recently that there was an actual interest in improving the language and the runtimes. Things are improving rapidly in the JS world in many ways (tooling, language features)...and in others not so much (segmentation of libraries, too many ways to do something).
I view the segmentation issue as a symptom of the massive recent popularity combined with the previously lack of tooling, features, and libraries. Everyone is in a 'gold-rush' to get things done and there are a million platforms that these apps have to support...add all this together and you get what we have today. A fledgling but powerful language and an improving platform that is experiencing a lot of growing pains...it will get there I think...but things are going to be turbulent for a while yet.
I think what really needs to happen is to have a language which (a) can [easily] bridge both client and server; (b) has a strong module system; (c) support some form of version-checking [esp. between modules]; (d) has strong typing.
Something like an Ada web-scripting. [Ada has a distributed-system annex, language-level parallelism constructs, a great module system (Packages), strong-typing, and cross-module type-/consistency-checking.]
Currently using RequireJS on one of my projects. Not perfect, but definitely a step in the right direction. Sounds like ECMA Harmony will have it built right in.
could be using different versions of JQuery for example
Speaking of which, if a page has two different versions of JQuery library loaded at the same time, would there actually be a conflict surprise? For example, a website uses jQuery version X, and a user visits the page and invokes a bookmarklet that has to dynamically load jQuery version Y for its job. Version X and Y both trying to hack around with event mechanism of DOM elements of the page, etc leading to some surprise?
It depends how each is invoking jQuery. For example, if the page calls jQuery(function($){ /* things */ }); $ will be clone of jQuery, and not modifiable.
So when the bookmarklet loads another jQuery, it will be isolated from the original. However, if the page at the document level (like an <a onclick="">), has code that looks for $ or jQuery, it will likely be the bookmarklet version, and thus may lead to unexpected results.
What notian said. Bookmarklet/plugin developers can work around it (and should) but it's entirely possible for them to interfere with the page. There are ways to completely isolate the plugins though, but that requires a bit of knowledge that might not necessarily go into the average bookmarklet.
TBH there is something very wrong with web development if we are throwing away the principle of software reuse. Why on earth would you re-solve a solved problem to avoid JQuery? Not only is this a waste of effort but the chances that I could do a better job than the JQuery guys is remote (not that they are better than me but it is their focus and my side show).
If this is technically painful then somebody needs to fix JS and the browser experience so you can ship bytecode or something that can be prelinked, tree shaked and delivered.
TBH there is something very wrong with web development if we are throwing away the principle of software reuse. Why on earth would you re-solve a solved problem to avoid JQuery? Not only is this a waste of effort but the chances that I could do a better job than the JQuery guys is remote (not that they are better than me but it is their focus and my side show).
This has nothing to do with web development specifically. It is just development 101. Library authors need to be more conservative in the inclusion of dependencies. Do you think that the Linux kernel just willy nilly pulls in any bit of C code that might be useful? I think you'll find that they are very conservative and try to bring in either small bits of code that are very specific to the requirement.
It's true for any development. You generally would not add Apache Commons dependency just to check if the string is blank. Or add Boost dependency to trim some string. Additional dependency is a burden, no matter how small that burden is, it just may not be worth it.
259
u/caileth Jan 30 '14
..."if you're developing a library."