AngularJS Tutorial: Learn to Build Modern Web Apps(thinkster.io)
thinkster.io
AngularJS Tutorial: Learn to Build Modern Web Apps
http://www.thinkster.io/pick/GUIDJbpIie/angularjs-tutorial-learn-to-build-modern-web-apps
92 comments
Ditto for paying for a print copy. Some tech books I'd rather read outside in the sun; it forces me to actively try to internalize more instead of hopping to/from the console every minute.
Maybe http://lulu.com ?
Maybe http://lulu.com ?
Agreed with the 'reading my mind part'. Though it is high time for fantasy season so its probably at the front of everyone's mind right now. Anyway, very excited to get into this.
Hey all - we'd love to hear any questions, criticism, or ideas you have.
Also, we have a pdf version of the ebook available for $25 on the site, but we'd like to give all of you on HN a 20% discount. You can go to this URL to get the cheaper price - http://gum.co/SUry/awesomehners
Thanks for all of your support!
Also, we have a pdf version of the ebook available for $25 on the site, but we'd like to give all of you on HN a 20% discount. You can go to this URL to get the cheaper price - http://gum.co/SUry/awesomehners
Thanks for all of your support!
It would be great to see a demo of the app being built. Either a couple of minutes of video or an actual link!
Once the tutorial is complete (within the next week or two) we'll be posting the demo :)
I'm more of a visual learner and something like this would be super helpful.
I agree with this. A great tutorial like this should be accompanied by a demo!
Like I said in another comment, the git clone command should be fixed to use https instead of ssh. That way it would be able for users that have no access to the repository (almost anyone) to clane it without any problems.
git clone https://github.com/msfrisbie/mean-stripdown.gitThere's also: yearofmoo [0], the AngularJSLearning Index [1], David Mosher [2], tutorialzine [3], and the ng-newsletter. [4] I would like to see the Integration With Other Languages/Frameworks section expanded (D3, PouchDB, etc). Are you guys planning on expanding on that?
[0] http://www.yearofmoo.com/
[1]https://github.com/jmcunningham/AngularJS-Learning,
[2] http://www.youtube.com/user/vidjadavemo/videos
[3] http://tutorialzine.com/2013/08/learn-angularjs-5-examples/
[4] http://www.ng-newsletter.com/posts/beginner2expert-how_to_st...
[0] http://www.yearofmoo.com/
[1]https://github.com/jmcunningham/AngularJS-Learning,
[2] http://www.youtube.com/user/vidjadavemo/videos
[3] http://tutorialzine.com/2013/08/learn-angularjs-5-examples/
[4] http://www.ng-newsletter.com/posts/beginner2expert-how_to_st...
I get a lot of requests to expand the tutorial with other frameworks, as you mentioned. Ultimately, the tutorial itself will be structured in a way that allows for the best presentation of concentrated learning. However, this doesn't mean that we won't be releasing other content covering integration with other frameworks.
I'll take that as a no since you haven't responded.
Working with a large Angular app, I've found it much nicer to split away from the "Rails"-style convention of grouping by type (controllers, models, etc) and instead grouping by modules. This plays especially well with Angular where you can group everything within a module together and include a single module which ties all the dependencies together.
Curious if others do something similar and group code together by modules or does everyone group by type?
Curious if others do something similar and group code together by modules or does everyone group by type?
Can you give an example of how you've organised the modules? Like one per model (a products module) or by section of the site?
If I'm not mistaken, instead of splitting into:
I've switched to this convention as well - less context switching of files.
controllers/
users.js
teams.js
models/
user.js
team.js
modules/
users.js
teams.js
I've switched to this convention as well - less context switching of files.
I don't understand what you would have in "models". Services?
I recently spent days writing AngularJS app and I came to same conclusion that I should have split the app into modules.
Even though the style of grouping together Controllers and Services works well, it still won't be easy to maintain when the size of app grows big.
I like grouping by functionality. All the account-related code in one directory, all the order-related code in another, etc.
Bugs me to have the order logic spread out in the views, models, controllers, hepers, libs, etc folders.
Bugs me to have the order logic spread out in the views, models, controllers, hepers, libs, etc folders.
I'm always excited to structure my projects in a different more effective way - well, it's more of a struggle - anyway, this sounds interesting. Can someone elaborate on the file structure and structure of files and the way they connect?
I'm rolling with a MVP structure that frankly is becoming cumbersome with my current project's size.
I'm rolling with a MVP structure that frankly is becoming cumbersome with my current project's size.
What I've done myself and found it pretty scalable is as follows:
appShell/ views/allbaseviewshere viewmodels/controllers or viewmodels for the core views services/baseservices moduels/ account /views/ /viewmodels/ /services/ order /views/ /viewmodels/ /services/ /controllers/ static /css/ /js/ /images/
AppShell contains the app starter page, controllers and util services (showing popups, utility functions etc.) AppShell/Views contains all the UI Skelton for the app (bootstrap main page, etc)
Every folder inside "modules" contains views, controllers (viewmodels) and services belongs to only that module. Account folder contains views for user registeration, sign in, change user profile, etc. etc.
This way you can keep building new moduels in their respective folders without touching the frozen code (already built modules).
Each module talk to outside world using "services". No module can touch anything belongs to other modules but with "services".
appShell/ views/allbaseviewshere viewmodels/controllers or viewmodels for the core views services/baseservices moduels/ account /views/ /viewmodels/ /services/ order /views/ /viewmodels/ /services/ /controllers/ static /css/ /js/ /images/
AppShell contains the app starter page, controllers and util services (showing popups, utility functions etc.) AppShell/Views contains all the UI Skelton for the app (bootstrap main page, etc)
Every folder inside "modules" contains views, controllers (viewmodels) and services belongs to only that module. Account folder contains views for user registeration, sign in, change user profile, etc. etc.
This way you can keep building new moduels in their respective folders without touching the frozen code (already built modules).
Each module talk to outside world using "services". No module can touch anything belongs to other modules but with "services".
I do it the way you just mentioned. I create specific modules and have them inject their dependencies. Each modules I create has its one or more models within its domain. I was going to go the repository route (one module per type) but it seemed overkill.
For front-end such as Angular I always group in modules, usually nested modules for larger apps. For back-end systems sometimes type makes more sense, especially when the app grows quite big and uses a layered architecture.
I do the same as you. Group by Module - which in my humble opinion is the real intention of the modules.
Oh between I do group by Type inside of a module.
Oh between I do group by Type inside of a module.
Why not both?
This article/book was marked as [dead] for a while, then got unmarked. How exactly does that happen?
I'm still not convinced about Angular's Dependency Injection thing. The problems it allegedly solves don't clearly outweigh the ones it certainly creates.
It claims to provide concern isolation, which facilitates testing and cleanliness. I don't think it helps that much.
But it has a middle-stage learning curve, more callbacks than I'd like, and implicitness of dependencies. For example, i.e. you need to know what $scope-like params are "supposed to contain" on every function that uses them.
Also, I find the naming spotty: "directive", "module", "injector", "compile" etc. lack specificity. They are not as bad as "Manager", "Data", "Info" and "Object", but they are not good.
It claims to provide concern isolation, which facilitates testing and cleanliness. I don't think it helps that much.
But it has a middle-stage learning curve, more callbacks than I'd like, and implicitness of dependencies. For example, i.e. you need to know what $scope-like params are "supposed to contain" on every function that uses them.
Also, I find the naming spotty: "directive", "module", "injector", "compile" etc. lack specificity. They are not as bad as "Manager", "Data", "Info" and "Object", but they are not good.
For example, i.e. you need to know what $scope-like params are "supposed to contain" on every function that uses them.
Outside of the controller-view relationship, nothing in AngularJS requires passing data in $scope objects, and you definitely shouldn't.
Why do you think dependency injection doesn't help exactly? I personally don't know of any other pattern to effectively test/mock things like HTTP interactions. It's also a pattern that's used by many, many other languages and frameworks - what's the alternative you're thinking about?
> The only exception to this is the relationship between views and their respective controllers.
My point exactly. The relationship between views and controllers is important. Using $scope there is sucky (also, its name is too generic).
> Why do you think dependency injection doesn't help exactly?
I think that dependency injection helps, and I use it all the time. I just don't like Angular's take on it.
It relies too much on anonymous functions. I think that 'new' (or equivalent) and 'globally accessible glasses or factories' (or equivalent) are just fine in lots of cases. They make the dependencies implicit, yes, but that's secondary to the fact that the code is much more readable.
My point exactly. The relationship between views and controllers is important. Using $scope there is sucky (also, its name is too generic).
> Why do you think dependency injection doesn't help exactly?
I think that dependency injection helps, and I use it all the time. I just don't like Angular's take on it.
It relies too much on anonymous functions. I think that 'new' (or equivalent) and 'globally accessible glasses or factories' (or equivalent) are just fine in lots of cases. They make the dependencies implicit, yes, but that's secondary to the fact that the code is much more readable.
The tutorial recommends starting your server using `node server`.
With MEAN a Grunt file is provided. Running the server with `grunt` will make grunt run the server and then watch the directory for changes - restarting the server and refreshing the page as necessary.
Much easier.
With MEAN a Grunt file is provided. Running the server with `grunt` will make grunt run the server and then watch the directory for changes - restarting the server and refreshing the page as necessary.
Much easier.
I tried to use grunt as you say with the tutorial, but it didn't work. They say they are using a stripped down version of MEAN, so maybe they took that out? Do you know a good tutorial on adding it back in, as I like the sound of the functionality you're talking about...
Yes. They have stripped out the gruntfile. Just copying this from the original project into your solution should work.
https://github.com/linnovate/mean/blob/master/gruntfile.js
Make sure you have grunt installed.
http://gruntjs.com/
https://github.com/linnovate/mean/blob/master/gruntfile.js
Make sure you have grunt installed.
http://gruntjs.com/
Thanks for that.
For anyone else trying to add grunt, you need to copy over the gruntfile.js and add the grunt dependencies to the dev section of package.json in the root directory of the project. Then you might also have to remove and reinstall the grunt nodemon package (grunt threw up instructions on how to do this when I first ran it)
For anyone else trying to add grunt, you need to copy over the gruntfile.js and add the grunt dependencies to the dev section of package.json in the root directory of the project. Then you might also have to remove and reinstall the grunt nodemon package (grunt threw up instructions on how to do this when I first ran it)
Is there a demo of the finished app somewhere? I don't want to read or buy the tutorial before I see how good the actual result is.
To add on to what mfrisbie said: If you want a good 3rd party opinion on the quality of the tutorial, you might want to see what Brad Green (the guy who manages the AngularJS team at Google) has to say about it - https://twitter.com/bradlygreen/status/373134106936090624
The tutorial is still having the finishing touches put on it, once it's completed there will be a demo available.
One advantage of the MEAN stack is that you only need to know javascript to start developing on it, which saves time and brainpower to get started.
That being said, I'm curious if there are other advantages to learn the MEAN stack?
That being said, I'm curious if there are other advantages to learn the MEAN stack?
Javascript is a harder language then most web development languages when you really get into it (OOP, inheritance, scope, first class functions, callbacks, closures, compile time errors). If you go into it thinking your going to save brain power you may be in for a rude awakening.
The advantage is you can do real time async stuff a lot better then with other frameworks.
The advantage is you can do real time async stuff a lot better then with other frameworks.
> OOP, inheritance, scope, first class functions, callbacks, closures, compile time errors
How does any of that make it harder than "most web development languages"?
> The advantage is you can do real time async stuff a lot better then with other frameworks.
How so? AFAIK, the only difference is that in Javascript you can only do async stuff, you don't really have a choice.
How does any of that make it harder than "most web development languages"?
> The advantage is you can do real time async stuff a lot better then with other frameworks.
How so? AFAIK, the only difference is that in Javascript you can only do async stuff, you don't really have a choice.
OOP: This is done with Functions not Classes.
Inheritance: Theres at least 3 different ways of doing this, 2 of them suck again use Functions instead of Classes.
Scope: Variables outside a function are global and theres no block scoping.
First Class Functions: This is not something most people are used to and can become confusing
Calbacks: Callback Hell, you can shoot yourself in the foot and mess up your code if you don't put extra thought keeping things organized and thinking through async/sync
Closures: Theres function scoping but not block scoping, this can be confusing if you're used to block scoping
Compile Time Errors: Theres very few compile time errors. If you are using a Function that requires the "new" keyword and you forget it your code will still run and all sorts of wacky things will happen.
Yes other languages have these features but they are harder in Javascript, thats why Javascript is a harder language.
Look into Meteor.js - try doing that in PHP. That's how so. And you can write Sync code if you want to.
Yes other languages have these features but they are harder in Javascript, thats why Javascript is a harder language.
Look into Meteor.js - try doing that in PHP. That's how so. And you can write Sync code if you want to.
I know all this, but I still don't think it's any harder than other languages. I have been following Meteor since the beginning, but I'm not impressed anymore to be honest. Seeing the video for the first time was quite shocking, but in the end they didn't really deliver. Using it is still a pain.
> try doing that in PHP
Meh, PHP is still the king, and it will stay there for a long time. Languages and platforms with crazy features pop up every day, but that's not enough for actually getting things done. You need a community, mature libraries, and a healthy ecosystem in general.
If you want something challenging try Clojure. It is by far The Best Language (tm) IMO, but you still can't even build a website with it. The only web framework available died and got separated into libraries, and everyone ends up wiring everything the way they can. Some people use Java libraries, some others reimplement everything. It's pretty messy.
> try doing that in PHP
Meh, PHP is still the king, and it will stay there for a long time. Languages and platforms with crazy features pop up every day, but that's not enough for actually getting things done. You need a community, mature libraries, and a healthy ecosystem in general.
If you want something challenging try Clojure. It is by far The Best Language (tm) IMO, but you still can't even build a website with it. The only web framework available died and got separated into libraries, and everyone ends up wiring everything the way they can. Some people use Java libraries, some others reimplement everything. It's pretty messy.
Most javascript code is actually synchronous. It is the event loop (xhr requests, timers, timeouts, etc.) that is async. TLDR, some parts of the language are sync, some are async
I've just kicked off my latest project using the MEAN stack.
The main advantage for using the stack has been a huge time saving in getting the project set up. NodeJS and express is hugely flexible about how you structure your source, which can also be a downfall in the additional mental load of deciding where stuff should go. MEAN does this for you.
The disadvantage has been where I want to do things differently from how MEAN is set up. For example, MEAN uses Bootstrap v2, I wanted Bootstrap v3. It was a slight faff updating it. It would probably be harder if you eg. wanted to use MySQL instead of MongoDB.
There is still a lot that you need to learn before you will get an app fully up and running, but with MEAN you can get cracking on stuff before you know it all. I don't know anything about Grunt yet, but can still use the Grunt file provided to run the server.
Well worth using in my opinion.
The main advantage for using the stack has been a huge time saving in getting the project set up. NodeJS and express is hugely flexible about how you structure your source, which can also be a downfall in the additional mental load of deciding where stuff should go. MEAN does this for you.
The disadvantage has been where I want to do things differently from how MEAN is set up. For example, MEAN uses Bootstrap v2, I wanted Bootstrap v3. It was a slight faff updating it. It would probably be harder if you eg. wanted to use MySQL instead of MongoDB.
There is still a lot that you need to learn before you will get an app fully up and running, but with MEAN you can get cracking on stuff before you know it all. I don't know anything about Grunt yet, but can still use the Grunt file provided to run the server.
Well worth using in my opinion.
It's super simple to set up. We're actually thinking of doing a Firebase version of our tutorial, as there would be no local set up (other than hosting the static files).
Looks good, and useful to me, nice work.
Will you be covering security in any detail? Most people seem to miss this and I'm discouraged to see when I download the MEAN project this is based on it has serious security flaws.
For example, if you view the articles list at /#!/articles and make a note of any article ID, then visit /article/<article_id> it will return the article author's hashed password, salt and email address in addition to the article content. This also works while logged out. Kinda scary if people are using this as a template for their own apps.
Will you be covering security in any detail? Most people seem to miss this and I'm discouraged to see when I download the MEAN project this is based on it has serious security flaws.
For example, if you view the articles list at /#!/articles and make a note of any article ID, then visit /article/<article_id> it will return the article author's hashed password, salt and email address in addition to the article content. This also works while logged out. Kinda scary if people are using this as a template for their own apps.
Yeah that freaked me out too. I'm not super familiar with mongoose either so at the time I couldn't figure out how to leave them out of serialization always. I could do it for one-off calls but there should be a way to generally whitelist I'd think.
That was one of the first things I noticed when examining the MEAN stack. The final version of the tutorial will take care of this flaw.
The best place I have found to learn about Angular is http://egghead.io . The videos are really clear and concise.
Many of the more confusing Angular fundamentals that many tutorials like these don't stress egghead.io has short 2 to 3 minute videos explaining in very clear terms.
PS. I know I sound like a shill, but I have nothing do with egghead.io other then I've found them immensely useful.
Many of the more confusing Angular fundamentals that many tutorials like these don't stress egghead.io has short 2 to 3 minute videos explaining in very clear terms.
PS. I know I sound like a shill, but I have nothing do with egghead.io other then I've found them immensely useful.
We have all the egghead videos, complete with ASCIIcasts and source code, on our site: http://www.thinkster.io/egghead.
And we structured all of the videos into one place to learn from here - http://www.thinkster.io/pick/GtaQ0oMGIl/a-better-way-to-lear...
I really like this is not an ebook per se, but an interactive tutorial. The checkbox to save your progress are really great :) Congratulations!
Thanks! We're still working on simple ways to improve the learning experience - would love to hear any ideas you have on this :)
Angular: ad hoc crowd sourced documentation at it's finest.
Kind of surprised how in depth the tutorial goes, but only manages to mention the word "test" once and doesn't cover the fantastic testing back end included with the AngularJS seed (https://github.com/angular/angular-seed).
Unless the person learning AngularJS has never done any automated testing before, I can't see any reason why not to be using tests as a tool to further your own learning. I learned Go last year relying heavily on tests, first specifying what I wanted to achieve in a high level test, then learning as I figured out how to make the test pass.
Unless the person learning AngularJS has never done any automated testing before, I can't see any reason why not to be using tests as a tool to further your own learning. I learned Go last year relying heavily on tests, first specifying what I wanted to achieve in a high level test, then learning as I figured out how to make the test pass.
Believe me, a big testing section is on the way.
Nice tutorial. One critique is the use of the "ng" prefix for your app's modules, which I believe is discouraged by the angular core developers since it's supposed to denote core angular functionality.
Looks like a solid walk through of building an angular app.
OT but the fantasy football twist is great. I only just started playing this year so I've been learning a lot. We're playing the uk version but I guess it's much the same. I've found it interesting how much strategy there is and how much data I can analyse.
We have a startup in the construction industry so wanted to use it as a tool for keeping a sort of weekly offline / banter conversation going on with clients. Turns out that I actually enjoy too!
OT but the fantasy football twist is great. I only just started playing this year so I've been learning a lot. We're playing the uk version but I guess it's much the same. I've found it interesting how much strategy there is and how much data I can analyse.
We have a startup in the construction industry so wanted to use it as a tool for keeping a sort of weekly offline / banter conversation going on with clients. Turns out that I actually enjoy too!
Heads up - the link[1] where it says "If you need a refresher on Angular services, go through this video" leads to a video on filters, not services.
- [1] http://www.thinkster.io/pick/sFObNwt4rA/angularjs-built-in-f...
- [1] http://www.thinkster.io/pick/sFObNwt4rA/angularjs-built-in-f...
Nice work! I love how all the individual components are one big scrollspy. We (Coursefork) had a call with Eric yesterday to figure out how to make this kind of material "forkable", but something we didn't talk about was this idea of charging for the "source source code". What exactly does that mean?
This looks very interesting, thanks for sharing. I especially like that you decided to go with a fantasy football app - can't say I've seen many tutorials do that ;) And last but not least, I like that you chose the MEAN stack, for no reason other than I am unfamiliar with it and have been meaning to look into it.
looks like a great guide.. i was working through the original "how to learn angularJS" tutorial, but it got dry through some parts because it was too much material at once without too much of the application behind it in the big picture. I think this tutorial will definitely help with that, good looks!
Anytime now some of you will be contacted by recruiters looking for people with 10 years AngularJs experience.
Awesome tutorial! I haven't gotten around to reading it all yet however I noticed it provides you with a base to begin coding which is good but is there anyway you can do a short writeup on how exactly that base is created?
The tutorial explains only what you need to know about the base to get started. If I explained the entire boilerplate of the MEAN stack, the tutorial would become a monstrosity.
Is angular the reason this site scrolls and renders content all weird?
No - what platform/browser are you using?
Safari works better then Chrome. I have a retina display so perhaps thats it. Its strange behavior, first it seems that greyed out images/css is loaded, then when you scroll the non-grey version appears and text appears as well that was not there before. Anyway I think this was probably designed this way but it glitches out weird when scrolling. Not a big deal just kinda distracting, glad its not part of Angular.
Thanks for the detailed info - I'm going to look into this. Our HTML/CSS structure is a little funky in order to make our sidebar drawer work smoothly, so it probably has something to do with that.
great tutorial for anyone looking to get into the MEAN stack, easily the best on the net currently and they seem like there planning on adding a lot more to it also over time
I love that the example site being built in your tutorial is a fantasy football app, great choice.
Looking forward to the player draft functionality with socket.io
Looking forward to the player draft functionality with socket.io
ESPN's FF interface is horrendous, I had to do something about it. Next sections of the tutorial are almost done, keep an eye out!
Hmm, didn't make it past the first check mark.
"Permission denied (publickey). fatal: Could not read from remote repository." -git
"Permission denied (publickey). fatal: Could not read from remote repository." -git
Great tutorial! Just wondering what the timeline was looking like for the rest of it? Looking forward to following along.
I've been experimenting with Angular today and have found this super helpful, thanks!!
Great work, looking forward to future parts of this tutorial! Will definitely buy it.
Signing in with Twitter wants to post as me and read my tweets, how come?
Your "Support us!" button has a typo- source source code!
Thanks for pointing that out! Will fix asap
No problem! Guide looks solid otherwise- will give it a run through when I have some free time :)
Why does the title say free but the link says $25 to download?
Looks like you can get the source code and the eBook as a .pdf for that amount.
I think of an ebook as something I can read without internet access. Is there something like that available for free on this website?
Edit: Print to PDF works, should have realized it was a single page app ;-). Thanks!
Edit: Print to PDF works, should have realized it was a single page app ;-). Thanks!
We are giving you free access to the ebook online. If you want to take it offline, we've made a nice PDF version that you can purchase to support our ongoing efforts. If you don't want to support our ongoing efforts to make the tutorial better, you can always 'print to pdf' and take it with you offline.
Thanks! This is what I am looking for.
Then this came out. Super excited for the weekend so I can dive on through. Thanks, Matt -- but stop reading my mind.
(n.b.: I'd be more than willing to pay sticker price if I could get a physical copy instead. I know it's lame, and slightly more effort, but I don't have a monitor setup at the moment so I'd rather leaf through a book than scroll through an alt-tabbed .pdf.)