mouthporn.net
#web dev – @dragoni on Tumblr
Avatar

DragonI

@dragoni

"Truth is not what you want it to be; it is what it is, and you must bend to its power or live a lie", Miyamoto Musashi
Avatar

Test your obesity level with  Pingdom’s Website Speed Test

There are two points of note here.
  1. The top ten sites are significantly lighter than the rest (worth noting if you want to be a top website).
  2. While the web in general is steadily getting heavier, the top sites have turned the corner.
Readers will point out that the some of the top sites are search engines and thus they have an easier job in keeping things light but even so the second point still stands: they are getting lighter, not heavier. Note also that the top ten websites list includes some relatively rich sites such as Amazon.
The Doom install image was 35x the size of the Apollo guidance computer.
Thirty-five times! Apollo software got us to the moon. Doom wasted millions of man-hours on a video game.
My point of course is that these comparisons are not actually that illuminating.
Are web pages much heavier than they need to be? Yes. This presentation very capably talks about that problem:
http://idlewords.com/talks/website_obesity.htm
Does comparing web pages to Doom help understand or improve the situation? No, not any more than comparing Doom to Apollo memory size helps us understand the difference between a video game and a history-altering exploration.
Avatar

Hear hear, thank you jQuery! Thanks to John Resig and the hundreds of contributors for making web dev suck less and FUN!  I still ♥ jQuery.

For some context, in the mid 90′s, JavaScript was a joke and CSS was but a glint. The table tag and style attribute was the foundation for all page layouts. If you’re responsible for creating emails you know the pain of the generation of developers before you.

As with internet time, every couple of years new libraries / frameworks solve a problem and becomes the new black. In turn, each will fade in the next cycle. Let’s look at Angular which was released in 2009. Fast forward 5 years: Angular sucks, Angular will fail. The total rewrite of Angular confirms it sucks. React was released in 2013 and is now all the rage. What’s on the horizon is 2 years that will supersede React?

Code is fleeting! All software is legacy. The future of JavaScript is still in the future -  Bret Victor - The Future of Programming

Comments from HN:

brakmic 37 minutes ago
Whenever I hear "You don't need jQuery!" I immediately ask myself: is this guy/girl younger than 25?
simonw 10 minutes ago
If you were writing JavaScript 8 years ago, a library like jQuery was pretty much essential to help patch over the enormous numbers of browser bugs and differences between the various IEs, Firefox, Safari and Opera.
My experience is definitely that developers under 25 are much less likely to understand the historic context that jQuery came from, and hence have less respect for what it achieved (and continues to achieve).

Now back to Mike’s post!

jQuery I love you. We’ve been together for 10 years and that’s more than 50 years in JavaScript framework lifetimes. I might see you now less often than I did once, but I need you now no less than when we first met. 
...
We don’t do $(document).ready() very much these days, but I still remember the good times we had. I also remember the pain I had trying to do this without you!
You were always there for me when things were tough. You made things consistent, how they should be, often without me even realising you were doing it. The web was a scary place and you brought order to it. You gave me confidence.
You were there for me too when I had no clue what I was doing. You helped me achieve things I would have never achieved on my own. In some ways, you made it too easy for me and I did some things I should have never done; I’m sorry, that was my fault not yours.
Shallow though it might be, I like the way you look. I can recognise your form anywhere. I love your neat and tidy closures and your chainable methods that keep me wanting more. I look upon you with comfort and familiarity. You always make me smile.
You are selfless. So selfless in fact, that you made me less reliant on you. You taught me how to think. And not just me, but the world around us has been shaped by your influence. Everytime I hear someone say “Native JavaScript” I smile and I think of you. You are so brilliant they needed a term to describe your absence. You have been my fearless leader and guiding light. That’s why I love you jQuery.
I wish those that didn’t know you as well as I do, would treat you with more respect. Younger suitors like Angular and React will come and go; some will make their mark and one day they might even be worthy of comparison. But you will always be my first love; my one true love.
It hurts me when I hear them say things like “you don’t need jQuery”. They don’t remember how dark it was before your light. We needed you then and we still need you now. I like the way you do things and although the years have passed, for certain tasks, you still do what you do better than anyone else could. I trust you. I know you and you know me. There will always be other ways we could do things, but I know I can rely on you and you’re always there when I need you to be.
So thank you jQuery! It’s been a wonderful 10 years. I hope we have another 10, but if we don’t it will always be with dignity and respect that I remember you and never less, because you do the perfect job of making yourself redundant. It is befitting that you do this so gracefully. If the time does come to say goodbye it will be because you have given us all that you can. To not be needed does not mean you will not forever be important to the me and the web.
Thank you jQuery.
Avatar

