I wish Grafana was this quick
there's this, but it looks stalled:
Show HN: Plotting 3 years of hourly data in 150ms
91–100 of 118 posts
Re: Show HN: Plotting 3 years of hourly data in 150ms
#92This is amazing, and you've done a wonderful job with the quick response time on the visualization!
Re: Show HN: Plotting 3 years of hourly data in 150ms
#93Unfortunately, I have to use Google Analytics and Google Ads at work every day, and these UIs have absolutely terrible performance :( A small part of the problem is drawing the trend charts. So I decided to make uPlot [1] to see what was really possible. [1] https://github.com/leeoniya/uPlot
This is awesome. I wrote some software to pull readings off my weather station and stream them to the browser. The plotting library that I use is pretty awful. Besides being slow, it's constantly hosing up the numbers on the y-axis. I want to give uPlot a shot.
Station: https://carlisleweather.com
Software: https://github.com/chrissnell/gopherwx
Re: Show HN: Plotting 3 years of hourly data in 150ms
#94Earlier quoted context omitted.
No, JS is slow(ish). The GC pressure alone will kill you. This is fast despite being in JS by simply doing as little as possible (while still meeting the requirements on the end result, which is where the genius lies). The fastest code is no code. No code is fast even with pathologically slow languages/runtimes.
It's no slower than Python. Probably faster unless you're staying within a native library like NumPy. But that wasn't my main point: my main point is that people love to rant about "JavaScript apps" while maintaining (willful?) ignorance about what the actual factors are that manifest as the slowness they experience. Sometimes it's poor usage of the DOM. Usually it's ads. It's almost never the unavoidable overhead of…
> people love to rant about "JavaScript apps" while maintaining (willful?) ignorance about what the actual factors are that manifest as the slowness they experience.
Are you sure you got this right?
Just because JS is fast[0] doesn't mean we cannot complain about Javascript apps that should have been plain web pages?
It is clearly possible to create advanced Javascript apps that are enjoyable even to people like me.
For most pages I use as a consumer I don't see much value add because of frontend code: I see the value of autocomplete, drag-and-drop etc but I would much prefer if my CPU stopped chewing after web pages were loaded and rendered.
[0]: yes, I agree - in most cases the Javascript language or engine is not the cause of the performance problems on the web
Re: Show HN: Plotting 3 years of hourly data in 150ms
#95Earlier quoted context omitted.
It's no slower than Python. Probably faster unless you're staying within a native library like NumPy. But that wasn't my main point: my main point is that people love to rant about "JavaScript apps" while maintaining (willful?) ignorance about what the actual factors are that manifest as the slowness they experience. Sometimes it's poor usage of the DOM. Usually it's ads. It's almost never the unavoidable overhead of…
> people love to rant about "JavaScript apps" while maintaining (willful?) ignorance about what the actual factors are that manifest as the slowness they experience. Are you sure you got this right? Just because JS is fast[0] doesn't mean we cannot complain about Javascript apps that should have been plain web pages? It is clearly possible to create advanced Javascript apps that are enjoyable even to people like me.…
> but I would much prefer if my CPU stopped chewing after web pages were loaded and rendered.
this happens when it's programmed with performance as an afterthought, which is sadly how things work when the prerogative is to just ship more features and continually ingest dependencies with the most features, with little vetting.
Re: Show HN: Plotting 3 years of hourly data in 150ms
#96Earlier quoted context omitted.
It's no slower than Python. Probably faster unless you're staying within a native library like NumPy. But that wasn't my main point: my main point is that people love to rant about "JavaScript apps" while maintaining (willful?) ignorance about what the actual factors are that manifest as the slowness they experience. Sometimes it's poor usage of the DOM. Usually it's ads. It's almost never the unavoidable overhead of…
> people love to rant about "JavaScript apps" while maintaining (willful?) ignorance about what the actual factors are that manifest as the slowness they experience. Are you sure you got this right? Just because JS is fast[0] doesn't mean we cannot complain about Javascript apps that should have been plain web pages? It is clearly possible to create advanced Javascript apps that are enjoyable even to people like me.…
Whether or not a given site should be client-side rendered is a valid discussion
Ad bloat is a valid discussion
Lazy development practices in modern sites/apps are a valid discussion
But in my experience, these as well as other less-legitimate issues all tend to get lumped under the banner of "JavaScript stuff == slow", without any nuance.
Re: Show HN: Plotting 3 years of hourly data in 150ms
#97Earlier quoted context omitted.
Here's a Dash app that use Dask & Datashader for fast aggregations on +40M rows: https://dash-gallery.plotly.host/dash-world-cell-towers The source code, which can be used as a Dash + Dask boilerplate, is here: https://github.com/plotly/dash-world-cell-towers Feel free to ask questions at community.plot.ly
It plots cell towers in the middle of my residential neighborhood where i absolutely sure there aren't any
https://community.opencellid.org/t/range-of-a-tower/370/2
>The range field tells you the approximate area within which the cell could be, in metres. This is effectively an estimate of how accurate the location is.
There's one marked in the middle of a corn field near me with a range of 48,000m. ?
Re: Show HN: Plotting 3 years of hourly data in 150ms
#98Let this be a lesson that JavaScript is not slow. The DOM can be slow, and downloading large bundles can be slow, and any code can be made slow if you try hard enough to write it poorly. But JavaScript the language is not slow in 2020. When we talk (or rant) about the performance of JS-based apps - running on the web or in Electron or otherwise - it's really important that the conversation focus on the factors that a…
It's among the fastest scripting languages. Only LuaJIT turned out to be faster (than Node.js) in my benchmarks. Node is on par with Dart most of the time and the latter is statically typed.
Re: Show HN: Plotting 3 years of hourly data in 150ms
#99Earlier quoted context omitted.
It plots cell towers in the middle of my residential neighborhood where i absolutely sure there aren't any
maybe they're Stingrays ;) https://en.m.wikipedia.org/wiki/Stingray_phone_tracker
Maybe.
However cellmapper.net shows few cell towers where they actually exists and this map doesn't show them.
Credibility?
Re: Show HN: Plotting 3 years of hourly data in 150ms
#100That looks amazing, nice job! I was trying to create a seb dashboard with several graphs each with a few hundred data points recently. None of the libraries felt "snappy" on a mobile device in terms of load time or responsivity. I ended up abandoning the proejct because of that, but if only I knew about this library at the time... The only thing I wish µPlot had is support for tooltips rather than numbers in the lege…
there are a couple tooltip demos here: https://leeoniya.github.io/uPlot/demos/tooltips.html https://leeoniya.github.io/uPlot/demos/cursor-tooltip.html
oh, and another one is in here [1] which turns the legend into the tooltip :)
[1] https://leeoniya.github.io/uPlot/demos/candlestick-ohlc.html