Posts Tagged ‘frameworks’
Although this list is not actually a complete or accurate list of my currently open tabs (I have since closed some, as well as, working on a page for DevTools docs), this is a list of tabs I have either open, or have opened at one time.
You may have noticed more and more recently, that Angular.js is growing in popularity among Front-end Developers. I’m personally a big fan of it, and I would like to share some more things which I’ve come to learn about it in the near future.
Until the, here’s a list of tabs which are mostly focused on developing with Angular.js, but a few others thrown into the mix as well.
- The Hitchhikers Guide to the Directive
- Communicating Between Directives
- Increasing Productivity
- Don’t Guess it, Test it
- Test Driven Development with Grunt – Screencast
- Accessing Properties Methods Defined Under $rootScope from Controllers in Angular.js
- Effective Communication Skills
- Angular.js Cheatsheet
- How to Create Angular.js Services in 4 Different Ways
- Experiment with Angular.js and Jasmine using these plunks
- Angular.js Cheat Sheet
- $provide Methods / Building Up with AngularJS
- Angular Design Patterns Best Practices
You can tell that Angular.js has really picked up some momentum judging by this graph. I wonder how long this climb to most popular will continue.
I don’t think I am alone in I say “Enough already with the need to fill in all the gaps that any one stack may have, there are 10 other options that exist for any given thing”. Sometimes I wish there was a way to freeze the development of new libraries and frameworks so that a chosen few can be determined from those that exist already. I hate to say it, but people need to stop releasing frameworks, libraries, and any other chosen name to categorize these things (tasks, packages…). I mean I understand why and do get it. I would also love to build that next game changing workflow simplifying aha.js framework, which ideally would bring us back to the simple days, when jQuery was all that you needed to start building something cool, while still keeping the various combinations of the “new stack development” that has become built-in. I’m still in the dream phase 1, and the beta release is set for some time in the future, indefinitely…
Again, I am not the only one who is feeling fatigued from the massive framework and library overload that front-end development has transformed very quickly into, resulting in dozens of options that have options with optional options you can opt to use or not. By options, I am referring to the many solutions for any single tiny piece of the puzzle for a given project that one can have which leaves the developer with the problem of choice.
On one hand, this isn’t a terrible problem to have. Not needing to reinvent the wheel is always best, so if there is a piece of code that already exists which solves a problem you need a solution for, then the obvious thing to do is use it. It’s silly to not reuse existing code wherever possible.
That said, choose your tools carefully as you cannot always easily swap them for something else later on when a project is in mid-development. Deciding on what technologies to use and which tools will be used as part of the workflow has become much more involved. There are many things to take into consideration and we all have our own particular preferences when it comes to things. It is necessary to weigh all the options so you are well-informed before settling on what to use.
When it comes to the problem with streamlining development workflows like the management and use of packages, frameworks and libraries available to aid in getting projects setup quickly, there is still a lot of work to be done and many people are working on improving things. However, this could create an alternative problem, multiple solutions to a problem yet again, or otherwise designed in a way where things are released as a full stack set of tools designed to work as a bigger “default” stack state.
The way it is now, depending on the person or project concluding any one technology, tool, concept, etc. to be better than another one might vary one day to the next. The evolution of front-end development is so rapid that any attempt to conclude anything will prove to be useless. I look forward to when things start to become more straight-forward again as it was a couple years ago. I would love to have all the new technologies out there to just simply work together without being required to become an expert of them all beforehand just so you can make them play nice.
You could say my excitement for new technologies is more in what they make possible and not with trying to combine a handful to make what would be possible in doing so. I feel like things have fallen into a lull or like we’re stuck in a rut spinning the wheels but not really making much needed valuable progress in solving the larger bigger problem, one we all must endure in the meantime until there is something to bridge the gap in workflows.
What’s going to be that solution, or result? I can’t imagine it’s going to be getting too much better anytime soon, so hang on for a wild ride, at least for the time being from what it looks like.
I’d love to know what you’re thoughts are on the matter in the comments