No announcement yet.

Mozilla's Incredible Speech-To-Text Engine Is At Risk Following Layoffs

  • Filter
  • Time
  • Show
Clear All
new posts

  • #81
    The technologies that Mozilla was pushing forward with FirefoxOS were offline-first applications that used local browser storage APIs. The whole point was usage by people living in areas where internet connections were slow or expensive.
    Their problem is that they basically promoted feature-crippled and slow stuff as default way to make apps for their platform. This has been further compounded by underpowered devices. And in areas where internet connection is slow and expensive there could also be problem with power as well. Should I say web apps are grossly inefficient in data processing, and therefore woefully power inefficient as well? The more your cpu runs, the more battery is drained, as simple as that. Even Java is rather troublesome in this regard. Though Google gone hell a long way in this regard. Now they even compile it into native ELF executables on program install, if I got it right. Still, these 6 amp-hour monsters imply it wasn't terribly successful.

    It's basically a native application, but written in JS with a sandboxed set of APIs available.
    I see some people don't even know what native is. Native application is when there is native code CPU could readily run - so no heavyweight interpretation or JIT phase takes place. Needless to say, direct execution on CPU with very little fuss attached is very useful for both speed and power consumption. FF OS "native" apps don't have this property by any means. It same crippled inefficient thing and it kinda hard to do something reasonable about it, even when it hurts. Yet Mozilla smartass management preferred to "release now, pr now, think about issues later" approach. Eh, sure, but users had other things around to compare their user experience, at which point Mozilla had very little chance. Even JITed java far more featured and lightweight compared to all that "native" cruft. Apple preferred even more native appls most of time.

    And offline-first web applications can be very resource efficient, but it depends upon how your application is written.
    No way.
    1) JS never meant to be a high-speed solution that is anyhow easy to compile into native code.
    2) HTML itself is fairly featured and complicated thing, its parsing is a rather challenging task on its own.
    3) Typically web things use lame and inefficient data formats that are slow to parse. Oh sure some gamedevs got fed up and requested more efficient approach in at least some places like typed arrays, but seems they finally gave up on this and mostly hold breath for webassembly. Though later is also half-way there.
    4) There're plenty of layers on the way and web tech engines are anything but lightweight.

    Say, Google managed to compile their java things to native ELF executables. And these have no inherent reasons to be terribly slow or inefficient on their own. Good luck to do something like this with web app..

    todo manager in HTML5 with vanilla JS in a few hundred lines of code, and it barely uses any system resources to run.
    ...except truckload of RAM, 10x more cpu cycles (==battery life) and so on. So it "doesn't uses resources" on top-notch dev workstation. But when it comes to battery powered thing, especially with crappy CPU, modest RAM and small battery things suddenly change and you eventually get idea you haven't even launched anything significant, yet device already struggles and even ancient Nokia Symbian brick from prehistoric ages was able to run more tasks, showcase some realtime games with reasonable GFX, and so on....

    consume 150MB of RAM just to display a short grocery list.
    Webmonkeys really prefer to do it that way. This further screwed Mozilla up. Sure, someone of Fabrice Bellard's magnitude could make even reasonably efficient emulator of foreign CPU arch, even in JS! But most webmonkeys are nowhere close. And so it gets like this: thousands of third-rate crapplications that would give whole world of trouble - and good luck to find some masterpiece in all that huge garbage bin.

    Net result is that Mozilla spread efforts and ended up with plenty of third-rate uncompetitive stuff, chasing butterflies all the time. I also don't exactly get why they were so eager to kill everything ppl considered advantage, be it XUL api allowing extensions to deeply change browser behavior or custiomizable UI. And so they preferred to be a third-rate clone of chrome. Who needs third-rate clone if you can just download and use original?
    Last edited by SystemCrasher; 03 September 2020, 09:11 PM.