Swoole is an high-performance network framework using an event-driven, asynchronous, non-blocking I/O model which makes it scalable and efficient. It is written in C language without 3rd party libraries as PHP extension.
It enables PHP developers to write high-performance, scalable, concurrent TCP, UDP, Unix Socket, HTTP, WebSocket services in PHP programming language without too much knowledge about non-blocking I/O programming and low-level Linux kernel.
Compared with other async programming frameworks or softwares such as Nginx, Tornado, Node.js, Swoole has the built-in async, multiple threads I/O modules. Developers can use sync or async API to write the applications.
Will be checking this one out, as an alternative to ReactPHP, since this one comes as a PECL extension. Speed should be heavily better. A quick search around tells me it performs quite well indeed.
🤓 Back in 2006 (!) I created a small site/tool named “The Box Office” to fake that. It took the line-height and floated a truckload of boxes to one side to fake the effect. It’s been long discontinued by now.
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 😉
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 🙂
I especially like the part where they take a look into an JS engine’s Object Model:
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:
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.