Learning AngularJS Magic: Expressions: Neville Samuell presents a very approachable and easily digestible explanation of AngularJS expressions. He introduces the $parse service and goes as far as introducing the lexer, which is great because by the end…
Regulex：JavaScript Regular Expression Visualizer.:
Pretty nifty little tool that generates railroad diagrams for your regular expressions.
Meta programming with ECMAScript 6 proxies:
Dr. Axel Rauschmayer’s thorough discussion of ES6 proxies.
What you should know about JavaScript regular expressions: Bjorn Tipling on the quirky corners of regular expressions in JavaScript.
leftoversalad:
Jeff Whelpley, “Screw You, Angular”: Recently there has been a great little triangle of battles going on among Ember, React and Angular. The reason why these debates are so great is that each of the frameworks have various pieces that are pure genius (ex. Angular DI, React Virtual DOM, Ember Router) and it is not […]
Optimize for change. It’s the only constant.:
Alas — the snark and schadenfreude are terribly unconstructive and show a shocking lack of empathy from someone who has otherwise gotten a rather fantastic reputation for having exactly that kind of empathy.
There’s an unstated assumption that people selected AngularJS for their projects simply because it was “backed by Google” or because it was some kind of shiny thing that everyone was playing with “at the time” — and while this may be true for some, there are many who have done their homework and did their framework/library bake-offs and looked at their specific situations and said: “You know what? AngularJS is the best solution for us for these legitimate reasons.”
Right. So the schadenfreude? Not helping anyone.
Which is unfortunate, because this point is really good and really important:
As a leader on a dev team, I personally consider it too risky to invest our team’s energy in learning the intricacies of a particular framework; I want our team to learn how to solve problems in JavaScript by combining the right tools for the job.
And/but here’s the twist: your customers never give a shit about what language or framework or library you use to solve their problem, they just want you to solve the problem. In that respect, domain knowledge is more valuable than any piece of technical minutia you’re picking up along the way. Which is not to say that that technical knowledge is not important — after all, these are (probably) the tools you need to use to solve exactly the problems in that domain you’ve worked so hard to learn something about. Which brings us full circle: do you burn time writing your own thing? or searching for and stitching together the little libraries? or buy into that larger framework which is going to allow you to off-load a lot of that?
Each team needs to decide this for itself. What trade-offs are you willing to make to get where you’re going? Because don’t believe for a second that you can just pick “a loose collection of a bunch of optional modules” and say that you’ve “optimized for change”. You’re just choosing a different set of dragons to wrestle with.
And anyway, everyone needs to draw a collective deep breath and chill the hell out over this. (1) Your software choices and architecture designs are always wrong to someone. (2) Maybe this event serves as an important wake-up call to you and your team and you come out on the other side of it having learned some valuable lessons about how to build front-end apps. (3) And/or just because no AngularJS upgrade path got announced doesn’t mean there won’t be one and maybe 6 months from now there’s a blog post that reveals just how everything is going to be just fine.
Regardless: relax, don’t worry, it’s just software.
UPDATE: Just about as soon as this was published (after simmering overnight as a draft in the queue…), I saw that Joreteg has re-written the post to be… less harsh. I’ve decided to leave my post as-is because if nothing else it will serve as a reminder to myself that we can all act too hastily in our responses at times. The main points of my own response remain the same: (1) try to be constructive in your criticism; (2) do your own research and make the right choice for your team; and (3) maybe just maybe it’s still too early for everyone to freak out as much as they have.
Why I Don’t Want Your JavaScript Framework but I Love You:
A very worthwhile read from Keith Rosenberg.
If there’s a tl;dr then it’s this: choose when to use a framework, not which framework — if you choose any framework at all, and/but/so when you do: take the time to get to know the source code, not just the docs.
Rosenberg has lots of good points in here, and while no single pithy quote jumped out as pull-worthy, it’s worth noting that he doesn’t simply dump on frameworks (as some do) but rather tries to ask the more interesting meta-question re: why are you even choosing to use one at all?
Obviously there are plenty of reasons to use a framework. There’s that old adage about either spending your time learning the framework or spending your time building all the home-brew infrastructure that turns in to your own personal framework. What Rosenberg points out though is that if you’re not digging deep into the source, then you’re not really learning, and you wind up in a bad place anyway — surrounded by all the framework magic that’s undocumented and you don’t understand, can’t debug, and spend days trying to work around, over, under, or through.
(Having been guilty of the above, and having been there myself, I cannot stress that enough.)
As he says: take the time to think about your problems and spend some time designing your application and discovering what you really need, instead of just diving in with your AngularJS life-jacket because that worked out so well on that last thing your build.
(Previously/related: RE: Developers are calling it quits on polyglot programming.)
“The fundamental problem with viewing JavaScript as the new VM is that it creates the illusion of control. Sure, if we are building an internal Web app, we might be able to dictate the OS/browser combination for all of our users and lock down their machines to prevent them from modifying those settings, but that’s not the reality on the open Web.”
–
Aaron Gustafson, A Fundamental Disconnect.
This isn’t (just?) FUD around JavaScript and web apps, it’s the reality. And this is the timbre of so many posts over the years: that you have no control over the ultimate runtime of your application’s interface and therefore [fill in the blank].
And so we’re left in this weird never-never land where we can’t really spend all the resources that we need to ensure that we’re reaching (literally) everyone, but neither can we justify rubber-stamping a “best in WebKit (on top of modern hardware)” banner as a way of coming in under-budget. There’s the notion that you can just follow a couple of best practices and be just fine but this doesn’t really acknowledge that not everyone doing front-end development is a Front-End Developer.
To Gustafson’s point about Hanselman’s point about JavaScript deployment basically being a VM… I wouldn’t say that he’s being unfair. After all, Hanselman is a smart guy and I must imagine that he’s making these statements in a sort of Inspired Visionary way. But at the same time… yes, calling the browser a VM is over-selling it a bit. And for all the reasons that Gustafson spells out.
Important Announcement Regarding YUI:
I was never a big fan of YUI, but it was an interesting framework, and an example of how to approach the design and assembly of a large, comprehensive project. The list of contributors is long and distinguished. I’m a bit sad to see them torpedo the project, but not all together surprised either.