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.
A superb talk on performance, advertising, and the future of the web. No doubt a transcript will appear in due time on Maciej’s site and when it does, I will enjoy it all over again.
Trust me: you’ll want to watch this.
This seems like a decent endeavour:
A collaborative research project aimed at designing better tools and practices for learning web development.
Harry packs a lot of great tips and tricks into one short video about performance troubleshooting. It’s also a great lesson in unlocking some handy features in Chrome’s developer tools.
A look at detecting, pinpointing, measuring, and fixing rendering performance issues.
Sara enumerates some handy tips aimed squarely at designers exporting SVGs. It focuses on Illustrator in particular but I’m sure a lot of this could equally apply to Sketch.
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.
A great presentation from Stephen. He takes a thoughtful look at our processes and tools.
The system makes the website. Don’t blame the web developer, blame the organisation. A web developer embedded in a large system isn’t the one making the websites.
To make a progressively enhanced website that performs well and loads quickly even on slow connections, you need to first make an organisation that values those qualities over others.
When I look around, I see our community spending a lot of time coming up with new tools and techniques to make our jobs easier. To ship faster. And it’s not that I’m against efficiency, but I think we need to consider the implications of our decisions. And if one of those implications is making our users suffer—or potentially suffer—in order to make our lives easier, I think we need to consider their needs above our own.
Kenneth has isolated Chrome’s dev tools into its own app. This is a big step towards this goal:
Why are DevTools still bundled with the browsers? What if clicking “inspect element” simply started an external DevTools app?
With DevTools separated from one specific browser, a natural next step would be making the DevTools app work with other browsers.
A collection of performance resources: articles, tools, talks, and books.
A very handy collection from Anna: articles, books, talks, podcasts, and examples of front-end style guides. If something’s missing, feel free to add it.
Focus on what you want to learn; not what you think you should learn.
There is a lot of pressure out there: to learn new things, to spend all your time coding, to be the super developer. I now believe that to be impossible and unhealthy. It means you aren’t living a balanced life and it also means that you’re living under constant stress and pressure.
Turns out that Brian LeRoux and I gave the same answer to this question:
I think I just saved you a click.
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.
Today, a basic HTML/CSS site seems almost passé. But why? Is it because our new tools are so significantly better, or because we’ve gone overboard complicating simple things?
He’s right, y’know.
The transcript of Malarkey’s recent talk. Good thoughtful stuff.
Well, this is pretty nifty: Dan Gilmour is at Indie Web Camp in San Francisco and he’s already got some code up and running on his site.
Y’know, I’m not missing South by Southwest in the slightest this year …but I’m really missing Indie Web Camp.
Excellent tips and tools from Google’s Paul Lewis on performance testing.
Craig recently had a piece published in the New Yorker called Goodbye, Cameras. It’s good …but this follow-on piece on his own site is truly wonderful.
Read. Absorb. Ponder.
Being close to the network does not mean being on Facebook, thought it can mean that, too. It does not mean pushing low-res images to Instagram, although there’s nothing wrong with that. What the network represents, in my mind, is a sort of ledger of humanity. The great shared mind. An image’s distance to it is the difference between contributing or not contributing to that shared ledger.
John shares his concerns about the increasing complexity involved in developing for the web.
John addresses the price of increasing complexity in front-end development.
Yes, tooling can make our life easier. We type fewer keystrokes, and commit more code. But as software engineers learned a long time ago, most of the life of an applications is not in its initial development. It’s in maintaining it. This is something we on the web have had the luxury of being able to largely ignore up to now. After all, how many of the things you build will last years, decades?
Happy birthday, JS Bin!
Remy has some important news. No, it’s not the competition to recreate animated gifs with canvas; scroll down past that…
Remy will be working on JS Bin full time. To make this possible, JS Bin will have Pro accounts. But don’t worry; all the functionality available today will continue to be available in the future.
But Pro accounts will get a bunch of nifty extra features (and if you’re in education, you get Pro for free).
Sign me up!
I really like Dan’s take on using Photoshop (or Fireworks) as part of today’s web design process. The problem is not with the tool; the problem is with the expectations set by showing comps to clients.
By default, presenting a full comp says to your client, “This is how everyone will see your site.” In our multi-device world, we’re quickly moving towards, “This is how some people will see your site,” but we’re not doing a great job of communicating that.
It might seem like an obvious point, but what Tim is talking about here happens over and over again: a technique is dismissed based on bad implementation.
This post is ten years old, but I think it might still be the best attempt to demarcate a difference between web “sites” and web “apps”: think of them as stories and tools.
It’s also remarkably prescient about the need for an effort exactly like HTML5:
A widely-distributed, standards-compliant, browser and platform-independent library of functions that would perform the basic user interface functions for a web-based tool, relying on the server side only for the logic and data sourcing.
This is a very in-depth look at how to become a power user of the Web Inspector in Webkit browsers. I’m sitting down with a nice cup of tea to go through all of this.
This seems like an eminently sensible thing to do when building responsive sites: ditch mock-ups entirely. The reasons and the workflow outlined here make a lot of sense.
How designing in the browser works for rapid iteration.
Mark talks about the tools web designers use and the tools web designers want. The upshot: use whatever you’re most comfortable with.
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.
An excellent design technique from Samantha that allows you to nail down a visual vocabulary without using something as wishy-washy as a mood board or as rigid as a fully-blown comp. Brilliant!
The style tile is not a literal translation of what the website is going to be, but a starting point for the designer and the client to have a conversation and establish a common visual language.
A nice collection of design tools and methodologies.
Kevin Kelly on mankind's love/hate relationship with technology.
A detailed comparison of jQuery and MooTools.
Vint Cerf announces M-Lab: an excellent resource which will allow people to find out if and how their internet access is being throttled. Viva l'internet!
Crows is smart. And yes, I am using the "Bookmark this..." link at the end of the article.