My Beef with Angular Conf 2017

I recently returned from Angular Conf 2017, an annual event that takes place in Salt Lake City.  It was well-organized and incredibly exciting.  There was angular swag, custom-designed angular graphics and banners, an angular rap with nerds onstage doing *terrible* attempts at dancing!   All in all, it was an A+ experience.angular

My favorite workshop covered the Angular 4 compiler.  In an hour, we picked the compilation process apart to see exactly how it works, and even turned the compiler off while we manually compiled some simple examples.

One thing that was missing from the conference was any mention whatsoever of angular 1. Those familiar with the background of angularJS know that the switch to angular 2.0 eight months ago ushered in a whole new paradigm that is not backwards compatible.  And while angular 2 is absolutely a better, faster framework, early adopters of angular are stuck in a state of limbo.  Many of us have just finished writing entire production applications using Angular 1.x with thousands of LOC.  And while there are tools to help teams upgrade, most teams end up having to rewrite large portions of their applications.  It is a costly process.

I wanted some mention of us, the invisible people stuck in a very difficult position due to the angular development team’s lack of foresight.  Based on the people I talked to at the conference, I’d guess at least 40% of us are in exactly that position.  Yes, we want to see the newest, latest, and greatest updates, but we also want some excitement around what we’re building every day, and some acknowledgement of the bind we’re in for the future.  Yet there was not even one talk or workshop acknowledging that angular 1 even still exists.

Taking this up with the angular team during a Q&A yielded the condescending answer: “Well, you just need to upgrade.”  They forget that not every company has unlimited resources like google does.  It seems they are developing for the most elite teams that have developer time to spare.

(Relatedly, another piece of advice from the angular team: update your angular package every 2 weeks to get every miniscule versioning change.  It’s a good idea in theory, but most startups don’t have engineers just sitting around waiting to read release notes and dependency changes every two weeks.)

I feel invisible to them, like my work doesn’t matter.  As an early adopter and early angular evangelist, I feel almost punished for adopting early, as our eager Angular 1 development landed my company in the legacy code position we are now in.  I love angular, but I’d love to work on a framework where I feel respected and acknowledged by the team developing it, instead of being ignored like last week’s lemonade.


TUTORIAL: Converting existing code to MEAN app

When my FullStack TA’s advised me not to try to convert my quiz application (using Angular and Angular Local Storage) into a MEAN app (MongoDB, Express, AngularJS, Node), I wanted to know why.  Why couldn’t I just generate an app using a MEAN app generator, then plunk my HTML’s, CSS’s, and JS’s in and wire it together?
I decided to try it and see how far I could get.  I used daftmonk’s generator-angular-fullstack, which includes yeoman, grunt, and passportJS, and began adding my quiz app files.  From this experience, I’ve derived some best practices to keep in mind when performing this conversion:
1. Don’t delete anything you can’t replace.  MEAN apps from a generator are very tightly wired.  Every file is there for a reason, and each one is linked to others through source hyperlinks, the gruntfile, angular routing, SASS routing, and possibly express routing.  Don’t delete any file unless you have opened it and feel confident that you can re-wire the app.
2. Try not to move things.  See #1.  Because of #1, you can have problems if you move files.  Your gruntfile and other routes expect each thing to be in a certain place.  One of the most interesting errors I had from this was when my console said there was an error with my app.js, and when I clicked on the words ‘app.js’, it showed me my index.html file.  The browser had been told that my app.js would be in a certain place, and when the app.js was not there, it grabbed another file and tried to read it as a script.  For every file I moved, I probably spent an hour fixing routes, reworking functions, and debugging strange errors.
3. The ‘Find in Files’ function in Sublime is your new best friend.  You are going to need to search for many, many terms to make sure that your app, route, and module names are all up to date.  You’ll find Sublime’s cross-file search indispensable.  Learn the shortcut: command-shift-F.
4. Look through your gruntfile.  Grunt is doing a lot of things for you behind the scenes.  For example, it will be combining all of your SCSS files and rendering them as one CSS file, which means that your views will all be modified by multiple SCSS files unless you make a change.
5. Learn your homonyms.  Within your application, you’re going to have several files with the same name.  You may have a few app.js files, a couple of index.js, a couple of route.js… take a look at your files with the same name and understand why some are intended for the front end (angular routes, for example) and some for the back end (express routing, passport).  It may be useful to draw a map of your site routes and decide whether to route each transition through the front end or through the back end.
I learned a lot through this project, but if I were doing it again, I would probably find a way to create a MEAN app by hand instead of using a generator.  On the positive side, I now have a better sense now of how the various files work together to create a fantastic app.