[HN Gopher] Perspective: Open Source WebAssembly-Powered BI
___________________________________________________________________
Perspective: Open Source WebAssembly-Powered BI
Author : texodus
Score : 260 points
Date : 2023-04-05 15:30 UTC (7 hours ago)
(HTM) web link (perspective.finos.org)
(TXT) w3m dump (perspective.finos.org)
| xal wrote:
| Awesome project.
|
| If there is ever a project that needed an electron app it's this
| one. I'd love to have a Perspective.app that efficiently loads
| local data style files.
| ivanmontillam wrote:
| Electron is going to kill the good performance gains of
| Perspective. Even if you have a fully beefed-up workstation,
| Electron is going to trigger the CPU fans.
|
| Electron is discouraged nowadays in favor of lightweight
| solutions like Sciter[0], Tauri[1] or even WebView2[2].
|
| --
|
| [0]: https://sciter.com/
|
| [1]: https://tauri.app/
|
| [2]: https://learn.microsoft.com/en-us/microsoft-edge/webview2/
| eis wrote:
| I don't see why rendering this in Electron (which is
| essentially just a bundled Chromium browser) would perform
| differently than in a standalone browser. Neither do I see
| how projects like Tauri or WebView2 which just embed the
| system webview would give better rendering performance.
| Microsofts webview is even using the same rendering engine as
| Electron - Blink. What you'd get is significantly smaller
| binary size but most people don't care much about that.
| ivanmontillam wrote:
| > _I don 't see why rendering this in Electron (which is
| essentially just a bundled Chromium browser) would perform
| differently than in a standalone browser._
|
| WebView2 has further optimizations as claimed by Microsoft
| in their recent blog post about Microsoft Teams[0]: _" The
| key benefits observed from the transition from Electron to
| WebView2 include reduced memory usage and a lowered disk
| footprint as resources are shared with Edge. Additionally,
| we have been able to take greater advantage of the native
| capabilities provided by WebView2 and ensure support for
| more up-to-date versions of Chromium (latest performance
| and security updates)."_
|
| So, I'd assume WebView2 is better than Electron.
|
| > _What you 'd get is significantly smaller binary size but
| most people don't care much about that._
|
| In the case of Sciter (quoted in my parent comment), Sciter
| is a bit different: The frontend is HTML, CSS and JS, but
| the app's local backend is whatever you want it to be: C#,
| C++, Python, Assembly, etc. That's why it's popular among
| performance-critical software such as malware scanners,
| where you need native performance but as well as a you know
| customers that like a nice UI.
|
| Any kind of software could benefit from Sciter's approach,
| if just companies liked to drop a bit more of budget at
| their shipped products.
|
| --
|
| [0]: https://techcommunity.microsoft.com/t5/microsoft-
| teams-blog/...
| eis wrote:
| You said Electron would kill the performance gains of
| Perspective. You also said it would make a workstation
| fans spin somehow.
|
| The performance gains in rendering of Perspective are due
| to using canvas + Webassembly. This would be exactly the
| same in Tauri or Webview2 because it would run in the
| same browser rendering engines which execute the Canvas
| renderer and Webassembly like in a browser or in
| Electron.
|
| > The key benefits observed from the transition from
| Electron to WebView2 include reduced memory usage and a
| lowered disk footprint as resources are shared with Edge.
|
| That's exactly pretty much where the benefits end. The
| memory usage reduction is even debatable if you are not
| running Edge as your browser. See WebView2 as an
| installed Electron core that's pre-installed on Windows.
| Doesn't change rendering performance.
|
| > In the case of Sciter (quoted in my parent comment),
| Sciter is a bit different: The frontend is HTML, CSS and
| JS, but the app's local backend is whatever you want it
| to be: C#, C++, Python, Assembly, etc. That's why it's
| popular among performance-critical software such as
| malware scanners, where you need native performance but
| as well as a you know customers that like a nice UI.
|
| Yea that's why I didn't list Sciter in my reply. With
| Sciter you don't get the system webview - you get a
| custom minimalistic web html/css rendering engine that
| supports a limited subset of the HTML5/CSS3 spec. There's
| no WebGL and there's no Webassembly. So you'd have to
| bring your own libraries for that. Easy enough with
| Webassembly and they could even skip that part and go
| native but with Canvas and trying to run on all major
| platforms... it's just a lot of added work for minor
| gains.
|
| I'm not against libraries like Tauri. Perspective could
| totally use that to make a desktop app. It would not have
| any advantage when it comes to rendering performance
| though.
| airstrike wrote:
| I'm building something similar to this and going down the
| Tauri route
| haolez wrote:
| This looks pretty awesome. What's the catch? There has to be
| something :)
| andybak wrote:
| What the hell is BI?
| johnzim wrote:
| Business Intelligence
| szundi wrote:
| We reinvent the wheel again. But new tech. Perfect.
| gorbachev wrote:
| I just made a few of our data analysts drool showing them this.
| Nice work!
| imachine1980_ wrote:
| relly cool project
| [deleted]
| VWWHFSfQ wrote:
| why are web apps always so janky. no offense to the op's app.
| This is just universal. Every web app I've ever used feels like
| crap.
| simonw wrote:
| What hardware are you testing them on?
|
| I have a recent MacBook Pro and current generation iPhone and
| they're often indistinguishable from native apps for me - once
| they've loaded at least.
| snacktaster wrote:
| It's because web tech itself is crappy and the ecosystem
| surrounding it is a complete cesspool.
| adamc wrote:
| "Every" is too strong, but it's common, I agree. I infer it is
| very challenging to get things to work across web platforms
| (browsers and OS versions).
| MH15 wrote:
| Their demos performed fine for me on both desktop and mobile.
| Not sure what the issue is here, you're allowed to require some
| baseline performance level for something like this.
| wongarsu wrote:
| I had no performance problems, but right on the first demo
| each scrollbar is broken in it's own unique way.
|
| The main area with the sparkgrid has good horizontal and
| vertical scrollbars, but they are nearly invisible, being
| dark grey on slightly lighter dark grey, and only visible if
| you hover in the area they scroll. Also the vertical scroll
| bar doesn't take you to the very bottom.
|
| Then there's the top right area, which has a normal looking
| scrollbar (good), but once you scroll it changes the size of
| the entire right panel (weird), and if you drag it past the
| point where it has reached the bottom (really easy to do
| accidentally) it starts spasming uncontrollably. If you
| instead use the scroll wheel, you can scroll to the bottom,
| but if you scroll a bit further you are back on the top? None
| of the other scrollbars has either of those issues.
|
| Then there's the bottom right, where the scrollbar is
| visible, takes you all the way to the bottom, and neither
| spasms nor resets, but just to be special in its own way it
| starts out as a big bar as if there was little content below
| the fold, but the further you scroll the smaller the bar
| gets. As you scroll up, it grows again. It's also stuttering
| a bit while making these size changes.
|
| Another example besides scroll bars is the lack of tool tips
| on the UI (they do exist on data though!), which makes for a
| weird toolbar that moves its content all over the place on
| hover. And I guess you're supposed to guess that check boxes
| are delete buttons.
|
| This doesn't take away from the app, it's still cool and
| useful, but little annoyances like that add up to make it
| feel weird and un-native (I guess foreign is the word).
| egeozcan wrote:
| These aren't accessible at all. Did you try using the components
| with a screen reader, with just a keyboard and in high contrast
| modes?
|
| They look amazing but I'm a bit puzzled to why in 2023, a11y
| would not be a priority.
|
| Even this landing page itself isn't keyboard friendly.
|
| Some patterns to help you get started with ARIA:
| https://www.w3.org/WAI/ARIA/apg/patterns/
|
| Designing for a11y: https://www.w3.org/WAI/tips/designing/
| texodus wrote:
| Not sure what specifically you are looking at - the data grid
| element e.g. is a well-formed, native HTML `<table>`, as
| recommended by the w3 [1] and renders fine AFAICT with the
| screen readers in Safari and Chrome (the browsers I have
| installed).
|
| A specific report on the GitHub for issues you find would be
| much appreciated!
|
| [1](https://www.w3.org/WAI/ARIA/apg/patterns/table/examples/tab
| l...)
| dsmmcken wrote:
| Menu aside, what is a a screen reader supposed to do with a
| table changing at 100 msg/s?
| tomjakubowski wrote:
| auctioneer voice plugin
| troymc wrote:
| It's an open source project. You could create an issue on their
| GitHub repo, or better yet, create a PR and reference this
| existing issue:
|
| https://github.com/finos/perspective/issues/2133
| supermatt wrote:
| Ironically your website doesn't meet the first criterion of the
| WAI design tips you linked (the nav links):
| https://www.w3.org/WAI/tips/designing/#provide-sufficient-co...
|
| No doubt I have poor a11y on my own projects - but if you are
| going to launch into critique of the landing page, at least do
| it from a position of authority :)
|
| TBH, I am not sure how a charting lib could effectively be
| accessible to any great extent. Its not covered in the
| resources you linked, and in my experience with other charting
| libs this seems to be commonplace. I would be interested if you
| have any insights or suggestions on that, as I use charts
| extensively on one of my projects.
| andrewcamel wrote:
| Big fan of this... suspect a lot of the modern SaaS BI /
| analytics players would benefit. Just end up hitting limits
| trying to use Javascript to render large datasets, having tried
| to build some of this myself. Happy to share some potential use
| cases / thoughts on where you could apply this if helpful! Feel
| free to reach out.
| intelVISA wrote:
| Also interested in disrupting this space, do you have a
| preferred contact method?
| nextworddev wrote:
| Given how powerful Apache Arrow is, there's a lot of promise to
| this library.
| cfuendev wrote:
| Definitively not made for lightweight mobile, tried on two
| browsers (Harmonic HN Client's Webview and Via Browser) and the
| website crashed my phone.
| deathtrader666 wrote:
| Worked perfectly fine on Brave on Android.
| denysonique wrote:
| Seems like another website on the HN frontpage today not working
| with Firefox.
|
| (my previous comment regarding this issue:
| https://news.ycombinator.com/item?id=35441337#35454074)
| chandureddyvari wrote:
| Working for me on Firefox Mac.
| paranoidxprod wrote:
| The site seems to load fine for me on Windows Firefox. Are you
| having the same error as the parent to your linked comment?
|
| Edit: I see the other commenter and yes, the "treemap" is
| broken for me as well. Not something a noticed but you are
| correct.
| nanny wrote:
| Only the "treemap" chart is broken for me, everything else
| seems to work ok (Firefox Developer Edition 111.0b6 64-bit
| Linux. Enhanced tracking protection turned on).
| sporkl wrote:
| Seems to work mostly fine for me except for the Treemap
| visualization.
|
| Firefox 111.0.1 on macOS 12.5.1
| lbrindze wrote:
| I'm having issues with it loading in Safari (14.1.2) on OS X,
| but it seems to be loading fine with Firefox (111.0.1) for me.
| Its pretty zippy too, and this computer is no spring chicken...
| sinistersnare wrote:
| (I'm a contributor to Perspective)
|
| As a Firefox user I definitely want to see better FF support
| here!
|
| The first step is to get a good test suite. Currently our tests
| only run on Chrome. So after we get tests running on Firefox,
| we can move to better support it.
___________________________________________________________________
(page generated 2023-04-05 23:00 UTC)