Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mighty Retrospective

blog.chaselambda.com

Post reply on HN
Print view View original

41–50 of 107 posts

Re: Mighty Retrospective

#41

Post by jamiek88 »

GMoromisato wrote: post #23
jamiek88 wrote: post #17

Earlier quoted context omitted.

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?

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 glo…

Sounds really interesting!

Thanks for the follow up.

Re: Mighty Retrospective

#42

Post by paulgb »

ghostly_s wrote: post #9
samwillis wrote: post #2

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…

Industry has been using Citrix in that problem space for nearly a decade. What does Mighty bring to the table?

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)

Re: Mighty Retrospective

#44

Post by paulgb »

samwillis wrote: post #2

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…

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...

Re: Mighty Retrospective

#45

Post by kevingadd »

quickthrower2 wrote: post #32
gruez wrote: post #7

>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?

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!

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.

Re: Mighty Retrospective

#46

Post by el_nahual »

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.

Re: Mighty Retrospective

#47

Post by kevingadd »

fragmede wrote: post #31

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.

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.

Re: Mighty Retrospective

#48

Post by TeMPOraL »

GMoromisato wrote: post #10
asadlionpk wrote: post #3

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.

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 b…

> 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.

Re: Mighty Retrospective

#49

Post by joncfoo »

yamtaddle wrote: post #12

> 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…

In Firefox, type % followed by a space and you can then search tab titles and jump to a tab.

Re: Mighty Retrospective

#50

Post by stonemetal12 »

gruez wrote: post #7

>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?

Java uses multiple threads even for single threaded code, the JIT compiler has threads, the garbage collector has its own separate threads. I don't see why a JS implementation wouldn't be multi-threaded even if it is presenting a single threaded environment.

Seems crazy to not know your application's performance profile before picking out the hardware to run it.

Post reply on HN