Making a full page background video is slightly trickier than a full page background image. Over on the Media Temple blog, I take a look at how that's done, but then also what the design patterns are once you've done it. You likely need text over top the video, so do you center it? Do you let the page scroll and cover the video? Do you get fancy and fade out the header as you scroll?
This was truly a team effort- a lot of people worked on these projects to get them going, and it's a really valuable contribution to the community. A lot of people want better performance for their framework of choice but can't get buy-in for time and resources to devote to this kind of endeavor. The ability to start with a baseline of high performance and good lighthouse scores is incredibly valuable, allowing developers to enjoy both the productivity and ergonomics of exciting frameworks, without sacrificing speed and user experience.
This article by Mark Dalgleish will go down as one of the most important front-end development articles of 2017.
I was asked to do a little session on this the other day. I'd say I'm underqualified to answer the question, as is any single person. If you really needed hard answers to this question, you'd probably look to aggregate data of survey results from lots of developers.
I am a little qualified though. Aside from running this site which requires me to think about front end development every day and exposes me to lots of conversations about front end development, I am an active developer myself. I work on CodePen, which is quite a hive of front end developers. I also talk about it every week on ShopTalk Show with a wide variety of guests, and I get to travel all around going to conferences largely focused on front end development.
So let me take a stab at it.
If you keep up with the jargon within the web development and design industry it's likely that at some point you will have come across the term "duck" at least once or twice. Apart from it being fun to feed bread to them, ducks in the web industry hold at least two completely different meanings.
We're not going to be looking at CSS in this post but we are going to talk about tricks for taking paid vacations when no one is paying you to take time off. I suspect that there are a number of us in the front-end development community who face similar situations and addressing is one way we can figure it out together and hopefully glean ideas that make our work-life balance much healthier.
Last week's ShopTalk Show was all about HTML Email. It's such a fascinating subject, as technically it is front-end web development, but it almost feels like a bizarro alternate universe.
We have dozens of browsers to worry about, they have hundreds of clients to consider. We worry about whether fancy new APIs are supported, they worry about whether padding is supported. We have grid layout, they have.... grid layout?!
It's tempting to make the joke: "It's coding like it's 1999!", but as we talk about in this episode, that's not really true.
Aside from all that, another thing I thing fascinating are all the tools involved. Lemme think this out.
React provides two standard ways to grab values from
<form></form> elements. The first method is to implement what are called controlled components (see my blog post on the topic) and the second is to use React's
Controlled components are heavy duty. The defining characteristic of a controlled component is the displayed value is bound to component state. To update the value, you execute a function attached to the
onChange event handler on the form element. The
onChange function updates the state property, which in turn updates the form element's value.
(Before we get too far, if you just want to see the code samples for this article: here you go!)
Exactly as I did the other week, Laurie Voss saw a tweet about the complication of front-end development and responded.
From the outside, front end development in 2017 looks pathologically overcomplicated. Is this a fair perception? If so, why is it happening?
— Pinboard (@Pinboard) May 21, 2017
The replies to Maciej's tweet are interesting to read. They fall roughly into two camps:
- Older/not front-end developers: because the web is shit!
- Current front-end developers: because shit is hard!
As is often the case, both camps are correct! The web is a shitshow of wheel reinvention and bad APIs. It's also a blizzard of innovation.
Expectations for what a website should be able to do have evolved enormously. Users expect snappy, desktop-like responsiveness and rich presentation in web apps. They also expect those same web apps to work equally well on mobile devices. And they expect these apps to load basically instantly.
Still here? Cool. Let's do this.
Manton Reece and Brent Simmons have just published their thoughts on JSON Feed which is a new standard for making a feed, like a collection of blog posts. The format itself is similar to RSS and Atom but since it's in JSON it's easier to read and a lot more familiar to developers:
For most developers, JSON is far easier to read and write than XML. Developers may groan at picking up an XML parser, but decoding JSON is often just a single line of code.
Our hope is that, because of the lightness of JSON and simplicity of the JSON Feed format, developers will be more attracted to developing for the open web.
My favorite part about this project? The spec is just so gosh darn easy to read.
I find Media Temple to be a perfect fit for a mostly-front-end person like me. I'm not an idiot, I'm pretty experienced with web work, but I don't really wanna be in charge of setting up and configuring a server. That's a specialized set of knowledge that I think is well suited to the people that own, sell, and support servers. (I think that would be a pretty good career choice, FWIW, kids.) That's what Media Temple does in spades. They own, sell, and support the heck out of servers.
That's true at all levels. They have super affordable WordPress-tuned servers and shared servers that cost less than a dollar a day that can host more sites than you'll ever need (500!). You can scale up from there with virtual servers (that's what I have) and up to dedicated servers and even fully managed AWS stuff, if that's the kind of power you need.
There is no such thing as one-size-fits-all styling. An image gallery with three images might need to be styled differently than an image gallery with twelve. There are some cool tricks that you can use to add some number-based logic to your CSS! Using
:nth-last-child, you can get some surprisingly complex information without ever leaving your stylesheet.
This post will assume that you have a basic understanding of how the
:nth-child pseudo-selector works. If you need a quick refresher, Chris has a great post covering that topic.
I know there are a ton of pure CSS cube tutorials out there. I've done a few myself. But for mid-2017, when CSS Custom Properties are supported in all major desktop browsers, they all feel... outdated and very WET. I thought I should do something to fix this problem, so this article was born. It's going to show you the most efficient path towards building a CSS cube that's possible today, while also explaining what common, but less than ideal cube coding patterns you should steer clear of. So let's get started!