mourner

I read the title as "Facebook Outrage Root Cause", got disappointed :)

That's awesome! Works great on my Pi digits calculation demo :) https://observablehq.com/@mourner/calculating-pi-digits

Hey Justin, we miss you very much! Happy to see you chime in here.

> it takes a real commitment from the leadership to fully integrate remote team members

This is so true. I thought this would only be manageable for relatively small companies, and that it was natural for Silicon Valley companies to loose this culture as they grow rapidly, so it's very inspiring to see this kind of commitment from a company as large as Stripe.

Welcome to Ukraine! Lard and Salo [1] are pretty much the main national dishes here. A healthy delicacy that's welcome on any table and is sold on every meat market.

[1] https://en.wikipedia.org/wiki/Salo_(food)

That's not true, at least not in areas where Telegram is prevalent (Eastern Europe). Here, it's quickly becoming the default 1-1 messenger.

It's a fantastic service from an engineering perspective. Fast, lightweight, reliable, simple, with low battery drain and data usage, and open source clients. A real joy to use.

I love the Bullet Journal system [1], writing yearly/monthly/daily goals in an old-fashioned paper notebook. Somehow it makes it much easier to reason about compared to keeping digital to-do lists.

[1] https://bulletjournal.com

No, just slides — I don't have a video of the talk. Perhaps there will be one someday if I'm invited to some international JS conference :)

Note that the hilbert function wasn't written by me, just merely ported from C++ — here's a post about it by the original author: http://threadlocalmutex.com/?p=126

No, it's single-threaded (it's pure JavaScript after all), but you can index data on a worker thread and then transfer the index instantly to the main thread for search queries. I don't think the algorithm needs parallelization — isn't worth the complexity, it's already fast enough.

Good point, thank you! I'll interlink those.

The most critical thing is avoiding unnecessary work — that usually means estimating algorithmic complexity and trying to reduce it where possible (e.g. by sorting + binary search, caching, using basic data structures like a priority queue, etc.). I'm meaning to make a long blog post about my approach to algorithms, but meanwhile you can check out my recent slide deck on the matter:

https://speakerdeck.com/mourner/fast-by-default-everyday-alg...

Awesome — let me know how it goes!

I think kdbush should always be faster for points — it uses more than 2x less memory, because when you encode points as bounding boxes, you basically duplicate them. Indexing and search is faster mostly because you operate on less data.

You're right! In my experience, today JavaScript is so fast on careful code like this that even ports to C++ or Rust aren't much faster, and any gains would likely be offset by JS <-> WebAssembly communication overhead (although this is being rapidly improved).

Here's a good thread with benchmarks that compare Earcut (also one of my libraries) to C++ and AssemblyScript WebAssembly ports: https://github.com/mapbox/mapbox-gl-js/issues/4835 (in short, mostly slower than JS)

Another anecdotal example is that C++ and Rust ports of https://github.com/mapbox/delaunator (my Delaunay triangulation library) are only 10-15% faster.

Basically, yes. I wrote a long article about this [1] which goes into depth on how algorithms like this work — hope it helps!

[1] https://blog.mapbox.com/a-dive-into-spatial-search-algorithm...

Hey, author of the library here — feel free to ask me any questions! Very happy to see this trending on HN.

Hey, any recommendations for a conversation starter in a coworking kitchen?

Great project! I recently wrote a detailed technical post on how to implement a similar visualization with WebGL — check it out: https://blog.mapbox.com/how-i-built-a-wind-map-with-webgl-b6...

Expected to see an article about the development of modern Go the board game theory after the advent of AlphaGo and AI generally. Got disappointed. Happens every time :(

Would love to see this adopted by Hugo. The default templating engine is ugly as hell.

Wow, talk about exaggeration... I live in Kyiv all my life, but travel to San Francisco frequently. And the latter feels MUCH more dangerous (especially around the Tenderloin area where most startup offices are located). Drug addicts, homeless and mentally ill everywhere on the street, it smells piss, it's hard to walk for 10 minutes without someone yelling obscenities at you, gun violence is ridiculously high, etc. With the new bright president in the US, it may get much worse — hate, anger and division spread like plague. You can find negative points like this in almost any place on Earth.

I traveled the world quite a bit, but never felt like relocating to any other city — sure, they are huge issues, but if you surround yourself with good people, it's wonderful to live here.

If the icons don't work when you use Leaflet through NPM, please report a bug at https://github.com/Leaflet/Leaflet/issues. This is certainly not an expected behavior. It might have regressed in recent versions.

Does this effect happen on the Leaflet frontpage example? You could be using an older version Leaflet CSS with a newer version JS.

WebGL is notoriously hard to use and requires tons of code for even simple things like drawing lines and polygons. (Disclaimer: I'm also one of the core developers of Mapbox GL JS)

One of our core devs (Ivan) works on Leaflet WebGL renderer, but I'd like it to remain a plugin, so that Leaflet stays true to its goal — to be as small and simple as possible.

Leaflet supports retina tiles, they're just not used on the frontpage example because default OSM tile service doesn't provide them, and we don't use other providers on that example for the sake of simplicity (to keep it as short as possible).

Leaflet author here. Thanks for the kind words everyone! A few core developers are here too. Ask us anything. :)

Getting fixed in 1.0.1, to be out today.

Of course the performance claims only relate to Leaflet itself, not the server performance — Leaflet is server-agnostic (you can use it with any tile provider). The improvements will be noticeable in dynamic map apps with lots of vector data, markers, tooltips etc. on top of the map.

Disclaimer: I'm the Leaflet author and I also work on Mapbox GL.

It's true that Mapbox currently focuses its efforts on GL, but they are not "moving away from Leaflet" — Leaflet will continue to be supported as one of the first-class clients to be used with Mapbox services (and GL-based styles have a raster tiles fallback). Leaflet is very mature, has a huge community, is suited for most simple mapping needs, is very easy to learn, and doesn't require a lot of development effort from the Mapbox side to support.

Mapbox GL on the other hand represents a vector rendering technology, which is very different. It is much more powerful than conventional raster tile based clients, and enables applications never seen before in the online mapping industry, but it's also many times heavier, more complex, and much harder to learn. Rendering vector data on the client is something Mapbox bets on as the future of mapping, but it's incredibly challenging to build, so it requires a lot of focus.

I'll continue to maintain both libraries — while they have some overlap, there's a place for both.