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.
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.
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.
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!
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.
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.
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.
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.
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 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
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.
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.
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.
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).
> 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.
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.
Given that the greatest challenge to JavaScript testing is the browser environment, it'd be worthwhile to mention Zombie.js (simulated DOM) and PhantomJS/CasperJS (V8). Code organization is also important for any large codebases, which is often addressed with browserify or RequireJS.
Nice, I like what you're trying to do, but things like
"Backbone.js: The most popular JS client-site framework"
worry me. Most people I talk to avoid Backbone nowdays in favour of the other popular frameworks.
Also: some descriptions appear to be lacking/missing & you definitely should mention Grunt under "Helpers". At least it's a GH repo and I assume you'll accept PR's? ;)
As someone who lives and breathes Backbone at the moment, I think its biggest problem is that the framework itself provides not nearly enough guidance to write maintainable and testable code, nor does its documentation. It's not nearly clear how to start your app in a sensible way, where to put stateful non-view, non-model logic, and how the pieces should all communicate. So, you start cobbling your Backbone app together, making architectural decisions as best you can, and then months later, you realize you've created an unmaintainable mess. I've had this experience coming into two large projects so far.
I'm sure everyone's second Backbone app looks a lot better than their first, but it's still an underdesigned framework, IMO. I think Marionette does a lot of good in terms of adding those missing structures and best practices, though. And I'm also intrigued by the idea of replacing views with React components.
It never was a framework; it was a better API for the DOM + some various other browser APIs -- so much better, in fact, you can get a near-framework-like productivity boost using it.
(At least at first, before it starts to matter that it's no help in terms of organizing a larger application. :)
Is there a "too clever" mentality in frontend web dev culture of late? An overly fragmented workflow toolset?
Not sure the cause, perhaps the influx of engineering "computer science disciplined" brains into the frontend world. Or a panicked competitive race to achieve a nirvana dev environment. Or a tendency to think that workflows for large websites with countless modules is the best workflow for a one-page web app.
Overkill for the intended task, or cluttering your project with too much technology, is the thing to watch out for in the frontend aspect.
Layers of tools and libraries and plugins can easily get out of control and beyond a joke. Don't forget you've got a web app to build while you mess around with the "right way" to build it.
You do not need a cup-holder on your scaffolding.
Just using plain JS with Jquery, and perhaps some additional smaller specific plugins/libraires, is enough to do a lot of cool stuff if we're talking "javascript" projects. Then just get a good editor and off you go.
> Just using plain JS with Jquery, and perhaps some additional smaller specific plugins/libraires, is enough to do a lot of cool stuff if we're talking "javascript" projects. Then just get a good editor and off you go.
These new tools and frameworks are becoming numerous and popular precisely because for large, complicated front-end applications you can't just get away with using "plain JS with Jquery" without it becoming an unmaintainable mess and writing boilerplate DOM manipulation code all over the place. 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.
> you can't just get away with using "plain JS with Jquery" without it becoming an unmaintainable mess and writing boilerplate DOM manipulation code all over the place.
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.
These new tools and frameworks are becoming numerous and popular precisely because for large, complicated front-end applications you can't just get away with using "plain JS with Jquery" without it becoming an unmaintainable mess and writing boilerplate DOM manipulation code all over the place.
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.
> 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.
No, they are aimed at people who have worked in front-end development for a long time and whose backgrounds are in programming precisely because they are sick of reinventing the wheel every time they start a new project and are able to understand the technical value behind concepts modern frameworks give us like dependency injection, unit/e2e testing, modularity, and separation of concerns. The myth that front-end developers are not "necessarily from a programming background" is poisonous thinking and it unfortunately usually comes from older programmers or non-front-end developers; the very people who could help guide the front-end world into maturity.
sick of reinventing the wheel every time they start a new project and are able to understand the technical value behind concepts modern frameworks give us like dependency injection, unit/e2e testing, modularity, and separation of concerns.
You write as if we didn't understand the technical value of those things before a couple of years ago when the current crop of JS frameworks arrived, and as if using one of those frameworks is somehow necessary to achieve them.
In reality, everything you mentioned has been widespread in other software development fields for decades. It's stuff the junior guy on the team learns in his first few months.
Moreover, I think there is a reasonable argument that of your chosen examples, testing is the only one that has sufficiently common requirements for building large but general tools to be worthwhile. The other design principles are valuable, but how best to use them will be highly project-specific, and therefore any widely useful framework will tend to be over-engineered and over-generalised for most applications. See also the Java nightmare I mentioned previously, the trend toward lightweight frameworks on the server side, etc.
Edited to add:
The myth that front-end developers are not "necessarily from a programming background" is poisonous thinking and it unfortunately usually comes from older programmers or non-front-end developers; the very people who could help guide the front-end world into maturity.
There is a difficulty in the industry that significant numbers of people are coming into this kind of front-end development from some sort of HTML/CSS and/or design background. They used to use a bit of JS here and there that they copied off a demo site to get their buttons to animate, and now they're being asked to move into more of a mainstream programming role, but neither they nor the people asking them necessarily appreciate what that involves.
That's not anyone's fault. It will be fixed over time as the industry matures, both because knowledge will spread and because more specialised roles than "front end developer" will probably evolve. But right now, today, it is the situation in large parts of the industry.
I think that's a naive way of thinking about the problem. Do people write rich server-side web apps in Plain Ol' Python? Of course not. Why reinvent the wheel?
For a tiny app, sure, maybe it's not so bad to just use jQuery. But if you're working on something with a very rich front-end architecture, a framework gives you a very necessary...er...framework to use to eliminate boilerplate and organize your work. Not only that, but you get to minimize your code debt to your actual business logic, not the plumbing.
Maybe people are trying to avoid work? If that's the case, be careful losing your innovative and creative edge from being shackled to an interlocking formula of tools and frameworks.
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.
Do people write rich server-side web apps in Plain Ol' Python?
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.
How many lines would it be if it used a good framework?
IME any application which grows that large without using a framework ends up inventing its own. If the code's maintainable by people other than its original author you've presumably separated the routing code from the template rendering code (and have a module that's effectively a generic template renderer) from the backend service access (and again, probably have a module that's some kind of generic service access layer). You'll have a set of utility functions that's more or less equivalent to underscore. And so on.
How many lines would it be if it used a good framework?
I don't know. That project has no direct equivalent to any of the current frameworks, other than approximately following MVC for its overall architecture and using message passing/publish-subscribe in various places to keep things modular and testable.
I imagine you could achieve some of the same behaviour using data binding tools in modern frameworks, but either way you're typically looking at a little boilerplate to connect things up in the first place and then one-liners to connect individual fields from a model to the corresponding parts of the DOM. It's not clear whether there would be any savings at all, but if there were, they wouldn't be significant for any framework I've considered so far. In any case, that represents a tiny fraction of the overall code base for this application.
IME any application which grows that large without using a framework ends up inventing its own.
All software has an architecture, sure. As with any framework vs. library debate, you're trading off the benefits of having some of that architecture predetermined for you and having some of the laborious plumbing work dealt with automatically against the overhead of managing a major external dependency and any extra costs you incur if you need to do something that goes against its natural capabilities. Sometimes using a framework is a win, and sometimes it isn't.
If the code's maintainable by people other than its original author you've presumably ...
You've made some assumptions there about how web apps work, but they aren't necessarily true.
For example, much of the complexity in this particular UI comes from providing many views of the same underlying model. Some of them are graphical rather than text/form based. Some of those rely on intermediate cached data structures for their source data because rerendering an entire view from the raw data in the model can be prohibitively slow. We have an efficient and simple architecture using the same basic principles as MVC for dealing with this kind of caching. We'd derive very little benefit here from the kinds of data-binding and template-rendering functionality found in the major frameworks.
Just to be clear, libraries designed to render interactive graphical page elements efficiently, allowing for portability across browsers and different image/scene formats, are another question entirely. I'm not arguing for reinventing the wheel or arguing against using tried-and-tested code from external sources. I'm just arguing that it should only be done when the benefits outweigh the costs, and that this won't necessarily be the case when considering whether or not to use one of the modern JS frameworks as the foundation for your web app.
That's great, but it sounds like this project predates the modern frameworks. It probably doesn't make sense to try to shoehorn it into a framework at this point. But to write 100,000 of framework-less JS today on a green field project seems ridiculous. 5 years ago, some person was probably bragging about their 100,000 line app built without jQuery. 5 years from now, someone will be bragging about how all they use is Backbone.
But to write 100,000 of framework-less JS today on a green field project seems ridiculous.
Why? I've worked on non-web software projects 1-2 orders of magnitude bigger that didn't need anyone's magical framework to develop and maintain a sound architecture. How come we can't just use good design that fits the project if the software we're writing happens to be the front end for a web app?
It's about picking the right tool for the job, the same as always. For some projects and some development teams, I'm sure these modern JS frameworks and tools have proved valuable and will continue to do so. On the other hand, we're currently planning another web app that is expected to grow at least as big as the one I described earlier, and no-one on the team is seriously considering using any of the current crop of front-end frameworks. That's not because we don't know what they do or how they work. It's simply because none of us thinks it's a smart idea to build such a large and hopefully long-running project with a fundamental dependency on the kind of technology that typically measures its time at the top in months.
I see there's a lot of great suggestions and critics here!
Since it's an open source project, you can feel free to open a pull request telling which resource you think it's better to be there, or which one should be removed. As well help me correct the grammar errors. I'm from Brazil, and my english is not that good.
I'm really glad about all the opinions, and for sure the site will be improved from now on.
How does this website relate to this repo [1]? I was going to contribute some fixes to the page, but when I cloned the repo, I found significantly different content. I'm also confused as to why the website [2] says that it is based on itself [2] at the bottom of the page.
Excellent work there. I always wanted to work on such a public collection but kudos to these guys on making it a reality. I've used/read-about/tried-out most of the stuff listed there and appreciate the hardwork that has gone into putting all of it together.
I think Polymer (Google) and Brick (Mozilla) deserves a mention there as Web Components have a very high possibility of becoming the ultimate way for the future of web development.
I occasionally code in Javascript and I always get the feeling that I'm working with a language without a decent built-in standard library.
Want to work with dates? Use a third party library (or use built-in 1995-style library).
Want to format a string? Use a third-party library.
Want to do X? Use a third-party library.
Coding in e.g Python feels completely different: almost everything I need is in the standard library.
It funny, but clicking to this link caused high CPU usage for N seconds and message from Firefox:
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
This is JavaScript: The Infinitely Many Ways. Shouldn't the right way remove at least a few options from the table?
I've found a sweet spot for myself, at least for single page apps which is what I work on most of the time. jQuery, Require.js, text.js and JSLint. r.js for building release versions. Those, along with a small "view" class I wrote whose constructor takes an html string, finds all elements with a data-vid attribute and adds properties to itself pointing at those elements. Markup is kept in bite-size html files, loaded by require during development but compiled into the single js file for release. Also, I can't remember the last time I used a jQuery selector.
For tasks that are created, executed, and processed purely in code, you wouldn't. But it still has uses in other areas, especially when you need to build something up from user input.
Could you give a concrete example? Why wouldn't you be able to use first-class functions when building something up from user input? How about giving us a code snippet? The consensus in the CS community is that the command pattern disappears (becomes overkill) for languages with first-class functions. This has been noted as early as 1998 by Norvig when comparing C++ to Lisp. It's one of my criticisms of Addy's JS Patterns book. He just blindly copies the GoF patterns and many of them are not needed in languages with modern features.
I started web development 8 months ago. First I started by reading "The good parts" but honestly it's not really a good book to learn from 0 with.
The thing that really got me going? Typescript. Not only does it help with abstracting javascript syntax, but the intelisence made me not have to google every 20 characters i write.
What I've never understood is how to effectively use both objects and functions in a multi-paradigm language like JavaScript. Most introductions to JavaScript explain how to use functions in their own section and explain how to use objects in their own section, but they never explain how to combine the two techniques.
The distinction can very much exist in practice, depending on the existence and capabilities of production-quality implementations.
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.
> The same goes for JavaScript today. Given that all of the usable implementations are interpreters, JavaScript can currently be considered an interpreted language.
This hasn't been true for quite some time. SpiderMonkey and JavaScriptCore do include interpreters, but only use them while code is first running. If a function gets hot, they then JIT compile the code. V8 has no interpreter at all, only JIT compilers (and is certainly usable and in wide use). And finally SpiderMonkey even just added an AOT compiler for compliant asm.js code (which, while a subset, is indeed valid JS code).
JavaScript Patterns by Stoyan Stefanov (made the list under reading/books) is a must for anyone wanting to learn JavaScript the right way. The content volume is just right with great examples. Can be read in a week easily and get you rolling writing better code fast!
It would be nice to see the browser versions supported by all these projects in one place... this simplifies the process of elimination for those who have to support older browsers.
Java would be an example of a language with weaker OOP capabilities. Javascript can emulate classic OO inheritance and it also supports prototypical inheritance. Crockford covers this in his Good Parts book, and you can find stuff around the web.
This way I can say that Java supports OO inheritance and can emulate prototypal inheritance (this can be done in C# and I suspect in latest Java). I think the correct statement is that "JavaScript supports a simple OOP model".
Needs more description of why one might choose (or not choose) a particular tool. Readers already know "X is a framework" because it appears under the "Frameworks" heading: what is each framework good at?
More importantly, what isn't it good at - for instance, some of the bigger frameworks are tricky to integrate if you don't want to hand them control over the whole page.
Javascript is the bare tool, in order to build abstraction, you need science, i mean something like algorithmic way in rendering view with framework like React framwork, it makes sense because it makes all developer around it thinks in the same way. It's the right way to do all successful thing.
I am not too fond of the styling. Looking at it on my desktop PC, the page could use some left/right margin. On my iPhone on the other hand its rather unreadable.
:/