Kong, Traefik, Caddy, Linkerd, Fabio, Vulcand, and Netflix Zuul seem to be the most common in microservice proxy/gateway solutions. Kubernetes Ingress is often a simple Ngnix, which is difficult to separate the popularity from other things.
This is just a picture of this link from March 2, 2019
Originally, I had included some other solution
I've been deceiving you all. I had you believe that Svelte was a UI framework — unlike React and Vue etc, because it shifts work out of the client and into the compiler, but a framework nonetheless.
But that's not exactly accurate. In my defense, I didn't realise it myself until very recently. But with Svelte 3 around the corner, it's time to come clean about what Svelte really is.
Svelte is a language.
Specifically, Svelte is an attempt to answer a question that many people have asked, and a few have answered: what would it look like if we had a language for describing reactive user interfaces?
A few projects that have answered this question:
| <!DOCTYPE html> | |
| <html lang="en"> | |
| <head> | |
| <title>Alpine.js Todo Demo</title> | |
| <link href="https://unpkg.com/tailwindcss@^1.0/dist/tailwind.min.css" rel="stylesheet"> | |
| <script src="https://cdn.jsdelivr.net/gh/alpinejs/alpine@v2.x.x/dist/alpine.js" defer></script> | |
| <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@tailwindcss/ui@latest/dist/tailwind-ui.min.css"> | |
| <meta charset="utf-8"> | |
| </head> |
You'll find the talks here
Approaching frontend as a backend developer, Svelte feels surprisingly pythonic. Let's take a quick look at what's familiar, what's foreign, and how to explore the gap.
| package main | |
| import ( | |
| "fmt" | |
| "sync" | |
| "time" | |
| ) | |
| const concurrency = 3 |
A running example of the code from:
This gist creates a working example from blog post, and a alternate example using simple worker pool.
TLDR: if you want simple and controlled concurrency use a worker pool.
In the beginning there was NPM, and for a time it was good. Packages went forth and multiplied. The New Gods proclaimed the great demon Dependency Management had been slain. But The Old Gods knew better, for they had seen much and knew that the demon can never be killed, only held at bay.
The Old Gods were ignored. In the folly of a young age grew an abundance of packages and with them grew the scourge of dependency. In the depths beneath the earth, in a place beyond memory, the great demon stirred.
The first sign something was wrong was non-deterministic package version mismatches. “This is fine!” The New Gods declared. “A temporary setback, nothing more! We can fix it.” And so they introduced shrinkwrap, a lamp to combat the growing darkness.
But it proved to be too little, too late, and dusk continued to fall. The New Gods suffered their first major defeat at the [Battle of Left-pad](https://www.theregister.co.uk/2016/03/23/npm_left_
| $('#edtProduct').typeahead({ | |
| //http://tatiyants.com/how-to-use-json-objects-with-twitter-bootstrap-typeahead/ | |
| source: function (query, process) { | |
| items = [] | |
| map = {} | |
| //TODO: get data from server | |
Hi. My name is Sadayuki "Sada" Furuhashi. I am the author of the MessagePack serialization format as well as its implementation in C/C++/Ruby.
Recently, MessagePack made it to the front page of Hacker News with this blog entry by Olaf, the creator of the Facebook game ZeroPilot. In the comment thread, there were several criticisms for the blog post as well as MessagePack itself, and I thought this was a good opportunity for me to address the questions and share my thoughts.
To the best of my understanding, roughly speaking, the criticisms fell into the following two categories.
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs