Hacker News Reader

Comment by manish_gill | Hacker News Reader

Having recently started getting into Javascript, I have to say it is the most confusing ecosystem ever. Learning the basics of the language is easy enough, but as soon as you start trying to create a non-trivial application, bam, you're hit with information overload - X framework, Y library. It's different from Python, Ruby et all because at least with them, there are good consistent popular choices that you can rely on. With Javascript, more often than not, I'm left scratching my head as to what I should exactly use.

View on HN

There's a lot of choices, and that's not a bad thing necessarily. Javascript is in a heavy growth period right now. But I totally get the choice overload thing. There's a lot of people interested in javascript from all different areas of computer land, and they all have different ideas of what "best" is, and they all want to make javascript more like lisp, or more like ruby, or more like java, or more like c# or more like flash, and so on and so forth.

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.

Backbone may or may not be right for you. Fortunately it's small, and fairly easy to read. The annotated sources [1][2] for BackBone and Underscore are fairly accessible.

Also, I would highly recommend adding an AMD loader like require.js to your "basics kit". Code organization gets very important very fast, and it helps to think modular-and-reusable from the beginning.

[1] http://underscorejs.org/docs/underscore.html

[2] http://backbonejs.org/docs/backbone.html

Plenty of debate these days over whether to use an AMD-based loaders like require.js [1], or to bundle all your js into a single file with Browserify [2]. Worth someone new being aware of, but that debate can get rather complicated.

[1]:http://requirejs.org/

[2]:http://browserify.org/

All of you are giving good advice but I just have to chuckle at how quickly you all proved OPs point.

Yeah this is one of the best examples of people proving a point by trying to disprove it I've ever seen.

"The ecosystem isn't (that) confusing, just use X Y and Z"

- "No, use X Y and A"

-- "Who uses Y? Use C"

Myth: confirmed!

Well, I wasn't trying to say it wasn't confusing. Just trying to reduce the confusion by picking a starter pack. It doesn't work if everyone else flinches and decides they have a better starter pack than me!

hahaha this was hilarious even before I saw the 15 or so additional contradictory suggestions below this thread.

That was the point ;)

Just a heads up, but require.js supports moving everything into a single file:

http://requirejs.org/docs/optimization.html

Your comment makes it seem like it doesn't.

For someone new to JS, as I once was, Require.JS can really complicate things. I know I read all these comments and blog posts saying "Use require.js!", so I thought I had to use it. Well, it took a long time to figure out how to structure my Backbone code that way. Most examples and tutorials aren't using Require.JS, and that also makes things harder. I would use it now on a backbone project, but not sure if I would recommend it to beginners.

If you're starting out from new, I'd argue you can make do with the templating in underscore instead of adding another library.

http://underscorejs.org/#template

Is there a good, focused, website where these .js tools are discussed on an ongoing basis? Yes, I know HN and a thousand other places scattered all over, and maybe that's really all there is, but I'm hoping there's a way to figure out what .js tools ought to be used for what, and keep abreast of changes, without having to read the whole Internet.

I suppose I could ask experienced developers on StackOverflow.... (Just kidding! "Stop! Silence! Nobody answer him! Not constructive! Not Constructive!")

If front-end MVC Is too much for a given use case, then Twitter's Flight.js[1] seems like a great way to keep jQuery well organized. It defines a way to write jQuery components that communicate via events, piggy-backing on the DOM's event propagation. Quite simple, and ideal for when a single-page-app (e.g. the kind you get with Backbone) isn't quite right for you.

[1] http://flightjs.github.io/

And definitely replace jQuery with Zepto (which is more-or-less a drop-in replacement), if you have control of the client (non-IE) or especially are working in mobile.

I wouldn't say "definitely". Even Foundation has gone back to jQuery.

I've not heard of Zepto. Out of curiosity, why use it over jQuery?

When using Phonegap (and mobile web in general), I've experienced a pretty major delay between page load and jQuery running. Zepto seems to run instantly. YMMV.

Probably the file size argument, last time I read one of these discussions jQuery was 3x bigger gzipped at ~30kb.

Ok, that makes sense, especially for mobile development.

I looked it up, and it seems to be missing quite a bit, including the .noConflict() option, which I seem to have to use quite a bit when working on others' code....

It's minimalist.

http://zeptojs.com/

Is there any strong reason to use Underscore over Lodash?

It's funny, even as someone who knows js really well, having worked with it for a decade (actually, longer!), the explosion in the ecosystem took me by surprise.

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

