[HN Gopher] Mighty Retrospective
___________________________________________________________________
Mighty Retrospective
Author : drewbent
Score : 58 points
Date : 2022-11-17 20:43 UTC (2 hours ago)
(HTM) web link (blog.chaselambda.com)
(TXT) w3m dump (blog.chaselambda.com)
| iLoveOncall wrote:
| > Mighty's short term goal was to make people more productive
| with their browser.
|
| I believe the biggest reason for their failure and lack of
| traction is because they misidentified their value proposition
| from day 1.
|
| No, loading web pages marginally faster is not going to make you
| more productive. It will save you a few minutes per day in the
| best case scenario, nothing else.
|
| Productivity does not come from loading speed, it comes from how
| quickly you can identify the information that matters on a page
| and absorb it.
|
| This HackerNews page took 320ms to load, but I've been on the
| page for 5 minutes already. They really think saving even 90% of
| the load time is going to make any difference to my
| _productivity_?
| lxe wrote:
| > In addition, Suhail had been trying out building a new product
| that was showing to be a reasonable alternative bet.
|
| I see they've been distracted with AI art just like everyone else
| and had to jump on that bandwagon :).
|
| Don't get me wrong -- Stable Diffusion is probably the fastest
| progressing thing on the internet in decades.
| swyx wrote:
| yeah but do they have some core insight that makes them better
| at building the 34th Stable Diffusion UI compared to the
| others?
| el_nahual wrote:
| I wish Mighty had succeeded for a different audience. The core
| value prop "make figma faster" was not very compelling--people
| who need to use Figma can buy a mac.
|
| You know who _does_ struggle with slow computers and memory
| issues? Call center employees who have to run Front, Slack,
| Chrome, and probably one or two other electron-based apps.
|
| At our startup (not in USA), these issues are so bad we've ended
| up getting people who earn $700usd/mo M1 macbook airs anyway
| because otherwise an electron-based workflow is unamnageable.
|
| I would have _loved_ to buy them cheaper computers instead that
| ran entirely in the cloud...plus extra permission management, no
| local storage, and other "really, really, really nice to haves"
| for remote workers dealing with PII.
|
| If Mighty's value prop had been "never worry about remote wiping
| an employee's computer ever again, oh, and it's faster too, and
| it's all OPEX, and we charge you by minute instead of by the
| computer" I would have signed up immediately.
| gruez wrote:
| >CPU: We gave users a 16 core machine just for their browser, but
| it turns out that the web is largely limited by single core
| performance (think JS, layout, html parsing, etc).
|
| I'm pretty sure that javascript being largely single-threaded was
| well known knowledge since day 1. Did they not know this? Did
| they think that mulit-threaded javascript was just around the
| corner?
| [deleted]
| quickthrower2 wrote:
| JS is single threaded, but does a browser use that same thread
| for rendering, animations, web workers, network etc.? How much
| front end JS code is intensely computational vs. simply
| spending most of its time waiting on a callback?
|
| Genuine question - I might see if I can find out next time I
| have to do a performance profiling in Chrome!
| kevingadd wrote:
| The design of web APIs means that a lot of stuff _has_ to
| happen as if it were on the main UI thread, so while you can
| do fork /join stuff to optimize it - for example, doing
| layout in parallel, etc - you're still bottlenecked by how
| fast the main thread is able to do all the stuff it needs to
| do. This is why many APIs disallow synchronous use or have
| serious constraints on synchronous use now.
| [deleted]
| itake wrote:
| AFAIK, rendering and animations are on the same thread as JS.
|
| web workers have their own thread, but I think adoption is
| low.
|
| Network requests are async (JS doesn't have to wait for the
| network request for it to do other things), but JS can still
| only start one network request at a time.
| ignoramous wrote:
| _If_ each of the 100 open tabs are all run in separate threads,
| then there are a 100 active threads. I think what TFA means to
| convey is, the user is interacting with only a single tab at
| any given point in time; hence any percieved gains are bounded
| by single core perf. And that there weren 't that many web-
| native apps using service workers to make any material
| difference to the UX to justify the cost of running just Chrome
| on a 16-core i9 machine.
| mwcampbell wrote:
| I wonder if they ever got around to implementing accessibility,
| e.g. for screen readers, in their remote browser. That's an
| interesting problem. Do you send serialized accessibility trees
| (and hopefully incremental updates) down to the local machine so
| it can implement the platform accessibility API and work with a
| user's existing assistive technology (e.g. screen reader)? Or do
| you run the AT remotely as well? I believe the former is feasible
| with Chromium (though I haven't yet proven it), but Cloudflare
| went with the latter in their Browser Isolation product, probably
| because converting the Chromium accessibility tree back to HTML
| in the local browser would compromise the security benefit of
| Cloudflare's product. But Mighty didn't have that concern AFAIK.
| fragmede wrote:
| The place where they really could have won is iOS, where browsers
| aren't allowed to use their own rendering engine, and system
| specs still lagged behind the M1.
| kevingadd wrote:
| I'm sure Apple would have rejected the app from the store,
| unfortunately. Lots of vendors have failed to get streaming
| apps of this sort onto the store and had to (heh) distribute
| them via Safari as web pages instead.
| samwillis wrote:
| While I never really believed in Mighty as a concept, I think the
| technology has enormous potential in some industries. A robust,
| performant and versatile VNC like toolkit to enable traditionally
| desktop software to be made available in the cloud could be be
| very successful.
|
| There are many CAD, Visualisation, Rendering, Editing, and
| Simulation tools that are incredible CPU, GPU or Memory intensive
| that could be made available in a collaborative environment for
| the first time using some of the Mighty tech. I hope someone
| picks it up and explores other ways it could be used.
| ghostly_s wrote:
| Industry has been using Citrix in that problem space for nearly
| a decade. What does Mighty bring to the table?
| samwillis wrote:
| I think it's more of a hybrid approach, the web renderer was
| running in the cloud, the ui was native and local.
|
| I beleve Citrix is mostly a standard VNC type product where
| everything is rendered on a server and streamed. I was
| envisaging a toolkit to enable you to build an app where
| parts of it run in cloud, parts of it locally.
|
| Think of a 3D cad tool, the ui could be all local, but the
| rendering and compute is in the cloud. Or a 3d physics based
| ray tracing app, you could do the 3d wire frame locally, but
| have the real-time ray tracing happening on a very large
| server.
|
| On top of that, by have a cloud based state, it's only one
| step away from marking that state shared with other users to
| enable collaboration.
| paulgb wrote:
| Having used both Citrix and Mighty, it's clear Mighty cared
| about latency in a way that Citrix doesn't (or, more
| generously, is out of control of Citrix since they don't own
| the end-to-end system)
| cokeandpepsi wrote:
| parsec, nvidia's thing and a few other companies are already
| in that specific space as well, mighty just seemed dumb
| slashink wrote:
| There are tons of these solutions in production for well over
| 10 years. Big media customers has run virtualized edit bays in
| AWS for at least 4 years at this point.
|
| Reasons people don't use these solutions are the same reason
| Mighty ended up not working. Even in CAD applications, latency
| matters when trying to move objects in 3D space with precise
| mouse input or using a 3dconnexion spacemouse. Sure, you can
| overcome latency by doing what Google essentially invested in
| with Stadia, run GPU's closer to the edge but at that point the
| cost of just buying workstations for your employees is not that
| different from acquiring a stable connection (for 8+ hours a
| day) with the fee of renting the hardware.
| jamiek88 wrote:
| Isn't this just Citrix?
| paulgb wrote:
| We've been working on a way for browser-based apps to run a
| rendering thread on the server and streaming back to the
| client, possibly composited into client-sode-rendered UI. So
| far the results are promising: you get the power of a server-
| side GPU with no additional latency for the normal UI
| interactions that can be drawn without a server round-trip.
|
| Here's a demo of a full-blown Blender "running in the browser"
| (I don't have a demo with local compositing yet, so this is all
| server-side)
|
| https://twitter.com/drifting_corp/status/1583460106963820545...
| swyx wrote:
| previous discussion:
| https://news.ycombinator.com/item?id=33583830 4 days ago
|
| interesting that https://www.mightyapp.com/ still has not been
| updated with any mention of shutdown
| asadlionpk wrote:
| Streaming Chrome with some value adds must have been a short-term
| product right? It could only have existed until PCs caught up on
| processing speed (Apple's M1?).
|
| I wonder what vision did Suhail pitch to PG to deserve high
| praise. Because this can't be it.
| [deleted]
| GMoromisato wrote:
| The ultimate vision is/was to have everything run in the cloud.
| Imagine if you could run any app on the most powerful machine
| in the world.
|
| See: https://blog.mightyapp.com/mightys-secret-plan-to-invent-
| the...
|
| In my opinion, this is the right goal, but I don't think this
| can be done by running existing apps in the cloud (and remoting
| their UI). Instead, I think we need a new cloud-native platform
| so that any app can be written as a cloud app. (Obligatory
| self-promotion: that's what we're trying to do with
| https://gridwhale.com)
| TeMPOraL wrote:
| > _The ultimate vision is /was to have everything run in the
| cloud. Imagine if you could run any app on the most powerful
| machine in the world._
|
| IMO the core paradigm shift that needs to happen is for the
| software _and_ infrastructure to become commoditized. The
| only way for cloud-everything to not be a nightmarish abuse
| of the end-users is for the mode of operation to change, from
| the current "data comes to the app", into "app comes to the
| data". That is, I believe the data, the application and the
| compute running it need to be independent to the extent
| possible.
|
| In particular, the choice of an app and where it runs should
| be entirely up to user. The user should be able to easily
| switch from e.g. a cloud run by Amazon to e.g. a "cloud" run
| by their HOA in the basement of their block of flats. And
| then possibly switch to a cloud run by a company local to
| their city, or one of their employer, etc.
|
| The primary point behind my view is to prevent application
| vendors from being able to take their users hostage by
| keeping users' data under lock on their own infrastructure,
| accessible only through their own software. The second point
| is to increase efficiency and boost local markets worldwide.
| swyx wrote:
| as pmarca is fond of saying, ideas are never wrong, just
| early. i bet at some point in the future a New Mighty will
| come along and work
| jamiek88 wrote:
| Hmmm. Interesting. Would the UI be local and compute remote
| in this paradigm? And how is that different from the old thin
| client model?
|
| just read your site, and I'm thinking of this as more like a
| super massive global mainframe?
| GMoromisato wrote:
| Yes, that's exactly it. Local UI (initially in the browser,
| but could be on a rich-client or mobile app) but all
| compute is in the cloud.
|
| The difference from existing thin-client models is that
| it's a single stack: When you write a program, you write
| the UI code as if on a local computer. E.g., you just call
| MessageBox("Hi, there") and the platform is responsible for
| remoting that as appropriate.
|
| "A super massive global mainframe" is the correct analogy,
| but instead of a text-mode VT100 terminal, you get a full
| remote GUI (more like X Windows).
| jamiek88 wrote:
| Sounds really interesting!
|
| Thanks for the follow up.
| janef0421 wrote:
| Or people started closing tabs more frequently and/or used
| something other than chrome.
| dhoe wrote:
| My guess when it launched was (maybe too cynically) that it's
| the 100% complete visibility of user behavior.
| samwillis wrote:
| A team with a background in data analytics, starting a fully
| hosted browser platform? You don't have to squint too hard to
| to come to that conclusion.
|
| Although they did claim to keep your browsing data privet:
| https://www.mightyapp.com/security
|
| Maybe four years ago it was seen as a strong counter to
| ad/tracker blocking. But now, with increased regulation and
| consumer resistance they couldn't make that play?
| dhoe wrote:
| Doesn't have to be personal data. You'd know the
| performance of every website's funnel, most used features
| of every app etc. Somebody would have paid a lot for it.
| nickdothutton wrote:
| I have some experience building infrastructure for on-demand
| cloud hosted desktops (HDx3DPro) for scientific users and their
| apps. Often wondered if there was a consumer play there too.
| Better someone tried and failed than never tried at all.
| fleddr wrote:
| I always found the idea to be bizarre.
|
| The group of people for which a browser is truly horrendously
| slow would be on something like a low-end Windows laptop. From
| mid-end and upwards it's fine (or good enough) and for Mac users
| pretty much never an issue.
|
| The people with such crappy hardware are exactly the group to not
| be able to afford 35$ a month. That's like the price of 3 or 4
| streaming services combined. Just to browse!?
| fossuser wrote:
| I had a similar impression of it, the best I can come up with
| is I think it was a bet based on a prediction of the future
| that is kinda true, but just doesn't matter as much as they
| thought.
|
| 1. Personal computers are dead and just a means to access a
| browser via dumb terminals
|
| 2. Applications will be Figma style - web based entirely.
|
| 3. Intel/AMD chips are bad and not getting that much better
| (this one is true, but missed the mark entirely because of
| Apple silicon throwing a curve ball)
|
| 4. Given that your personal computer is basically a dumb
| terminal to a web browser you could imagine a world where it
| doesn't matter and it's worth paying $35/mo for a super
| computer to run your web apps streamed to whatever local
| hardware you're using, since your local machine is basically
| useless as a machine and only serves to load a web browser
| (which is where your actual applications are). This super
| computer will also remember state so any devices you access
| mighty on is exactly as you left it. Long term, this could end
| with a Chromebook like devices of some sort that just connects
| to mighty and are really nice low power hardware.
|
| --
|
| Personal bias aside (I hate this future and I'm actively
| working on software trying to bring personal computing back in
| a from first principles networked way) - it was a bet on trends
| and fits squarely into the PG concept of a good startup being a
| bad sounding idea that might have recently became good because
| of changes in the environment that have not yet been really
| recognized. I think Apple made it less relevant. I also agree
| there's a weird issue of who is the actual target market at
| that price point (the exact people that would maybe need it can
| also afford good hardware).
|
| That and there is obviously fertile ground in AI right now and
| the founder sees a bigger opportunity there with a lot of low
| hanging fruit.
| andrewstuart wrote:
| I had expected Mighty to pivot to solving the giant problem of
| corporate computing security.
| paulgb wrote:
| You might find Whist interesting
|
| https://www.whist.com/
| FanaHOVA wrote:
| https://www.island.io/ (not affiliated in any way)
| yamtaddle wrote:
| > RAM: Mighty allowed users to open hundreds of tabs without
| being worried that their RAM would be consumed. But my sense is
| this was not a killer feature. The benefit simply isn't massive:
| the alternative is to close tabs and "clean things up". Many
| people probably do this anyway because it's visually hard to have
| hundreds of tabs open, so users end up closing tabs even with
| infinite RAM. This is evident in the data: when we gave users
| 32gb of RAM, 90+% of them didn't go beyond 16. We did have the
| opportunity to provide users with a whole new interface of tab
| management - one in which tabs never have to be closed and
| hundreds of tabs are visually manageable. Maybe this would have
| been a smash hit, it's hard to be sure.
|
| What I want is for the address bar to give me a really quick way
| to jump to existing tabs, if I start to type in the address of
| one I already have open. The entire reason my tabs get out of
| control is that at some point I get enough open that I start to
| lose track of what's there, and repeat myself. End up with like 5
| AWS tabs, only one of which I'm actually using, stuff like that.
| So finally I just bookmark the whole set ("just in case"--I've
| not _once_ looked back at these, in almost a decade of working
| this way, though I bet there 's some great shit in there) and
| start over.
|
| Apple's "tab groups" approach being a solution, but the trouble
| is I forget to switch to the correct group for a given site and
| end up using a single jumbled-up session anyway. It needs better
| (more automatic, probably) UI.
| Jarwain wrote:
| > What I want is for the address bar to give me a really quick
| way to jump to existing tabs, if I start to type in the address
| of one I already have open.
|
| Chrome's been doing this recently and I absolutely love it
| joncfoo wrote:
| In Firefox, type % followed by a space and you can then search
| tab titles and jump to a tab.
| mmcclure wrote:
| Others mentioned Chrome doing this, but it never really seemed
| to work reliably for me.
|
| This actually came up in a thread the other day, so feels weird
| to be talking about it again, but I've been playing with Arc[1]
| lately. Took me a while to get used to how they treat tabs
| (almost more like bookmarks) but I've enjoyed it. Squirrel the
| ones I want to truly keep around into folders ("To Review",
| "Some Project"), but all the randomly opened tabs automatically
| get closed after a specified time period (default 24 hours, I
| have mine set to a week). When I hit cmd+t I can _reasonably_
| often get to the right tab I've already got open.
|
| I have a feeling the honeymoon will end when they start trying
| to figure out a monetization strategy, but so far I'm rooting
| for them.
|
| [1] https://arc.net/
| jamiek88 wrote:
| Yes tab groups has helped a lot and is _nearly_ there but not
| quite.
|
| I try and be disciplined but like you end up having to manually
| stop myself and drag tabs back to the 'proper' group.
| jemmyw wrote:
| The tab groups extension for Chrome works well for automating
| moving tabs to the correct group.
| https://chrome.google.com/webstore/detail/tab-groups-
| extensi...
| yamtaddle wrote:
| Just manual settings I could use to say "always open this
| site in tab group X" or "prompt to move this site to tab
| groups Y or Z if I open it somewhere else (but with the
| option not to)" would probably make it usable-enough for me.
___________________________________________________________________
(page generated 2022-11-17 23:00 UTC)