!

One of the great things about jQuery was that it had a simple, powerful idea. It’s entire mindset was “find these items in the DOM, and attach these events to them”
...
While the simplicity of the ecosystem was fantastic, the community quickly ran into the age old problem of curation. There was just so much duplication and cruft to sift through. It also fakes you out to think that you are building out a lot more than you are. You could add functions that understand The One True Pattern, but there wasn’t a component system that you could build on (unless you picked one of several).
The best part of this era though was how the benefits were embraced by the platform. John Resig didn’t try to build The jQuery Platform, even though plenty of VC’s pushed him to. Instead he helped browsers and we now have items such as querySelector*, dataset, and classList. Once you bake these type of things in, your library becomes a place to hold your opinions, and make the cross browser stuff work (polyfill, prollyfil, and ugly hacks to boot).
Avatar

so tru

Keynote: CSS Still Sucks 2015 & POCss 

POCss: Page Override Components CSS
Why POC?
It's technology-agnostic
One css framework can be played with whatever technology stacks You can combined Scss, PostCSS and whatever you want
Solving problems, and easy
Makes reading and teamwork much easier Get all benefit from BEM, SUITCSS and others
Leverage the power of cascading properly
Scoping components but allow reasonable overriding It's pragmatic, flexible and hitting the sweet spot
Avatar
This test will analyze a URL and report if the page has a mobile-friendly design.
Learn more about the mobile-friendly criteria and how it may affect Google's search results by reading our blog post.
Learn more about mobile-friendly pages
If you're interested in learning more about mobile sites, check out our Webmaster's Mobile Guide or the Principles of Site Design on Web Fundamentals.
Avatar

Status

This is a work in progress.
At the time of writing, the examples were written for React 0.12.x. This guide will be updated with examples for React 0.13 ES6 classes soon!
...

Authors Note

This primer makes use of several libraries, but it is by no means a "React the right way". It's just a introduction to how I am building my own React applications. The goal of this primer to help developers get familiar with React and dive right in. Maybe you will come up with approaches that work with better for you and I hope that you share them with the community! Or if you're already well versed, help improve this document so others in the community can benefit. Sharing is caring!
Avatar

The Chrome DevTools team helped Wikipedia find and fix performance issues with their WikiMedia Editor.

Take away, don’t use $.html(str), hide(), toggle(), :visible or :hidden because of costly style recalculations.

Here are the slides

As the complexity of the web apps you build keeps moving, so do the Chrome DevTools. In DevTools State of the Union, Addy will give you the latest update on your favourite companion; exploring new features like paint profiling, animation inspection and updates to the JavaScript editing workflow with V8.

tl;dr spoiler

“If you think its slow, profile it. ... Know where your bottlenecks are”

  • jQuery is not your friend for high-performance visibility toggling
  • Track visibility on your own rather than using :hidden, :visible, .show(), .hide()
  • Avoid $(elem).html(str) for DOM insertion. Use innerHTML or DOM methods.
  • jQuery does a lot of magic around querySelectorAll. Use it on its own if possible.
  • Keep your DOM size low for predictable performance
  • Try to touch the DOM less. Batch changes. Mutations just make things harder.
Avatar

@mdo also created Twitter Bootstrap. Primer is a pure CSS framework - no JavaScript. Currently, primer.css file is only 30.8k uncompressed!

