Some very smart ideas in here for resetting default browser styles, like only resetting lists that have classes applied to them:
ul[class],
ol[class] {
padding: 0;
}
I select only lists that do have a
classattribute because if a plain ol’<ul>or<ol>gets used, I want it to look like a list. A lot of resets, including my previous ones, aggressively remove that.
When you ever had to fix just a few lines of CSS and it took two hours to get an ancient version of Gulp up and running, you know what I’m talking about.
I feel seen.
When everything works, it feels like magic. When something breaks, it’s hell.
I concur with Bastian’s advice:
I have a simple rule of thumb when it comes to programming:
less code === less potential issues
And this observation rings very true:
This dependency hell is also the reason why old projects are almost like sealed capsules. You can hardly let a project lie around for more than a year, because afterwards it’s probably broken.
“Ah, this is good news!”, I thought, reading this update about how service worker scripts won’t be cached.
And that was the moment when I realised what an utter nerd I had become.
This is a really good use-case for cancelling fetch requests: making API calls while autocompleting in search.
I’m not sure why but I genuinely love this Windows 95 style interface for Instagram coded up by Gabrielle Wee.
Browsers have had consistent scrolling behavior for years, even across vendors and platforms. There’s an established set of physics, and if you muck with the physics, you can assume you’re making some people sick.
Guidelines to consider before adding swooshy parallax effects:
- Respect the Physics
- Remember that We Call Them “Readers”
- Ask for Consent
Given all the work that goes into a powerful piece of journalism—research, interviews, writing, fact-checking, editing, design, coding, testing—is it really in our best interests to end up with a finished product that some people literally can’t bear to scroll through?
Philosophically, I’m completely against Google’s AMP project and AMP for Email, too. I will always side with the open web and the standards that power it, and AMP is actively working against both. I’m all-in on a faster web for everyone, but I just can’t get behind Google’s self-serving method for providing that faster web.
"Basically, both Google and Facebook are desperate to find a baseball cap that they can put on backwards. Angular is Google's baseball cap. React is Facebook's."
"I can assure you that you are infinitely better off writing code than metadata, be it as a template or a complex query language like GraphQL."
Lately I've been doing a lot of development in Ruby, specifically with Sinatra and Sequel, and I've been liking that development stack a lot. So much so, that when I switch back to PHP for a project, I wish my PHP stack was more like my Ruby stack.
I managed to put together a few PHP projects that result in a very similar framework, described below.
Slim Framework is a PHP micro-framework, very similar to Sinatra. I settled on this one because of its similarities to Sinatra.
<?php
$app = new \Slim\Slim();
$app->get('/hello/:name', function($name) {
echo "Hello, $name";
});
$app->run();
?>
PHP Savant is a simple templating engine for PHP. After evaluating several "minimal" templating engines, I liked PHP Savant the best because of its simplicity.
It was one of the few that actually lets you write PHP in the views. Most try to create an abstraction where you have to learn a new syntax for outputting variables and writing "for" loops.
Here is an example controller and corresponding view code:
<?php
// Load the Savant3 class file and create an instance.
require_once 'Savant3.php';
$tpl = new Savant3();
$tpl->title = $name;
$tpl->display('books.tpl.php');
?>
<html>
<head>
<title><?= $this->title ?></title>
</head>
<body>
...
The great thing is that since the views are actually PHP, you can write whatever PHP code you want in them. You can do things like $date->format() or simple foreach loops without having to learn another syntax. The downside is the project hasn't been updated since 2011, although I haven't run in to any major issues with it yet. If you know of a similar templating engine I'd be happy to learn about it.
This is worth repeating: I am not interested in a templating framework that invents its own syntax. PHP, Ruby and Perl can all be used as templating frameworks, there is no reason to re-invent this. I do not want to use Smarty, Haml, Liquid, etc. These are all abstractions. I just want to write HTML with some variables stuck in it. PHP Savant and Ruby's ERB are the only ones I've found that do this.
Idiorm is the simplest PHP ORM I could find. It is very similar to Sequel for Ruby. It provides a simple wrapper around building queries.
<?php
ORM::configure('mysql:host=localhost;dbname=test');
// Simple Queries
$numUsers = ORM::for_table('users')->count();
$users = ORM::for_table('users')->find_many();
foreach($users as $user) {
echo $user->name;
}
// Inserting a Record
$user = ORM::for_table('users')->create();
$user->username = 'bob'; // setting properties
$user->set('age', 25); // the set() method
$user->set_expr('created_at', 'NOW()'); // setting values as expressions
$user->set(array( // setting bulk properties
'first_name' => 'Bob',
'last_name' => 'Smith'
));
$user->save();
?>
This ORM does not provide concrete classes for your database tables. If you're looking for something more like Ruby's ActiveRecord or DataMapper, then you can also try Paris which is built on top of Idiorm.
Put together, this stack is very similar to a common stack in Ruby. The table below shows the comparable Ruby and PHP components.
| Component | PHP | Ruby |
|---|---|---|
| Routing | Slim | Sinatra |
| Templating | Savant | Erb |
| Database | Idiorm | Sequel |
| Projects I've written with this stack | IndieNews |
IndieAuth Pingback Flickr Archiver |
It's worth noting that this stack will work with any front-end environment. You can use any CSS or Javascript framework with this, this environment doesn't care.