My colleague Ruben released a new Spatie package to generate type declarations in TypeScript from a Laravel application.

Read more

Last week, the W3C decided they were not going to use WordPress for their next website.

The decision making process behind this is happening in the open, on w3c.studio24.net. Accessibility was the driving force for the final choice between three contending CMS’s (WordPress, Craft, and Statamic), but they did a lot of research before.

Read more

“Why Do We Interface?” is a micro-book about interfaces over the ages: from cave paintings to Google Glass to your latest note-taking app. It’s important to understand why we build interfaces in order to get better at building them.

The purpose of any interface, regardless of the technology, is to retrieve, decode, modify, and/or distribute information. […]

The core purpose of graphics in a GUI is not to be pretty The purpose is to be informative.

Some questions to ask yourself when you’re designing an interface:

1. How does the interface help us retrieve information?
2. Is it easy to decode the information that was retrieved?
3. Does the interface allow for easy and clear modification of information?
4. Does the interface assist in, and clearly declare when it is going to distribute information?
5. How will this interface redefine what it means to be human?

Number five is a bit too bold for my taste, but the first four are valuable guidelines.

Read the book on whydoweinterface.com.

My colleague Brent tells the story of how he got “stuck” at his old job.

I decided to leave because I got stuck, there wasn’t any room to grow anymore. The perspective of being a developer who’s 5 years behind of modern day practices made me miserable.

Even though I’d been advocating within the company to make significant changes, both on a technical and management level; it didn’t seem achievable. We were still struggling to deliver the quality we promised our clients, we were using out of date technologies, I went home almost every day feeling down and depressed.

I believe “we were still struggling to deliver the quality we promised our clients” is what really wears you down. Using out of date technologies might have held the team back in this situation, but isn’t necessarily the root cause.

I don’t regret having worked for that company: I did learn valuable lessons there. It’s ok to be at a place where there’s little or no room for growth, as long as it’s not too long. Watch out, and critically assess your situation from time to time; you might get stuck without even knowing it.

It’s important to evaluate from time to time. Not just your job, but all of your work. Ask yourself how the project you’re working on is going every now and then. What went wrong in the last few months? What are you happy with? Keeping this in check will keep you from getting stuck.

Read the full post on stitcher.io.

Jeremy Wagner measured some performance differences between React and vanilla JavaScript. While I’m not surprised that running your code on bare metal code is faster than a framework, it’s interesting to see some exact numbers.

React and ReactDOM total about 120 KiB of minified JavaScript, which definitely contributes to slow startup time. When client-side rendering in React is relied upon entirely, it churns. Even if you render components on the server and hydrate them on the client, it still churns because component hydration is computationally expensive.

If it sounds like I have a grudge against React, then I must confess that I really like its componentization model. It makes organizing code easier. I think JSX is great. Server rendering is also cool—even if that’s just how we say “send HTML over the network” these days.

Even with server-side rendering, React and other virtual DOM frameworks add loading time because they need to load more code and hydrate the page before it’s interactive.

A vanilla addEventListener callback performs about 40 times faster (!) than an event handled in a React component. React’s overhead worth when you have a lot of complex state, not “simple state” like menu toggles.

Read the full article on CSS-Tricks.

If you’ve dealt with dates in the browser, chances are you’ve used Moment.js. Moment has been the date library for JavaScript in the past years. In a humble prelude of the documentation, the Moment maintainers talk about the (near) deprecated status of the project.

Read more

If GitHub is your daily driver or you’ve contributed to open source at some point, you’ve probably seen the comparison screen before.

“Compare and review just about anything”

They’re not lying. You can compare a lot in there, but most of it isn’t available in the UI. Here are a few tricks you probably didn’t know about.

Read more

Rsync is a command line tool to copy files between different hosts.

Read more

Ever since Things 3 came along, it’s been my todo app of choice. Every now and then I check out the competition, but I always swing back.

Inspired by Stefan Zweifel’s post, here’s how I use Things on a daily basis.

Read more

I’ve been looking for a way to add captions to markdown images without falling back to raw HTML. It turns out Hugo supports this with render hooks.

Read more

When you need to set up a service in a Laravel app, service providers are generally the place to be. But, there’s one problem with service providers: they’re global. This usually doesn’t matter, but in multi-section apps this can be problematic.

Read more

Zipping is easy. Remembering zip’s arguments is hard.

Read more

As developers, we often talk about the importance of learning. Learning is so important to us, that it’s worth persuing ways to improve the way we learn.

One way to become a better learner is to master the reverse: unlearning. Not the ability to completely forget, but the ability to set something aside for a brief moment.

When we learn a new language, framework, or tool, it’s hard not to dismiss new ideas based on our existing opinions. It’s the mental baggage we carry along all day.

What we’ve established as antipatterns in tool X’s, might be shiny tool Y’s bread & butter. That doesn’t mean we should dismiss tool Y. Ideas on their own are rarely good or bad, they need to be evaluated in a certain context.

Read more

My colleague Brent wrote a food-for-thought post about two different kinds of programmers: builders & architects.

The first ones, the builders, are the programmers who get things done. […] On the other hand there are architects. They are concerned about sturdy and structurally sound code. […]

These two types of programmers seem like opposites. They themselves look at the other group and often think exactly that. They have a different way of handling the same problems. The other group’s solutions are so different, they can’t possibly be right, or so it seems.

Builders often find architects too rigid and conservative. They follow the rules for the sake of following them, without any practical benefit. Architects in turn, think of builders as careless, too focused on results, instead of thinking about long-term maintainability.

Different programmers aside, “build vs. architect” is the eternal internal conflict when I want to make decisions. Striking a balance between “getting things done” and “getting things right” is tough.

Read the entire, beautifully illustrated post on stitcher.io.

By Fred Hebert:

• if you make the build tool simple, it won’t handle all the weird edge cases that exist out there
• if you want to handle the weird edge cases, you need to deviate from whatever norm you wanted to establish
• if you want ease of use for common defaults, the rules for common defaults must be shared between the tool and the users, who shape their systems to fit the tool’s expectations
• if you allow configuration or scripting, you give the users a way to specify the rules that must be shared, so the tool fits their systems
• if you want to keep the tool simple, you have to force your users to only play within the parameters that fit this simplicity
• if your users’ use cases don’t map well to your simplicity, they will build shims around your tool to attain their objectives

The endless loop of software development. Complexity is why what starts out as “a lightweight alternative to X” often ends up as bloated as X. Greenfield projects allow you to not care about the edge cases for a while, but complexity always catches up.

Read the full article on ferd.ca.