Primer is GitHub’s internal CSS toolkit. It’s been the base coat for GitHub.com for years now, providing styles for our global typography, layout, tooltips, buttons, and more. Starting today, it’s open source.
Primer isn’t another large front-end framework, though. It’s rather limited in functionality and isn’t intended to replace something like Bootstrap. It will always be GitHub’s internal toolkit first, designed to help build GitHubby things. That said, we love to share.
Primer is licensed MIT, so you can basically do whatever you like with the source code. We’ll be a little stringent on merging new features to the project for the foreseeable future though. Longer term, we envision having a suite of Primer projects—one repository for each new component. More on that another time though.
For now, head to GitHub to view the source code and read through the docs at http://primercss.io.
See the roadmap for a rough outline on what’s slated for future versions of Primer.
Avatar
I absolutely loved this New York Times column which lamented the world of apps, where we don’t have the capability to link to content anymore:
Unlike web pages, mobile apps do not have links. They do not have web addresses. They live in worlds by themselves, largely cut off from one another and the broader Internet. And so it is much harder to share the information found on them.
...
My point is that a lot of web developers today are completely ignorant of the protocol that is the basis for their job.  A core understanding of HTTP should be a base requirement for working in this business.  To not do that is to ignore a massive part of digital history (which we’re also very good at).
I’m currently working through HTTP: The Definitive Guide by O’Reilly.  The book was written in 2002, but HTTP hasn’t changed much since then.  It’s fascinating to read all the features built into HTTP that no one uses because they were never adopted or no one bothered to do some research before they re-solved a problem. There’s a lot of stuff in there that solves problems we’ve since programmed our way around.  The designers of the spec were probably smarter than you, it turns out.
Avatar

Every month, Libscore scans the the top million sites on the web to determine which third-party JavaScript libraries are installed on each site.
Libscore aggregates this data to provide open source developers the numbers they need to measure their impact. Before Libscore, front-end developers only had Github star counts as a proxy for their library’s success. But most developers don’t star Github projects all, opting instead to bookmark Github pages or download libraries exclusively through npm or bower. (This is not a knock on Github; they’d be the first to admit that audience measurement is not the intention of starring.)
The end result is that developers contribute to open source in a vacuum; they develop, hoping — but never knowing — whether their library is being used at-large. Libscore’s data substantiates this hope with facts, resulting in a tighter feedback loop between a project’s development and its developer adoption. This feedback loop, in turn, works to motivate a much higher frequency of open source project maintenance, which ultimately leads to a greater lifespans for open source projects.
...
Libscore was created by Julian Shapiro and Thomas DavisJesse Chase built the website. The project is sponsored by Stripe and Digital Ocean.
Visit Libscore’s Github page to get links to library badges, which publicize a library’s site count. (Any number over 25 is something to be very proud of. Remember, only the top million sites are counted.) Consider embedding it into both your project’s Github README and official documentation page to showcase your library’s adoption at-large to potential new users.
Avatar
upload an image to generate favicons, apple touch icons and the correct HTML header to make it work with all devices and browsers

Pretty Sweet! faviconit generated icons and HTML:

<!-- ****** faviconit.com favicons ****** --> <link rel="shortcut icon" href="/favicon.ico"> <link rel="icon" sizes="16x16 32x32 64x64" href="/favicon.ico"> <link rel="icon" type="image/png" sizes="196x196" href="/favicon-196.png"> <link rel="icon" type="image/png" sizes="160x160" href="/favicon-160.png"> <link rel="icon" type="image/png" sizes="96x96" href="/favicon-96.png"> <link rel="icon" type="image/png" sizes="64x64" href="/favicon-64.png"> <link rel="icon" type="image/png" sizes="32x32" href="/favicon-32.png"> <link rel="icon" type="image/png" sizes="16x16" href="/favicon-16.png"> <link rel="apple-touch-icon" sizes="152x152" href="/favicon-152.png"> <link rel="apple-touch-icon" sizes="144x144" href="/favicon-144.png"> <link rel="apple-touch-icon" sizes="120x120" href="/favicon-120.png"> <link rel="apple-touch-icon" sizes="114x114" href="/favicon-114.png"> <link rel="apple-touch-icon" sizes="76x76" href="/favicon-76.png"> <link rel="apple-touch-icon" sizes="72x72" href="/favicon-72.png"> <link rel="apple-touch-icon" href="/favicon-57.png"> <meta name="msapplication-TileColor" content="#FFFFFF"> <meta name="msapplication-TileImage" content="/favicon-144.png"> <meta name="msapplication-config" content="/browserconfig.xml"> <!-- ****** faviconit.com favicons ****** -->

