Filestack is a web service that completely handles file uploads for your app.
Let's imagine a little web app together. The web app allows people to write reviews for anything they want. The give the review a name, type up their review, upload a photo, and publish it. Saving a name and text to a database is fairly easy, so the trickiest part about this little app is handling those photo uploads. Here's just a few considerations:
- You'll need to design a UI. What does the area look like that encourage folks to pick a photo and upload it? What happens when they are ready to upload that photo and interact? You'll probably want to design that experience.
- You'll likely want to support drag and drop, how is that going to work?
- You'll probably want to show upload progress. That's just good UX.
- A lot of people keep their files in Dropbox or other cloud services these days, can you upload from there?
- What about multiple files? Might make sense to upload three or four images for a review!
- Are you going to restrict sizes? The app should probably just handle that automatically, right?
That's certainly not a comprehensive list, but I think you can see how every bit of that is a bunch of design and development work. Well, hey, that's the job, right? It is, but the job is even more so about being smart with your time and money to make your app a success. Being smart here, in my opinion, is seriously looking at Filestack to give you a fantastic uploading experience, while you spend your time on your product vision, not already-solved problems.
In which I argue that the only browser usage statistics that make sense use for decision making are the ones gathered from the website being worked on itself.
The reason you can’t use global statistics as a stand-in for your own is because they could be wildly wrong ... Sites like StatCounter that track the worldwide browser market are fascinating, but I’d argue largely exist as dinner party talk.
We've all been there. Landed on a website only to be slapped with a modal that looked something like the one below:
For me that triggers a knee-jerk reaction: curse for giving them a pageview, close the tab, and never return. But there's also that off case when we might actually try to get to the info behind that modal. (more…)
A bit of a wordy title, huh? What is server side rendering? What does it have to do with routing and page transitions? What the heck is Nuxt.js? Funnily enough, even though it sounds complex, working with Nuxt.js and exploring the benefits of isn't too difficult. Let's get started!
Stuck making "a few easy changes" to the website for someone? Component IO makes it quick and simple for you or your team to make edits (even for non-technical users).
Join hundreds of projects already using Component IO, with a free tier and plans from $7.95/mo. It's built to make web development easier for everyone.
We get a decent amount of comments on blog posts right here on CSS-Tricks (thanks!), but I'd also say the hay day for that is over. These days, if someone writes some sort of reaction to a blog post, it could be on their own blog, or more likely, on some social media site. It makes sense. That's their home base and it's more useful to them to keep their words there.
It's a shame, though. This fragmented conversation is slightly more useful for each individual person, it's less useful as a whole. There is no canonical conversation thread. That's what Webmentions are all about, an official spec! In a sense, they allow the conversation to be dispursed but brought all together in a canonical conversation thread on the main post.
Webmentions don't need to be an alternative to comments, although when you pop over to real Drew McLellan's post you'll see he's using them that way. They can be in addition to "regular" comments. Surely the idea of turning off regular comments is appealing from a community perspective (less asshats likely when you need to link to your published words) and a technical debt perspective.
Let's take a look at Hoodie, the "Back-End as a Service" (BaaS) built specifically for front-end developers. I want to explain why I feel like it is a well-designed tool and deserves more exposure among the spectrum of competitors than it gets today. I've put together a demo that demonstrates some of the key features of the service, but I feel the need to first set the scene for its use case. Feel free to jump over to the demo repo if you want to get the code. Otherwise, join me for a brief overview.
The following is a guest post by Rob Levin and Chris Rumble. Rob and Chris both work on the product design team at Mavenlink. Rob is also creator and host of the SVG Immersion Podcast and wrote the original 5 Gotchas article back in '14. Chris, is a UI and Motion Designer/Developer based out of San Francisco. In this article, they go over some additional issues they encountered after incorporating inline SVGs in to Mavenlink's flagship application more then 2 years ago. The article illustrations were done by Rob and—in the spirit of our topic—are 100% vector SVGs!
HTTP/2 has been one of my areas of interest. In fact, I've written a few articles about it just in the last year. In one of those articles I made this unchecked assertion:
If the user is on HTTP/2: You'll serve more and smaller assets. You’ll avoid stuff like image sprites, inlined CSS, and scripts, and concatenated style sheets and scripts.
I wasn't the only one to say this, though, in all fairness to Rachel, she qualifies her assertion with caveats in her article. To be fair, it's not bad advice in theory. HTTP/2's multiplexing ability gives us leeway to avoid bundling without suffering the ill effects of head-of-line blocking (something we're painfully familiar with in HTTP/1 environments). Unraveling some of these HTTP/1-specific optimizations can make development easier, too. In a time when web development seems more complicated than ever, who wouldn't appreciate a little more simplicity?
Hidde de Vries gathers some of the early thinking about CSS:
There is quite a bit of information on the web about how CSS was designed. Keeping it simple was a core principle. It continued to be — from the early days and the first implementations in the late nineties until current developments now.
The four main design principles listed are fascinating:
- Authors can specify as much or little as they want
- It is not a programming language by design
- They are agnostic as to which medium they are used for
- It is stream-based
So... did it?
I think lots has changed since the early nineties, but not really things that touch on how we apply CSS to structured markup.
Let's do this.
A community-driven list of stats and news related to Progressive Web Apps
Twitter Lite saw a 65% increase in pages per session, 75% in Tweets, and a 20% decrease in bounce rate. Twitter Lite loads in under 3 seconds for repeat visits even on slow networks.
It's in the same veins as WPO Stats, which is focused solely on web performance and positive effects of doing a good job.
Media Temple has always been huge supporters of the web design and development communities. They got some deals cookin' right now to celebrate the 20th anniversary of CSS itself. Funny to think this site is just about exactly half as old as its namesake. Over on their blog, Alex Rojas rounded up some highlights of those first 20 years, and I did similarly.
I've used Media Temple for hosting for this site, and dozens and dozens of others, throughout my years in web development.