Image by Susie Lu, take from the Addy Osmani's post
I believe it’s very important to understand how the software that users are working with actually functions. From a purely technical point of view, for the development team the clients are the browsers, and understanding how they read, interpret, and render our code is essential to provide the best possible experience for the users of the application or website.
| <div id="canvas"></div> | |
| <style> | |
| #canvas { | |
| width: 500px; | |
| height: 300px; | |
| border: 5px solid black; | |
| position: relative; | |
| box-sizing: content-box; | |
| } |
This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.
I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.
But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.
If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.
I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.
I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.
"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr
invoices/123? in a URL like /assignments?showGrades=1.# portion of the URL. This is not available to servers in request.url so its client only. By default it means which part of the page the user should be scrolled to, but developers use it for various things.
This is some sort of answer to recent posts regarding Web Components, where more than a few misconceptions were delivered as fact.
Let's start by defining what we are talking about.
As you can read in the dedicated GitHub page, Web Components is a group of features, where each feature works already by itself, and it doesn't need other features of the group to be already usable, or useful.
| const assert = require('assert'); | |
| //========== Helper functions | |
| /** | |
| * Resolves after `ms` milliseconds | |
| */ | |
| function delay(ms) { | |
| return new Promise((resolve, _reject) => { | |
| setTimeout(resolve, ms); |
Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.
@broros
otherwise why would he hand over a popular package to a stranger?
If it's not fun anymore, you get literally nothing from maintaining a popular package.
One time, I was working as a dishwasher in a restu
| #!/bin/bash | |
| # Invoke like this: | |
| # ./watch.sh my command here | |
| # And it will run 'my command here' once, and then when it detects changes. | |
| # TODO: Don't just search in the last second. Search for updates since the last | |
| # completed build. Otherwise for big directories, midway through your search | |
| # you've already taken 1s and you will miss updates. |
