Open source responsive charting library for JS
Know a full stack, even if you don’t work it every day
A very few brave developers still customize every aspect of their sites and apps, from polishing interface design on the front end to optimizing database connections on the back end. Many more people choose standard sets of tools — the LAMP stack or MEAN stack — and hope that they can stay within the lines enough to get help. Building effective web systems, though, means understanding how the layers of applications interact and their communications styles. At the very least, it means understanding the layers with which your work interacts.
This reflects my technical skills philosophy pretty succinctly although I have definitely grown to prefer the front end work.
The analogy that I use is that I prefer finish carpentry over framing or plumbing because, although both the other disciplines are important, the mainly interacts with the visible surface of the thing.
One last major piece of the puzzle that is AngularJS 2.0 is the persistence story. AngularJS started with pure XHR request support (through $http and $resource). Sockets were introduced through third-party services and integrations. Offline support was done through LocalStorage on a per-application basis. These have become common enough in applications nowadays that rethinking the core AngularJS communication and persistence story was necessary. To this extent, the following are planned:
Phase 1 of AngularJS 2.0 would come with support for Http communication (using ngHttp), Local Storage, Session Storage, and IndexedDB access (through ngStore), and WebSocket API (through ngWebSocket). Each of these would be optional modules that could be included on a per-project basis.
Phase 2 would build on top of this to build offline-first applications, which would be able to check connectivity status, cache data offline, and more.
Phase 3 would finally aim to build an ngData module which would allow developers to build Model classes which represent your data, and act as an abstraction layer on top of Phase 1 and Phase 2 modules. Thus, it would be able to handle offline access, querying network, fetching pages and so on.
Composition is incredibly powerful, allowing us to stitch together reusable pieces of functionality to “compose” a larger application. Composition ushers in a mindset of things being good when they’re modular, smaller and easier to test. Easier to reason with. Easier to distribute.
From Addy’s excellent survey of the JS landscape for 2015. As a front end developer that got started with JS hacking the ExtJS components built into ColdFusion 8 and moved on to straight up ExtJS applications I definitely experienced the power of composition.
A living CSS style guide is a page on your site that uses your current CSS styles and acts as a reference for all the currently available visual elements and design patterns. This helps to tightly integrate design into your delivery process by promoting co-ownership of the UI and avoids duplication of styling across your application. Styling changes are visible in the guide immediately and changes propagate across your site from a central location. A sensible way to do this is with a well organized SASS/LESS file structure with semantically named elements that separates structure, aesthetics, and interaction.
I built one of these in 2014 – woot!
16 steps that front-end developers should go through when planning a front-end web application
Cody’s insights are alway’s interesting and this post contains some excellent insights on current front end development and links to some tools in each step of interest as well.