Basically it boils down to what you want to do.

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/

browserify, +1.

If in doubt, just use Javascript without anything. Maybe add jQuery.

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.

Plain javascript is nice, but if you're talking about getting a single bit of code to work in N many browsers, the "frameworks" start becoming less optional.

Actually the frameworks don't help in that regard. They are meant for organizing your code, they don't offer any special compatibility.

jQuery does that.

Well let's define some terms here then. In the sense that I was speaking about, I was using "framework" as a synonym for "library". Not an entirely unprecedented usage.

Underscore gives you array extras in every browser, even ones that don't have array extras.

Mustache because let's face it, javascript doesn't have any nice way of doing templating or string formatting or anything. not without resorting to doing things that might not work in every browser.

and backbone because, while some of the newer browsers and newer versions of ecmascript provide facilities for monitoring and reacting to changes, and doing data binding like things natively, not all browsers do.

now I'll admit that backbone is not as new and shiny as say, that om/react/clojure stack making the rounds on hacker news, it's been around for a few years and it's still here. So that's something.

>Not an entirely unprecedented usage.

Well, not a valid usage either given the context. From the examples you give, the only fitting one is Backbone, and even that it's stretching it a little (nobody uses the ES6 monitoring/reacting facilities directly atm, so it's not like Backbone gives them compatibility for them, it's like it provides them in the first place).

What does XCODE call a "library"?

… a framework.

and underscore. not for DOM, but for some functional compatibility (map, forEach, etc). Plus, it's convenience methods quickly become indispensable.

_(fn).bind(this), anyone?

Uh oh, I've been using fn.bind(this) everywhere. Is there a linter that will warn me when I'm not using cross-browser supported js?

it's called IE7. Any feature that's not cross browser supported is guaranteed to not be supported in IE7. A.K.A. lowest common denominator.

Very soon to be IE8.

I'd say underscore needs to be there too

And this is exactly how it starts :-)

And it never ends :-)

Correct, the performance of lodash definitely makes it the better choice. :)

These days, think Lodash is the better pick.

> It's different from Python, Ruby et all because at least with them, there are good consistent popular choices that you can rely on.

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.

I think there are 2 things at play that prevent a rails-like monolithic framework for js at the moment:

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.

Your last sentence is specially interesting. Being able to do a "bower install backbone" and going back to work is actually the purpose of a package manager. If it doesn't understand your project structure and is not able to wire the downloaded libraries into your project, whats the point of using it? Then bower is as good as npm or any other tool to download libraries. Right?

What bower manages is downloading dependencies at a specific version and putting them in a folder. It does not wire/unwire them into my index.html. At this point I have to do that by hand. There are a lot of ways my project could be laid out. I might only want d3.js on my dashboard page, I might have a layout template where all of my html imports reside. I might want the files all concatenated together and downloaded in the browser as a single main.js. In it's current incarnation it's still a package manager... it makes packages available at a path. It's just not as useful as it could be if it were a bit more specific about project structure.

OK. That makes sense.

I'm with ya... there are a LOT of choices. A couple of days ago I was looking for a dropdown menu library. A simple Google search quickly turned up about 300 options. But to make it worse... the other library I was using for drag and drop layout (Gridster) was somehow munging the attributes of <li> elements such that a dropdown menu using either of the first two choices I picked (Bootstrap and some JQuery plugin) both failed to work inside the draggable widget. And figuring out how to make Gridster work using <div> elements instead of <ul> and <li> was a PITA.

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.

You can always start building things in plain javascript and start adding libraries when you run into problems. That way, you have specific criteria to help you decide which solves your problem best.

Hehe. I know the feeling. I've spent a lot of time learning about the different options over the past year. Maybe it was wasted time, hopefully not. Backbone taught me a lot about design patterns in general (event aggregators, pub/sub w/Marionette, MVC). Then I started learning Angular which felt like being turned upside down.

Nevermind the libraries and frameworks, I find it more troubling that there are so many different patterns/conventions to emulate things that aren't part of the language, like modules or classes. But ES6 is very promising in this regard.

I understand the whole 'paradox of choice' thing - but this should never be seen as a negative. It is a sign of a strong, healthy community making lots of progress.

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

I suggest trying CoffeeScript if you want to a cleaner version of JavaScript. Not that that answers your framework question.

Coffeescript isn't javascript, though.

Reply on news.ycombinator.com