A Few Paragraphs on Angular 2


Look! I’m back! I may end up writing here more often that I have over the past couple of years as I’m significantly cutting back on the amount of time I spend on Twitter. If you’ve enjoyed me saying “get off my lawn” on Twitter over the past few months, you’ll have to come here to read those thoughts. There is the benefit of paragraphs and formatting on the site, so there’s that. If you’re curious what the hell I’m talking about, this tweet-storm is a great example. That kind of stuff will live here now, if the mood strikes me.

The mood has struck! Read on!


I just finished up a long-term consulting gig and, while I’m kicking off a shorter-term a project for another long-term client, I’m also looking to set up my next big project. That’s the big question for me right now- what am I going to be doing for 2017?

As part of that process, I’m finally going to do a deep dive into Angular 2. I worked with it a little bit at my last client, but that’s not really enough for me to really feel like I know it. People are interested in it. I’m interested in it. So… I’m looking at it.

I’m starting with Switching to Angular 2. I’ve got a bunch of Angular 1.* experience so a book written for people looking to move from 1 to 2 seems like a decent place to start.

Between the book and the exposure I had to it on my previous project, my initial take is that it feels like everything that’s right and wrong about the web all wrapped up into one package.

It’s “right” in that it’s really well put together. The general framework architecture combined with the use of TypeScript make it a very compelling alternative for certain types of applications and teams. Like Angular 1 before it, it works for me for some things.

It’s “wrong” in that it’s just ridiculous. It doesn’t make sense for most of what people actually need to do on the web.

Modern web development is generally too damn complicated for its own good. That complexity is heightened by the interconnected, patchwork nature of modern front end development. If you buy into this mode of development you are relying on a matrix of software that no human could possibly vet. You’re basically acknowledging you’re going to live with random bugs, dependency issues, and reams of alpha software you’re supposed to trust going into production.

Angular 2 is exactly that.

On my first project with Angular 2, I experienced weeks of flaky builds as the development landscape shifted randomly underneath us. Many dependencies were also flaky and/or barely maintained. So much fun! Once the builds stabilized, I was flabbergasted to take a look at how much code was required to run the application. node_modules had over 1000 dependencies and our main.bundle.js was over 4.5MB. This was for a read-only application. It didn’t even do anything. I can’t help but think that’s ridiculous. For complicated, large-scale applications I can see the benefits, but for something simple… holy cow that’s a lot of code to solve the kinds of problems I was able to solve with a few hundred KB of pure JavaScript in 2006.

More on it as I get deeper into this dive.


On a final, related note, I’m really interested in exploring a way to marry the best of modern web development with a more stable, accessible (in both senses) and minimalist approach. There’s got to be something more appropriate for smaller applications and general “web” development.





Source link

Leave a Reply

Your email address will not be published. Required fields are marked *