If you just need a choice, somewhere to start. I'll make some choices for you. Here's the zen selection. My view of the standard javascript library:

jquery ($)

underscore (_)

mustache ({{}}) (possibly accentuated by iCanHaz)

Backbone (Backbone)

And that's your basic starter pack. It's a confused ecosystem because it was only since about 2007 that people started to realise that javascript was an actual programming language and not just a stupid toy. I remember that year chatting with people on #javascript on IRC who simply didn't believe that I had an actual full time job writing server side javascript. the idea seemed too absurd. And so here we are, a mere 7 years later and we've pieced together a very humble ecosystem in the face of that level of bald hatred and misunderstanding. I remember it wasn't so long ago that flash was in a similar position, and not long before that, java, with its popular image being its slow crummy applets.

So, yes, in conclusion, you're right, and it's because it's young and every language goes through this stage.

I left my web agency role over a year ago to work on my start up with a friend so I've been in relative developmental isolation (lots of python and js, not so much keeping up with the latest trends). I came back to help out on a project recently and had to spend a day researching all the new tools. Particularly around package management, bower, grunt, yeoman, node, npm etc. A year ago a js lib was generally delivered as a js or min.js file. Now there's the whole system to sit around it; every project on github now seems to include the config for each of the different package managers. Even a vagrant file so you can get it all up and running on a brand new vm.

Something as simple as adding bootstrap to a project. It's not totally obvious when you first look at it. Where does the code go? How do you compile it in such a way that you don't touch the vendor src itself but you can customise it etc. I have a method that works for me, but I had to play around a little to figure out how to fit it to my needs.

Once I got through that stage I was really happy with where things were at. JS libs are nice and easy to install and version control now, dependency management with bower has worked really well for me so far. Grunt makes the automation side of development nice, contained and easily shared. All in all it's a really good transition.

I'm lucky in that I've been developing for the web since people were changing files in ultraedit and ftping to the live server to see the changes. When each new thing comes along I only have one new thing to learn. Step away for a year and suddenly there's a lot to figure out to get back in to it.

I can only imagine how daunting it could be for a complete newbie trying to find their way.

As ever these tools can be great, but you ultimately you really want to understand what goes on underneath so they don't limit you too much. Amazing talk on this subject posted by another HNer in a comment the other day - https://www.youtube.com/watch?v=ShEez0JkOFw

If you know you’re replacing many parts of your page with data you have to load, use a framework like angular, backbone, ember, …

If you visualize data, use d3.

If you need to animate some UI elements but don’t need much else, use jQuery.

Else use plain JS, maybe with some shortcuts like function $(sel) { return document.querySelector(sel) }. maybe with underscore.js if your love funtional programming.

In any case, strive to write idiomatic code. d3, jQuery, and many else e.g. have their own variant of $, select, querySelector, … – decide on one framework and use its way to write code.

Any you’ll want to find a way to compartimentalize code. https://github.com/mbostock/smash is good, and http://browserify.org/

All those frameworks may be nice, but as soon as the tools get a distraction, I think it is useful to step back. And JS doesn't really need anything to be useful.

In the browser yes , i would say there is no consensus as to what lib to use. Some hate jQuery others like it,but the kind of projects people do are very different on the client.

I'm not going to use the same framework for a game or a LOB app or an interactive "flash like" experience, and some framework will use a paradigm I may or may not like.

Also on the client frameworks and libs are totally monolitic because JS doesnt have a proper module system. Python and Ruby dont have this issue. So JS lib are always re-inventing the wheel.

Despite what people say , client side , there is not "one true way" to do stuffs( like using AngularJS for everything).

I personally use jQuery and Ractive because they are fast and easy to use. On bigger projects I use browserify to build my own stack instead of a monolitic framework.

1) Front-end applications tend to have wider variation in functionality requirements from the start (real-time, graphs, animations, forms, modals, pushstate). There isn't a "standard CRUD app" that people are building with front-end js, often js is just being used for a single effect or widget.

