Bootstrap is a product of Twitter. If you want your team to work like Twitter’s team, then by all means use Bootstrap. Pick up their design language. Their tool chain. Their decisions. Don’t be surprised when it feels off every time you use it. It will.
The same goes for Material Design. Foundation. These are all products built by other teams to work for their process. Their structure.
Finding the right tool is not what I am advocating for. Making it is.
Use a framework if you must but never presume it’s viable over the long-term. Newer and better alternatives will appear before you’re half-way through your project. Never forget frameworks are an option — you don’t have to use one.
Here’s Paul’s write-up of his excellent talk at FF Conf.
Previously I’ve used the term “developer convenience” when describing the benefits of using a framework. Paul uses the term “ergonomics” to describe those benefits. I like that. I worry sometimes that the term “developer convenience” sounds dismissive, which isn’t at all my intention—making our lives as developers less painful is hugely important …but it’s just not as important as improving the lives of the end users (in my opinion …and Paul’s).
As I look at frameworks, I see the ergonomic benefits (and those are important, I agree!), but I can’t help but feel that, for many developers, investing in knowledge of the web platform itself is the best long-term bet. Frameworks come and go, it just seems to be the ebb and flow of the web, and, as I said above, they do contribute ideas and patterns. But if you ever find that the one you use no longer works for you, or has a bug that remains unfixed, being able to understand the platform that underpins it will help enormously.
This was one of favourite talks at this year’s FF Conf. But I will readily admit there’s a hefty dollop of confirmation bias in my enjoyment.
Following on from her great conversation with Jen on The Web Ahead podcast, Rachel outlines a strategy to avoid feeling overwhelmed by the deluge of tools, frameworks, libraries, and techniques inundating front-end developers every day:
Learn your core skills well. Understand HTML and CSS, be able to build a layout without leaning on a framework. Get a solid understanding of how a website actually gets from the server to a browser, an understanding of security and accessibility. These are the basics, the constants. These things change slowly. These things sit underneath all the complexity and the tooling, the CMSs and the noise of thousands of people all trying to make their mark on this industry.
She also makes this important point:
As you are doing this don’t forget to share what you know.
Progressive Enhancement remains the best option for solving web development issues such as wide-ranging browser support, maintenance and future-proofing your application.
Sensible words from Christian.
Web applications don’t follow new rules.
And frameworks will not help:
A lot of them are not really fixing fundamental problems of the web. What they do is add developer convenience. … This would be totally OK, if we were honest about it.
I’ve said it before: if your client-side MVC framework does not support server-side rendering, that is a bug. It cripples performance.
I have doubts about Angular 1.x’s suitability for modern web development. If one is uncharitably inclined, one could describe it as a front-end framework by non-front-enders for non-front-enders.
Angry, but true.
Don’t lock yourself into a comprehensive technology that may just die within the next few months and leave you stranded. With progressive enhancement you’ll never go wrong. Progressive enhancement means your code will always work, because you’ll always focus on providing a minimal experience first, and then adding features, functionality, and behavior on top of the content.
I can relate to every single word that Bastian has written here.
The longer I look at boilerplates, build tools, frameworks and ways to make my life as a developer easier, the more I long for the basics.
John shares his concerns about the increasing complexity involved in developing for the web.
I despair sometimes.
Here’s a ridiculous Heath-Robinsonesque convoluted way of getting the mighty all-powerful Googlebot to read the web thangs you’ve built using the new shiny client-side frameworks like Angular, Ember, Backbone…
Here’s another idea: output your HTML in HTML.
There’s something fundamental and robust about being able to request a URL and get back at least an HTML representation of the resource: human-readable, accessible, fault tolerant.
A new PHP-based content management system. It uses Twig for the templating, which I like.
I find it hard to agree with any part of this. To me, it shows a deep misunderstanding of the web—treating the web as just another platform, without understanding what makes it so special.
I think I may have found my polar opposite.
The hilarious obsession with file size is the start of my frustrations with the web community.
I like these design principles for server-side and client-side frameworks. I would say that they’re common sense but looking at many popular frameworks, this sense isn’t as common as it should be.
Josh writes about the importance of using rules and systems as tools without being bound by them.
This amuses me. I am amused.
This is interesting, not because it’s yet another grid framework (which I never use anyway) but because of the way it’s doing layout: with border-box and inline-block, rather than floats. If you’re only serving up your layout styles to browsers that support media queries (which would discount older versions of IE anyway), this could make a lot of sense.
Mark has put together this rather excellent prototyping tool. It’s basically the V from an MVC system. You can easily move stuff around, change data …all the good stuff you want to do quickly and easily when you’re prototyping in the browser.
Jonathan gives a thorough overview of the various tools and frameworks out there to help build native, hybrid and mobile web apps. He also shares his decision-making process on when to build what.
A framework for banging out ready-made responsive designs.
A set of default styles to get started on a mobile-first responsive design.
I’m usually not a fan of CSS “frameworks” but I like the thinking that’s gone into this fluid, responsive system. I particularly like this advice:
Take it apart, steal the parts that you like, and adapt them to your own way of working.
Paul has created a site for tracking usage of the BBC’s GEL (Global Experience Language) visual design language. Nice’n’responsive it is too.
A framework for creating old-school arcade games in the browser, using HTML5.
Gareth tries to figure out why Django seems to strike a chord with standardistas. It may that the separation of concerns resonates with the methodology of progressive enhancement. Some good comments follow
Here's another CSS framework for grids. It could prove to be very useful for wireframing.
Pulling together a bunch of CSS tricks from a range of sources: reseting, baseline typography and grids (fixed width, unfortunately).
YUI Version 2.2.0 Released: Browser History Manager, DataTable, and Button Components, New Versioning, and More » Yahoo! User Interface Blog
Roll up and get it: hot off the presses; the new version of the Yahoo User Interface library. Happy birthday, YUI.
The Spry framework from Adobe looks like it could be worth further investigation. I certainly like the underlying philosophy: lightweight, standards-based, and declarative.
An interesting looking lightweight framework for PHP.
The creator of PHP offers an antidote to the profusion of frameworks out there.