A rather geeky/technical weblog by Bram(us) Van Damme, est. 2001
Jeremy Keith, on Separation of Concerns and how that comes into play where one’s dealing with Component based design:
My point is this:
- Separating structure, presentation, and behaviour is a good idea.
- Separating an interface into components is a good idea.
Those two good ideas are not in conflict. They work best when they’re done in combination.
Yes, yes, yes, … YES! A THOUSAND TIMES YES!
💁♂️ You might also have seen this related image float around on the Twitters:
If you’re using React Navigation in your app(s) you might have noticed these two issues the folks over at November Five have written about:
On a few screens – specifically those with lots of components – we started noticing a few things…
Right off the bat, there is a substantial delay between the user pressing a button and the swipe-in animation of a new screen. When a new screen is pushed, React Navigation will initially render it off-screen and animate it into place afterwards. This means that when a complex screen with lots of components that easily takes a few hundred milliseconds to render is pushed, it feels less snappy than a natively written application. It also causes some nasty side effects: for instance, if you tap a button quickly, you can trigger the same route from being pushed multiple times.
Another problem is that business logic can be executed while the swipe-in animation is doing its thing. This can make for a janky animation.
Of course the post also contains fixes for these problems 😉
A lesson in webdev history by Jason Hoffman:
The clearfix, for those unaware, is a CSS hack that solves a persistent bug that occurs when two floated elements are stacked next to each other. When elements are aligned this way, the parent container ends up with a height of 0, and it can easily wreak havoc on a layout. The clearfix was invented to solve all that.
But to understand the clearfix, you have to go back even further, to the 2004 and a particular technique called the Holly hack.
I had some nostalgic flashbacks whilst reading this 🙂
Mathias Bynens and Benedikt Meurer:
As a JavaScript developer, having a deeper understanding of how JavaScript engines work helps you reason about the performance characteristics of your code.
I especially like the part where they take a look into an JS engine’s Object Model:
How do JavaScript engines implement the JavaScript object model, and which tricks do they use to speed up accessing properties on JavaScript objects? As it turns out, all major engines implement this very similarly.
(knowledge of the aforementioned Property Descriptors will come in handy ;))
The contents of the article have also been touched upon in this duo-talk they gave:
Very insightful piece by Uday Hiwarale on ES Decorators (Class Method Decorators, Class Instance Field Decorators, and Class Decorators).
Right now (June 2018), Decorators are in stage 2 and we have Babel plugin to transpile decorators
babel-plugin-transform-decorators-legacy. In stage 2, as syntax of the feature is subjected to change, it’s not recommended to use it in production as of now. In any case, decorators are beautiful and very useful to achieve things quicker.
Before going into Decorators he gives a very insightful explanation about Property Descriptors first:
To understand decorators, we need to first understand what is a property descriptor of JavaScript object property.
A minimal guide to ECMAScript Decorators (and Property Descriptors) →
Gerardo Rodriguez from Cloudfour:
While testing a progressive web app for one of our clients, I bumped into a suspicious error in the browser console:
DOMException: Quota exceeded.After browsing the app a few more times, it became clear the error would occur after a small number of images were added to the cache storage by the service worker. Looking in the Chrome DevTools Application tab, the cache storage was indeed over capacity.
How could this be? There were only ~15 images in the cache storage. Something was off.
The culprit? Opaque Responses.
Interesting piece by Vox on the use of Trajan in movie poster design:
Ryan Yu:
There are many great techniques out there to improve the way we write CSS, and from my experience, I found the following three techniques that make up the BIO acronym work very well together
- BEM
- ITCSS
- OOCSS
A lot of developers/engineers already know those famous techniques but I would like to go through each of them and talk about the way I use those techniques.
I can say that this combination works really well, as it is exactly the work I have done at Small Town Heroes whilst working on their Zender product.
Combining the Powers of SEM and BIO for Improving CSS →
During said project I even outperformed myself when it comes to adding comments in the code 😜
#refactoring #itcss pic.twitter.com/2iSmfpEbqb
— Bramus! (@bramus) September 6, 2016
I first heard of the Dunning-Kruger effect at last year’s Fronteers Conference in a talk by Jessica Rose. In that talk she said that “the unskilled aren’t aware of their lack of own skill, and are unable to assess and value others’ skills”. This is known as the Dunning-Kruger effect.
This nice video goes into more detail:
How good are you with money? What about reading people’s emotions? How healthy are you, compared to other people you know? Knowing how our skills stack up against others is useful in many ways. But psychological research suggests that we’re not very good at evaluating ourselves accurately. In fact, we frequently overestimate our own abilities. David Dunning describes the Dunning-Kruger effect.
Interesting blog post by TJ Vantoll, who works on NativeScript:
In this article we’ll walk through Airbnb’s complaints in detail, and talk about how some of those same problems could’ve been handled in NativeScript. We’ll start with things that NativeScript does well (this is the NativeScript blog after all), and then move on to things NativeScript does, well, less well.
Takes a good look at things like the bridge, the use of TypeScript, the benefits of NativeScript’s single threaded model.
Would Airbnb Have Fared Better With NativeScript Instead of React Native? →
Be sure to also read “State of React Native 2018”. In that post, Facebook announced some changes it’s going to make regarding the bridge/threading:
To make React Native more lightweight and fit better into existing native apps, this rearchitecture has three major internal changes. First, we are changing the threading model. Instead of each UI update needing to perform work on three different threads, it will be possible to call synchronously into JavaScript on any thread for high-priority updates while still keeping low-priority work off the main thread to maintain responsiveness. Second, we are incorporating async rendering capabilities into React Native to allow multiple rendering priorities and to simplify asynchronous data handling. Finally, we are simplifying our bridge to make it faster and more lightweight; direct calls between native and JavaScript are more efficient and will make it easier to build debugging tools like cross-language stack traces.
Really looking forward to these upcoming changes 🙂