As an author of the vector tile specification it is really exciting to see how many different things people can do with the format. People are using data in ways that constantly amaze myself and others. There is an ever growing number of tools that have been built around the format and the future seems bright. I really enjoyed your map, great job!
I wish there was more stuff happening outside of the Node ecosystem. It feels like everything around vector tiles is written in Node these days; the only exception I can think of off the top of my head is TileServer-PHP.
And Node can be painful to work with on some platforms and in some circumstances, not to mention that JS is not everyone's favorite PL.
There are a lot of things being written outside of Node currently [1]. However, a large number of the tools are in node, primarily because lots of people at Mapbox are using Node. However, most of these are backed by C++ libraries so the potential is there for lots of porting to different languages, other people simply need to build against them. Some of the non-Mapbox libraries are not as up to date with the specification, but they are getting much better!
I completely agree this is awesome. Would be very interested in a detailed write up of every detail behind this project. In the meantime, you can just ride into the sunset knowing you've provided someone with their daily inspiration.
What is the original source of the Tile Data? I'm totally ignorant on these topics and even after a pretty close look I can't see who provides the actual geographical data. Is this something that can be sourced from OpenStreetMap or something like that?
I thought for a minute it was somehow zooming in on my current
location and got freaked out, but then realized I'm just not that far from c-base at this moment,
heh. :)
This demonstrates how you could make a site that says something like "Our new technology can tell you are here, please invest" and you just need to pick a single location.
Anyone who happened to be looking at your site from there would be impressed :)
On an unrelated note, I can read minds, think of a card... any card.
If it's the Seven of Hearts then send bitcoin to address number [REDACTED] before I tell everyone your first pet's name.
It happens that I'm building a game which has a CLI and map integration. I was going to left the map out of the CLI client but now there's a good chance I'll use your library sometime in the future :)
I don't know if you're interested in making the "telnet" experience better, but something I've seen used elsewhere is a well-known/advertised SSH login. At the very least you can enable compression on SSH connections. Compression level 1 is nearly free in terms of cpu.
For instance, try `ssh joshua@crawl.akrasiac.org`, and the password is again `joshua`.
If you're allowing anybody on the internet to SSH in, you could also use mosh (mosh.org) to make it feel even faster.
Why do people make terminal-based programs like this in NodeJS? I'm not trying to be snarky - it's a legitimate question. This program is relatively resource-intensive, and you're using NodeJS of all things to try to render things in the terminal. It seems like the most counter-intuitive tool for the job.
> It seems like the most counter-intuitive tool for the job.
How so? What exactly do you think is more difficult about this in node than in other languages or frameworks? Is there something you would recommend as a better alternative?
As much as I like developing in C for fun, it's not a good pragmatic choice (unsafe, verbose, you don't need direct memory access to build an application like this one). Nor is bash, unless you think archaic syntax, primitive control flow, and a lack of modern language features are good things. If you'd suggest something like Python, it's basically exactly the same as node in terms of how high level it is, but (anecdotally) the package ecosystem is much richer in node and npm is easier to use than pip.
It's almost like people think because JavaScript started in browsers it should stay there and any other use case is somehow wrong or a hack. But ECMAScript is an open scripting language standard and has absolutely nothing to do with the DOM, or alert()s, or onclicks.
I write a lot of Java and C++ for pragmatic, work-related reasons, but if I need to write a command line application quickly I'll always come back to node. It's just so damn fast to develop with, and nearly everything I need is one npm install away.
Good question indeed, main reason for me was the incredible well toolset in the node.js world around Vector Tile based map data and GIS processing. Check out the list of used libraries in the repo and you might understand ;)
Not as fast as a compiled language, because JavaScript is too dynamic to apply the same kind of aggressive JITing that things like the JVM or CLR can. It is, however, "fast enough"(tm).
You say that, but in some ways it has the potential to be faster. JIT compilers can recompile code at runtime making use of a profiler, optimising specifically to both the host and the use case.
Modern JavaScript VMs like V8 will often optimise functions treating types as static, then "deoptimise" in the rare case their type assumptions are broken.
Benchmarks or GTFO. Tracing JITs are hard to implement, use up a lot of memory, and cannot efficiently implement many kinds of control flow[1]. AFAIK TraceMonkey was the only JavaScript tracing JIT and it was not that great.[2]
> Modern JavaScript VMs like V8 will often optimise functions treating types as static, then "deoptimise" in the rare case their type assumptions are broken.
And that logic that's needed to test invariants is exactly the overhead we're talking about.
I'm wondering if you're confusing nodejs with HTML/CSS web renderers like Electron, which have received a lot of criticisms for being slow, and also use a nodejs runtime internally.
Electron uses nodejs/v8 as a backend, with Blink/HTML/CSS rendering the UI - the latter introduces some of the well documented performance challenges. This appears to use nodejs/v8 as a backend with your terminal (of choice) rendering the UI.
Perhaps I'm completely misreading your question though.
You can smack together something that grabs JSON over HTTP and does something with it really, really fast in Node. Fast to write, that is, not necessarily to execute.
Reading command line arguments and config files is also much faster/easier/saner/just-works than other, otherwise-better-for-the-task languages (to pick on a favorite: Go, at least the last time I looked at it, which was way too long ago)
Did you add a blink command or something similar? On my terminal, the whole screen is constantly showing then hiding then showing again in 1 second intervals. Mac OS X 10.6.8, Terminal 2.1.2.
Very odd - na, that's a bug and not a feature, I'm just throwing color coded Braille characters at you ;) Most likely related to your Terminal version, http://iterm2.com might help.
I'm a bit confused about how this works. Can you just use markup like :zap: in a commit message, and GitHub will automatically replace it with an emoji? Or do you need to use some client-side scripts to handle that?
Cool! Is there a method to which gitmoji you use, or is it just random? I could see it as being kinda useful as a way to describe what kind of changes the commit it making.
It seems to be a classification of sorts. He's using {guy running} for performance optimizations like ae65f95, {paint palette} for visual changes, etc. What a neat idea! It's easy to glance at the commit log and get a sense of what the changes are doing.
EDIT: Whoops, the emojis aren't rendering in HN comments. Changed to textual descriptions...