Avatar

Time to checkout FF dev tools. I haven't use it since converting to Canary.

A new set of the Firefox Developer Tools features has just been uplifted to the Aurora channel. These features are available right now in Aurora, and will be in the Firefox 31 release in July. This release brings new tools, editor improvements, console and inspector features:
  • Editable box model
  • Eyedropper
  • Console stack traces
  • Styled console logs
  • Copy as cURL
  • Editor – multiple selection, Sublime Text keys
  • Canvas Debugger
  • Add-on Debugger
Avatar
How fast is fast enough?
I’m asked this question a lot. Page weights and load times vary so much from site to site and industry to industry. While it’s easy to spot the obviously bad examples, it can be much more difficult to find the line between is “fast enough” and what is slow.
My usual answer of “make it as fast as possible” doesn’t seem to make people very happy, so let’s try to get at least a little more concrete.

Paul Irish's comment

My answer to how fast is fast enough? A Speed Index of under 1000.
And for professionals that get there, they should shoot for delivering the critical-path view (above the fold) in the first 14kb of the page. That way you are guaranteed to be serving the initial view of the site within the first RTT.
(These two goals come from a deck on perf tooling I did a bit ago)
And lastly I think most people's expectations for what's OK is currently way too lax. :)
Avatar
Most mobile carriers force all HTTP traffic to go through their proxies that—among other things—recompress images on the fly. This means that visitors of your website or mobile app may be getting images in much lower quality than you’re serving.
It turns out that these proxies are not as bad as I expected, but quality of images they produce is rather low and cannot be relied upon. With few simple tweaks it’s possible to deliver images with even better compression and quality. Here’s what I’ve found:
  • All proxies recompress all JPEG images. Unfortunately, even very low quality JPEGs are recompressed to have even lower quality. If you’re already using JPEGs at minimum acceptable quality (e.g. “compressive images” trick for high-dpi displays) you need to stop proxies from ruining them.
  • PNG images are very rarely recompressed. If you’re not using lossy PNG yet—you really should!
  • Static GIF images are getting noticeably posterized/discolored/dithered. Fortunately, apart from nostalgia, there’s no reason to use GIF for images any more.
  • The standard HTTP header Cache-Control: no-transform which tells proxies not to modify responses was respected by all proxies I’ve encountered. This is amazing! It wins an award in the “Best Supported Obscure Header” category.
...
Proxies cannot modify HTTPS traffic, so this is one way to bypass them. For insecure traffic, you can add an HTTP header.
In nginx:
location ~* \.(png|jpg|jpeg|gif)$ { add_header "Cache-Control" "public, no-transform"; }
Apache:
<IfModule mod_headers.c> <FilesMatch "\.(png|jpg|jpeg|gif)$"> Header append Cache-Control "public, no-transform" </FilesMatch> </IfModule> ...
...
Takeaways
  • Make PNGs 70% smaller by converting them with a lossy PNG encoder. Check outImageAlpha or TinyPNG.
  • Lower quality of JPEGs. “Quality” setting in JPEG is very misleading—it controls how much data is removed, but some images can tolerate much more compression than others. Tune it per image instead of using arbitrary high setting for all of them. TryJPEGMini/Adept and ImageOptim.
  • Serve well-optimized images over HTTPS or with Cache-Control: no-transformheader to prevent further degradation.
  • Never use GIF, TIFF, BMP or other legacy formats.
You are using an unsupported browser and things might not work as intended. Please make sure you're using the latest version of Chrome, Firefox, Safari, or Edge.
mouthporn.net