Tags: javascript

579

sparkline

Monday, May 22nd, 2017

Are we making the web too complicated? | Seldo.Com Blog

Laurie Voss on the trade-off between new powerful web dev tools, and the messiness that abusing those tools can bring:

Is modern web development fearsomely, intimidatingly complicated? Yes, and that’s a problem. Will we make it simpler? Definitely, but probably not as soon as you’d like. Is all this new complexity worthwhile? Absolutely.

I agree that there’s bound to be inappropriate use of technologies, but I don’t agree that we should just accept it:

Are there some people using a huge pile of JavaScript and a monstrous build chain to throw together a single-pager web site with one box that collects an email address? For sure. And that’s silly and unnecessary. But so what? The misuse of technology does not invalidate it.

I think we can raise our standards. Inappropriate use of technology might have been forgivable ten years ago, but if we want web development to be taken seriously as a discipline, I think we should endeavour to use our tools and technologies appropriately.

But we can all agree that the web is a wonderful thing:

Nobody but nobody loves the web more than I do. It’s my baby. And like a child, it’s frustrating to watch it struggle and make mistakes. But it’s amazing to watch it grow up.

Thursday, May 4th, 2017

Going offline. — Ethan Marcotte

Ethan has added a service worker to his site and he’s got a nifty little recipe for showing a list of saved-for-offline articles.

Monday, May 1st, 2017

Offline Web Applications | Udacity

This is a free online video course recorded by Jake a couple of years back. It’s got a really good step-by-step introduction to service workers, delivered in Jake’s typically witty way. Some of the details are a bit out of date, and I must admit that I bailed when it got to IndexedDB, but I highly recommend giving this a go.

There’s also a free course on web accessibility I’m planning to check out.

Springer Nature frontend playbook: house style guide

I like it when organisations share their in-house coding styles. This one from Springer Nature not only has guides for HTML, CSS, and JavaScript, but it also has a good primer on progressive enhancement.

Tuesday, April 25th, 2017

Replacing Disqus with Github Comments · Gazoo.vrv

If you’re using Disqus to power the comments on your blog, you might like to know that it’s pulling on loads of nasty tracking scripts. Bad for privacy and bad for performance.

Tuesday, April 18th, 2017

Offline-first for Your Templated Site (Part Two)

I’m really interested in this idea of service-worker side templating (I know that Glenn is working on something really, really cool in this area too). Can’t wait for part three of this series! (hint, hint, Jeff)

Saturday, April 15th, 2017

Inclusively Hidden | scottohara.me

Comparing different ways to hide content accessibly:

There are three reasons behind hiding content in an interface, and it’s important to identify what those reasons are, as they will correlate with the appropriate technique needed to hide such content.

  1. Temporarily Hidden Content
  2. Purposefully Visually Hidden Content
  3. Purposefully Visual-Only Content

Wednesday, April 12th, 2017

A Todo List

A great step-by-step walkthrough by Heydon of making an accessible to-do list, the “Hello World” of JavaScript frameworks.

There’s a lot of great knowledge in here that can be applied to plenty of other interface elements too.

Thursday, March 30th, 2017

Creating my first HTTP server in node.js | Charlotte Jackson, Front-end developer

Charlotte’s step-by-step account of setting up a Node server is going to be invaluable if and when I get around to dipping my toes in those waters.

Sunday, March 26th, 2017

LA Times and ads | Nelson’s log

A lot has been written about the future of journalism, the importance of businesses like the LA Times being profitable as a way to protect American democracy. I agree with that in theory. But this sort of incompetence and contempt for readers makes me completely uninterested in helping their business.

Like Craig says…

Thursday, March 23rd, 2017

Modern JavaScript for Ancient Web Developers

Speaking as an ancient web developer myself, this account by Gina of her journey into Node.js is really insightful. But I can’t help but get exhausted just contemplating the yak-shaving involved in the tooling set-up:

The sheer number of tools and plugins and packages and dependencies and editor setup and build configurations required to do it “the right way” is enough to stall you before you even get started.

Retrofit Your Website as a Progressive Web App — SitePoint

Turning your existing website into a progressive web “app”—a far more appealing prospect than trying to create an entirely new app-shell architecture:

…they are an enhancement of your existing website which should take no longer than a few hours and have no negative effect on unsupported browsers.

Wednesday, March 22nd, 2017

Improve Your Billing Form’s UX In One Day – Smashing Magazine

A few straightforward steps for improving the usability of credit card forms. The later steps involve JavaScript but the first step uses nothing more than straight-up HTML.