2) Performance tradeoffs are very tangible to end-users. For instance, in most cases, straight HTML is still lighter and snappier than an AngularJS app (until you click on something, then that's another tradeoff) but an app served by 2 rails servers will usually be indiscernible from one served by 1 sinatra server.

With rails, you can say that the performance penalties are worth productivity gains because those penalties are really only going to effect deployment costs, not the UX. With JS, every extra bit you add to your framework is going to effect UX.

For me, the biggest pain is still dependency management. Bower is great for pulling stuff in but then I have to blend it with requirejs or an AMD loader or hand-wire it into my html. Likewise, when I want to remove something I have to touch a bunch of files. I'd love to just be able to "bower install backbone" and get back to writing code but building such a feature would require bower to be able to understand my project's structure.

But in the end, I now have a way to build a nice draggable widget that can contain a menu in the draghandle. Now, to embed a Google Gadget in that (the menu is for setting UserPrefs) and make the OpenSocial API work... Oh joy.

If you're looking for popular tech, i think a good proxy is github stars.

http://www.google.com/trends/explore#q=angularjs%2Cbackbonej...

[1] https://github.com/braziljs/js-the-right-way [2] "Based on a work at http://jstherightway.org"

Your page is split in half on the iPhone, check it out. Cheers.

http://addyosmani.com/resources/essentialjsdesignpatterns/bo...

While there have been attempts to compile a language like Python down to native code, they are still very limited and not useful in a practical sense. Hence, Python is a de facto interpreted language, since its usable implementations are implemented as interpreters.

The same goes for JavaScript today. Given that all of the usable implementations are interpreters, JavaScript can currently be considered an interpreted language.

    > What would be an example of a language with weaker OOP capabilities?

Nonsense. Maintainability is all about good documentation, neat code, sensible peer-reviewed code, a good dose of manual testing and a healthy injection of personal responsibility in seeing the project be the best it can be for your users.

I test my work manually on a bunch of test devices and computers I own. It doesn't take long and I get to see any browser specific display glitches that automation tools wouldn't pick up. It's a no-brainer, and you LEARN about the nature of browsers by testing manually.

I hate bootstrap, don't use it. I've made big website templates with lots of traffic, and smaller components and other things. I don't want bootstrap in the mix thanks. Whenever I have to maintain a project which someone else started with bootstrap, I sigh and dive into the ridiculous use of simulated rows and columns, and the crappy CSS overrides meant to give us flexibility, but actually giving us not much at all.

So how do other developers like my work when they have to maintain it? Well, I leave them something SIMPLE and well documented to decipher, so they can get straight to work doing the maintenance and getting on with business. No learning curves of countless toolsets and pre-processing junk. Just the basics. I've had no complaints.

Frontend is very much concerned with visual elements and interaction. I don't know much about server side except for what I find behind the projects I work on and fetch with AJAX or other means... such and such data feeds, this or that outputs etc. I'm more interested in user interfaces and how a web app or webpage "feels". I know exactly what to do when something doesn't feel snappy, or a graphic flashes or renders poorly on load. I know what to do because I haven't sold my soul to a framework that promised me the world, but delivered mediocrity.

Each to their own.

That's a rather negative view, and I don't think it's entirely realistic. I am involved with multiple long-running web projects that have been using things like (real) MVC architectures and single-page applications since long before any of these trendy JS frameworks existed. The projects have been built using sound software development principles and usually a small number of carefully chosen supporting tools and libraries. They are still doing their jobs just fine, and they have stood the test of time in terms of maintainability.

The only people I meet who have an aversion to these modern JS frameworks are front-end devs who refuse to learn them or server-side devs who hate javascript.

Please consider that there is at least one more option, which I imagine applies to many of the older readers here. Some of us have seen before the rapid evolution of an ecosystem as a programming language takes off, and we simply don't buy the hype.

We saw the arrival of Java, with all its garbage collected wonder. Then we saw the nightmarish descent into over-engineered hell that followed.

We saw the arrival of Boost for C++ and the potential of community-developed, peer-reviewed libraries. Then we noticed that in 2014, C++ still doesn't even have basic features for working with filesystems or rendering a simple UI as standard.

We saw the evolution of very dynamic "scripting" languages like Python and Ruby into widely used server-side languages for real applications. Then we saw people trying to maintain those applications a few years later, when they weren't prototypes any more and when quality and performance mattered.

More recently, we've seen front-end web development shift toward JavaScript and move away from the likes of ActiveX controls, Flash plug-ins and Java applets, as language support became more consistent across browsers and some real effort went into improving performance. Today we are also seeing the inevitable explosion of the surrounding ecosystem as JS becomes a tool for building more heavyweight software, signalled by the arrival of vast numbers of different automation tools and libraries and frameworks.

But with the cynicism of the industry veteran, we also see that many of these new tools will do 80% of a job easily but make the last 20% much more painful. We know that some are merely short cuts aimed at people who now work in front-end development but whose backgrounds aren't necessarily in programming and who haven't yet developed their general software development skills in that way; there's nothing wrong with that, of course, but such tools have no (or negative) value to those who have moved beyond the level where they are helpful. Most of all, we know that five years from now, as the ecosystem evolves standards and consolidates, it is highly unlikely that most of the currently trendy tools will still be as effective and well maintained as they are today, but that like the five-year-old projects some of us work with today, someone will still have to maintain those projects after all the hypesters have moved on.

This doesn't mean that we somehow refuse to learn new technologies. It just means that if I can see what looks like a fire, and it feels as warm as I expect when I get close enough to examine it, I'm not still going to jump in for a few minutes just to see if it's really as hot as it looks because I read on a web site somewhere that all the cool kids were doing it.

Now get off my lawn. :-)

This debate feels loose. We are lucky to have so many options. It all depends what project you're working on.

I prefer rich possibilities in design and functionality rather than rich possibilities in minimising how much I have to think/solve/innovate. I don't want a crutch, I want a turbo boost of creativity in web development... and that comes from hard work, not automating your life.

These tools are often about slapping the same old stuff down day in day out. Where's the fun in that?

Am I re-inventing the wheel? Spreading boilerplate code around in a mess? No I am not. My boilerplate code is nicely organised and easily deployed thanks very much! And the wheels.. well, the wheels I make are lightweight, and I know and trust them inside out. They're my wheels. I made them, and they stand out from the crowd.

Perhaps not, but plenty of us write them using a lightweight framework like Flask rather than heavyweights like Django, and even in a relatively mature field like ORMs, there are downsides to using them that sometimes outweigh the advantages.

For a tiny app, sure, maybe it's not so bad to just use jQuery.

I've got ~100,000 lines (before minimising etc.) and ~5 years of successful maintenance "just using jQuery" for one web app that I can quickly check from here that is still going strong. I think most of us would agree that's not a tiny single page application.