found drama

get oblique

Tag Archives: frameworks

“a good thing being able to configure a framework”

by !undefined

The Future of the JavaScript front-end framework:

More/less the same drum getting beaten by so many right now (see also: the Joreteg’s announcement about Ampersand, although this opinion piece is probably a better illustration of the theme) – and by that I mean: “Go ahead and provide an all-inclusive framework, but be modular so I can swap out the parts I need.” Which is great, but I would say misses a big point: discoverability of those modules. Say what you will about Spring’s role in the Java eco-system, but its worthwhile to align with a single trustworthy starting point. Part of what’s missing from the “framework fatigue” discussion is just that – that our “big frameworks” only provide a relatively thin slice of what our whole app needs and we’re in “contrib” (and/or plugin, and/or mixin, etc.) hell for everything else. This glosses over the BIG-Big frameworks of a few years ago (e.g., dojo, ExtJS, YUI), but the point stands.

(A version of this previously appeared as my comment on Prismatic.)

surrounded by all that framework magic

by !undefined

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.)

“my fallible conclusion”

by !undefined

Opinionated Rundown of JS Frameworks:

Henrik Joreteg, writing at the &yet blog. He does a brief teardown of 5 front end MVC(ish) frameworks (their pros and cons) and while you’re busy coming up with counter-arguments against his inevitable thrust about using “no framework”, he goes on to make almost exactly all of those same points.

Only to wrap it up with what winds up feeling a bit like a sales pitch for his Ampersand framework.

This is not necessarily bad, and he does acknowledge that each team needs to decide for itself what it wants/needs in order to make it effective. At the end of the day, this isn’t a competition to find out what framework is the best (spoiler alert: none of them) — it’s a struggle to find effective work strategies so that we can build great software that solves real problems for people.

Linkdump for March 5th

by Rob Friesel

Debugging JavaScript in a Hostile Environment E.J. Dyksen, writing at Mutually Human. It's an interesting story of how they handled the debugging for this particular environment (WebBrowser Control in a VB app), even if the solution itself is not especially novel. The one surprise (to me) was that the Angular $log service was not mentioned. […]