Tuesday, March 21st, 2017

The web share API | Phil Nash

I really need to have a play with this API. I think it could potentially be a useful indie web building block …if the web share target API also gets implemented.

Sunday, March 19th, 2017

Frameworks without the framework: why didn’t we think of this sooner? • Svelte

Interesting ideas around front-end frameworks:

The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that’s not really true. At best, frameworks move the complexity around, away from code that you had to write and into code you didn’t.

Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your concepts. Frameworks are primarily a tool for structuring your thoughts, not your code.

The proposed alternative here is to transpile from the idiom of the framework into vanilla JavaScript as part of the build process, which should result in better performance and interoperability.

Friday, March 10th, 2017

153 ☞ A Crash Course in React

This is a nice understandable explanation of the basics of React.

There’s a real skill in explaining something so clearly that even n00bs like me can understand it.

Thursday, February 16th, 2017

Teaching in Porto, day three

Day two ended with a bit of a cliffhanger as I had the students mark up a document, but not yet style it. In the morning of day three, the styling began.

Rather than just treat “styling” as one big monolithic task, I broke it down into typography, colour, negative space, and so on. We time-boxed each one of those parts of the visual design. So everyone got, say, fifteen minutes to write styles relating to font families and sizes, then another fifteen minutes to write styles for colours and background colours. Bit by bit, the styles were layered on.

When it came to layout, we closed the laptops and returned to paper. Everyone did a quick round of 6-up sketching so that there was plenty of fast iteration on layout ideas. That was followed by some critique and dot-voting of the sketches.

Rather than diving into the CSS for layout—which can get quite complex—I instead walked through the approach for layout; namely putting all your layout styles inside media queries. To explain media queries, I first explained media types and then introduced the query part.

I felt pretty confident that I could skip over the nitty-gritty of media queries and cross-device layout because the next masterclass that will be taught at the New Digital School will be a week of responsive design, taught by Vitaly. I just gave them a taster—Vitaly can dive deeper.

By lunch time, I felt that we had covered CSS pretty well. After lunch it was time for the really challenging part: JavaScript.

The reason why I think JavaScript is challenging is that it’s inherently more complex than HTML or CSS. Those are declarative languages with fairly basic concepts at heart (elements, attributes, selectors, etc.), whereas an imperative language like JavaScript means entering the territory of logic, loops, variables, arrays, objects, and so on. I really didn’t want to get stuck in the weeds with that stuff.

I focused on the combination of JavaScript and the Document Object Model as a way of manipulating the HTML and CSS that’s already inside a browser. A lot of that boils down to this pattern:

When (some event happens), then (take this action).

We brainstormed some examples of this e.g. “When the user submits a form, then show a modal dialogue with an acknowledgement.” I then encouraged them to write a script …but I don’t mean a script in the JavaScript sense; I mean a script in the screenwriting or theatre sense. Line by line, write out each step that you want to accomplish. Once you’ve done that, translate each line of your English (or Portuguese) script into JavaScript.

I did quick demo as a proof of concept (which, much to my surprise, actually worked first time), but I was at pains to point out that they didn’t need to remember the syntax or vocabulary of the script; it was much more important to have a clear understanding of the thinking behind it.

With the remaining time left in the day, we ran through the many browser APIs available to JavaScript, from the relatively simple—like querySelector and Ajax—right up to the latest device APIs. I think I got the message across that, using JavaScript, there’s practically no limit to what you can do on the web these days …but the trick is to use that power responsibly.

At this point, we’ve had three days and we’ve covered three layers of web technologies: HTML, CSS, and JavaScript. Tomorrow we’ll take a step back from the nitty-gritty of the code. It’s going to be all about how to plan and think about building for the web before a single line of code gets written.

Sunday, February 12th, 2017

Accessibility and Performance | MarcySutton.com

When I heard about Universal JavaScript apps (a.k.a. isomorphic JavaScript), despite the “framework hotness”, I saw real value for accessibility and performance together. With this technique, a JavaScript app is rendered as a complete HTML payload from the server using Node.js, which is then upgraded as client resources download and execute. All of a sudden your Angular app could be usable a lot sooner, even without browser JS. Bells started going off in my head: “this could help accessible user experience, too!”

Interneting Is Hard | Web Development Tutorials For Complete Beginners

A nice straightforward introduction to web development for anyone starting from scratch.

Thursday, February 9th, 2017

Fluid Paint

The texture here is shockingly realistic.