Mighty
Suhail Doshi (tweet, Hacker News):
We’re excited to finally unveil Mighty, a faster browser that is entirely streamed from a powerful computer in the cloud.
After 2 years of hard work, we’ve created something that’s indistinguishable from a Google Chrome that runs at 4K, 60 frames a second, takes no more than 500 MB of RAM, and often less than 30% CPU with 50+ tabs open. This is the first step in making a new kind of computer.
[…]
One answer is moving more client-side compute to the cloud. […] If you can move the most demanding processing, then battery life can finally improve because video decode and render times (we’re streaming video here) get more efficient with better chipsets. […] If most of the time people spend is in a browser and most of the processing and system resources are offloaded, their computer won’t feel slow as apps become more demanding.
This sounds like an amazing technical achievement, if it works as described, yet also an indictment of the modern hardware/software stack. Personally, I mostly work in native apps and don’t find the Web unacceptably slow, certainly not to the point of wanting to rent a VM in the cloud or give a company all my data.
Previously:
Update (2021-05-03): Francisco Tolmasky:
Anyone who asks “why would anyone need Mighty?” has their critique backwards. It should be: how is it that Mighty is a compelling value prop? How is performance of native apps a non-issue on a $600 iPad, but we’re moving mountains to make web apps bearable on high-end hardware?
Traditionally, the strategy for a disruptive platform that has a built-in disadvantage (in this case performance) is to attack new or neglected markets. The web however has repeatedly insisted on focusing on areas that highlight its weaknesses, while seldom offering anything new.
[…]
@Suhail is right, the web of 2021 isn’t for reading blogs. You know how I know this? Because when I go to a medium.com link, it bounces me into to Medium iOS app. Because not only have we failed to offer the the future, we somehow managed to lose ground too.
The web lost mobile, full stop. And yet I’m still seeing pitches for how “the future of the Desktop is the web” like it’s JSConf 2009.
20 Comments RSS · Twitter
I legitimately thought this was a late posting of an April Fools joke. What a sad commentary on browsers that someone thought this would be worth designing and selling.
...takes no more than 500 MB of RAM, and often less than 30% CPU with 50+ tabs open.
I'm confused that those figures are supposed to be impressive for a streaming video container.
@vintner I think they’re meant as a comparison with a browser running locally, where each tab may use a few hundred MB of RAM.
It's really an indictment of web standards and modern web browsers such as Chrome.
A 200 page book in UNCOMPRESSED Postscript takes 1.6 Mb. Postscript, as you may recall, is not exactly terse. It's a program that tells the computer where to place each letter, and where to draw figures with primitives such as lines.
It's truly bizarre. We spend inordinate efforts inventing H265, compressing video down to nothing, but webpages can use 100s of Mb. Perhaps we just couldn't ask the blue haired youngsters to learn a Forth-like language, could we? Their precious little heads might explode, and that would be such a shame.
@Michael Comparisons against browser bloat can make most anything look good. But resolution aside, 10 years ago I was using OnLive to stream a Windows desktop + browser to a 512MB iPad 2 at high framerate and responsiveness.
Coincidentally, a couple of days ago I was telling someone that his "simple" blog page had ~7,000 characters of actual content and more than 500,000 characters of code, not counting content loaded from CSS, content embedded from other sites, web fonts, and other media.
Can you copy stuff from the web page it displays? Because from time to time I copy stuff from my browser to my WP....
I thought the radio was one of the most power-hungry things on a device, which would suggest that a streaming browser is probably not going to save power?
"Perhaps we just couldn't ask the blue haired youngsters to learn a Forth-like language"
I'm going to assume that you're joking, but just in case: JavaScript is not the problem. The problem is that a lot of programmers have a pathological hatred for JavaScript, and have only ever written code in moronic imperative programming languages like Forth, so when they see a modern, functional programming language like JS, they start whining about how confusing it is, instead of investing a day or so into really grokking functional programming.
This means that it is extremely difficult to hire actual software engineers with experience in JS, which means that a lot of JS developers are (for example) visual designers who made a career switch, which means that a lot of JS code is written badly, which means that we're stuck with bloated websites.
Also, all the add tracking garbage doesn't help.
Even so, I regularly have tens of dozens of tabs open, and somehow, things are just fine. This product is truly weird.
@Plume:
When they see a modern, functional programming language like JS, they start whining about how confusing it is, instead of investing a day or so into really grokking functional programming.
You're talking to someone who has been coding Haskell for over 30 years... and before that LML and Miranda. I "grok FP". That doesn't mean I like Javascript. In my book, Javascript is barely functional (pun intended). It's mostly imperative, and certainly is not modern, unless by that you mean pre-postmodern. Whoop-di-doo it's got closures! Manna from Heaven! Frankly, I find it awful. No laziness. No purity. Verbose. Slow. Weird corner cases. And yes, I've coded enough years in it to know what I'm talking about. It's only advantage: ubiquity.
"Moronic imperative languages like Forth"
Here, unfortunately, you prove you truly don't know what you're talking about. Forth can be used imperatively. But you can also use it to write functional code, to no less a degree than you can in Javascript. It also supports garbage collection with the appropriate library (the entire language is basically defined by library. "Syntax", if one can call it that, is the space character). I was put off by its weird looks too, and it is old so it is rarely used in an FP style. But once you get past that, it is in fact very neat, reminding me of Lisp. Factor pushes the functional idea further, but you could do that in Forth if you wanted. I actually wasn't joking. Forth is really worth studying, particularly if one's goal is to write tiny things with lots of functionality.
add tracking garbage doesn't help
Languages with GC ran perfectly well back in the 1990s when a 33Mhz 486 was the state of the art, as was 8Mb of RAM. GC doesn't have to mean slow.
I regularly have tens of dozens of tabs open, and somehow, things are just fine. This product is truly weird.
Thanks for making my point. We're living in a world in which it is impressive that a 4GHz multicore machine with 8Gb of RAM and an SSD is able to run a dozen tabs, each mostly doing the sorts of computations that a properly programmed 68000 running at 8Mhz with a few Kb could do trivially. Yes, in those days, we had rich text editors, games running at 50fps, sound synthesizers, and so on.
You're talking about Javascript running "just fine" on what would have been a supercomputer 20 years ago. The M1's GPU alone provides 2.6 teraflops. That's more than ASCI Red, the supercomputer Intel delivered to the Sandia National Laboratories in 1999 !!! They simulated nuclear explosions on that beast.
Where you are right is that "a lot of JS developers are (for example) visual designers who made a career switch, which means that a lot of JS code is written badly". Those are the blue haired people I was referring to... who think they know how to program because their code vaguely does what they want. They don't.
Indeed programming requires real skill and learning. It's not just gluing bits copied from Stack Overflow together. If you're interested in programing, please don't get stuck in some silo, and think you're done, that you've found the Holy Grail. I kind of did that with Haskell for a while. There's always a lot more to learn. FP is great for certain tasks (Compilers/AI). Imperative for others (e.g. embedded, games, many computer vision tasks). OO for others (GUIs). Logic programming again for others (AI). And Deep learning for yet others (AI). Assembly is also worth learning to really understand how computers actually work. Learning all these paradigms will make you a much better coder, providing you with different conceptual tools. You'll know learn which ones best fit each job. It's a lifelong and fascinating journey...
The problem is that a lot of programmers...have only ever written code in moronic imperative programming languages like Forth...
lol
...so when they see a modern, functional programming language like JS
LOOOOOOOOL
>In my book, Javascript is barely functional
Spoken like somebody who never really used JS.
>Forth can be used imperatively. But you can also use it to write functional cod
Forth can be used to write functional code in the same way C can be used to write object-oriented code: you're not technically prevented from extending the language with functional concepts. If that's good enough for you, great. Me, I'll stick to what I said in my previous post: it's moronic. Use the appropriate tool for the job.
I get that this is not what people here want to hear, but language design has actually made a lot of progress in the past 50 years. This is probably scary for octogenarians like you or vintner, but unless you're willing to accept this, software companies will keep hiring these darned blue-haired kids, and you'll have to keep being angry about the youth, and telling everybody else stories about how you used your punch card to give deadly paper cuts to that poor German soldier in WW2 ;-)
>We're living in a world in which it is impressive
I didn't say it was impressive.
@Plume
Your arguments truly demonstrate your expertise: you speak in generalities, throw around plenty of judgements and provide no evidence. You also accuse others of lying. That won't serve you well in life, particularly when you're wrong. Oh, and you can't count (no octogenarians served in WW2 on the Allied side).
"Your arguments truly demonstrate your expertise: you speak in generalities, throw around plenty of judgements and provide no evidence"
This must be the least self-aware comment I've yet read on this blog.
"You also accuse others of lying"
For somebody who has no issues accusing others of lacking experience, you seem to be very easily triggered by that same accusation.
A programmer who claims that "Javascript is barely functional" is clearly a programmer who has very little experience actually using JS. You can dislike JS's language design, and we can argue about that, but you can't argue that it is "barely functional". That's just not a reasonable position to take for somebody who has extensive JS experience. So there's your evidence: based on how you talk about JS, "your arguments truly demonstrate your expertise: you speak in generalities."
"That won't serve you well in life"
I find it amusing that you make all of these assumptions about me, and then get very upset when I make assumptions about you. Don't you find that at least a little bit hypocritical?
"no octogenarians served in WW2 on the Allied side"
Oh, so now you're admitting that *you* were lying when you told that story about the deadly punch card paper cuts, and you never even served in WW2? :-D
I have no idea what you're talking about Plume. Punch card paper cuts? What??? I don't recall any such story. You must be confusing me with someone else. The only WWII thing I may have mentioned might have been that my grandfather fought in WWII. Unsurprisingly he was born some time before me... He'd be over a 100 today.
To the point "Barely functional":
Haskell is a functional programming language. JS isn't. It's imperative, with some functional constructs.
That lets you write some things in a vaguely functional style, like you can in Python, or Forth, or C++, or C. But it's emulation, not actual functional programming:
R.pipe(
R.filter(v => v.type === 'suv'),
R.map(v => v.price),
R.mean
)(vehicles);
versus Haskell:
mean $ map price $ filter ((=="suv").type) vehicles
In Haskell, the compiler will fuse these functions together and produce a single loop. In JS all this will be done at runtime which makes it useless if that loop runs hot.
function dot(vector1, vector2) {
return vector1.reduce((sum, element, index) => sum += element * vector2[index], 0);
}
versus Haskell:
dot v1 v2 = sum . zipWith (*)
Clearly Haskell is way more functional than JS: the use of higher order functions is not discouraged, since all these higher order functions, and separations of concerns, will be compiled away into a single loop by the compiler. But there's a lot more to a fully functional language (pattern matching, purity, possibly laziness, immutability, a strong type-system, etc). The problem is that functional programming is a spectrum, and there's no clear definition of what is, and what isn't a functional language. Nevertheless I'd call JS imperative with some functional constructs.
There's another aspect to my quip. I dislike JS' "design". I'm not the only one, otherwise "let" would not have been introduced to fix var's ridiculous scoping rule. ==, === etc? What were they thinking? In my book, JS is a poorly designed language. Yes, you can make it do things, and if that's what you mean by "functional", fair enough. But to me the entire point of designing a language is to reduce cognitive load on the programmers, to allow ideas to be expressed clearly, without stumbling over lots of quirks that don't need to be there. Therefore to me, JS is barely functional: it is a step backwards in clarity versus what came before.
Every single one of the steps from punch cards, to machine code (writing hex for instructions), to assembly (writing mnemonics for instructions), to C (writing higher level constructs while still having an idea what the assembler would do), to C++ (avoiding boilerplate for doing OO + templates to produce a variant of polymorphism), to Objective-C (better albeit slower OO), to Haskell and its predecessors (actual FP), Python (easily used glue with few quirks) and Prolog (logic programming) allowed for better ways of expressing oneself. Even Forth is neat because it requires very little runtime and can be used when developing firmware. Rust too is an improvement on C... Although I never used punch cards, with each of these transitions/languages, I could see clearly how and why the new language improved my code. But not with JS. I see nothing I cannot do better with some other language, except that it's currently needed for web browsers. I hope WASM will provide a way to avoid it.
Finally you said that FP in Forth would be as clunky as FP in C. I disagree. Since there is no syntax in Forth, you can actually get closer to something that feels like FP than the equivalent C would be. And because there is no syntax, it is easier to write your own compiler pass equivalents to translate your "Functional Forth" into something more imperative. This is what you have to do to run fast, since CPUs only understand imperative code (which you call moronic). To my eyes, that makes Forth and Lisp much better platforms for playing with multi-paradigm ideas than JS, C, or Haskell will ever be.).
Now all of this is not to say that one can't use JS to write good code. For 3D code, much of this code looks nice and clear to me: https://ciechanow.ski/js/ice.js But if it were written in C or C++ it would look much the same. And its result looks good too: https://ciechanow.ski/internal-combustion-engine/
Obviously you like JS. Good for you. Perhaps you'd care to explain in what ways it helps you solve problems better than any of the languages that I have mentioned could. By this I mean the language itself allows you to express ideas better in code. Something intrinsic to the language. I don't mean extrinsic qualities such as "it runs in a Browser".
"I have no idea what you're talking about Plume."
I'm sorry, there seems to be a huge discrepancy in how seriously we take this discussion. I was referring back to my previous comment where I analogized your "blue-haired youth" comments to telling stories about WW2. I do understand that you didn't really tell any WW2 stories.
"[JS is] imperative, with some functional constructs."
JS supports all of the language features that are commonly used to determine whether a language is functional: first-class higher-order functions, lambda expressions, closures, currying, etc. It's true that it is missing some features that other functional programming languages have, but I'm not sure if you'd find a lot of people who would agree with you that a static type system is a necessary part of what makes a language functional.
But you're also right, in that JS doesn't *only* support writing functional code. It also allows for imperative programming, and it has a prototype-based object system, which you can also make work like a class-based system. That's what makes JS an effective programming language: you can use the paradigm that fits the problem. A pretty typical use case for JS is a code base where you write UI code using a prototype-based object-oriented approach, but then also have a controller that talks to the backend, or works with data in general (e.g. if you're writing an Electron app), where a functional approach may make the most sense.
It's pretty difficult (or outright impossible) to do this kind of thing with most other programming languages, whereas with JS, it's effortless. It's how the language is intended to be used.
I do agree that JS's designers made a lot of mistakes early on, and it is true that many programmers formed valid, negative opinions about JS in the 90s and early 00s. The thing, though, is that even back around 2005, you didn't have to use most of these badly designed language features. They mainly remained in the language for backwards-compatibility.
About let: it's true that variable scoping in JS is a controversial topic, but IMO, the way var works wasn't a language design flaw, it was just different from what people were used to (and yeah, it was a source of bugs for people who didn't get how it worked). I'm pretty sure the primary reason why let was eventually introduced had much more to do with execution performance (e.g. let helps with garbage collection), and less with dev experience. Although admittedly, now that we have let, I'm using it :-)
The thing, though, is that I don't even like JS particularly much. I think all programming languages are pretty bad, except maybe Prolog, which is really fun to use. The main reason why I defend JS is because a lot of the criticism people have of JS is just not valid. I find this particularly grating coming from Objective-C programmers, who have somehow convinced themselves that their terrible C pre-processor (that admittedly has two or three good ideas in it, all of which were stolen from Smalltalk - also, I know it's not a pre-processor anymore) is somehow the best programming language ever invented, and who form very strong opinions about JS after spending five minutes misunderstanding its basic concepts.
JS is bad, it's just not as bad as people pretend, and it isn't worse than most other programming languages, it's just bad in ways that confuse people who are used to the badness of other programming languages.
It would be nice if we could all just come together and agree that programming languages in general are pretty sucky.
You two do realize the topic is… a weird network computing- or VNC-reminiscent browser, not programming languages?
To Plume's point, JS is more the symptom than the problem. That language was clearly never designed to do the kinds of tasks it performs these days, just like the Web was never designed for apps, but for pages.
(Also, give it up, Haskell will never be popular.)
@Plume
Thanks for your answer. After learning Objective-C properly, I found it, to my surprise, to actually be better in some ways to C++. And one could combine them (Objective-C++) which I did for one project. You might be right about Smalltalk. I have yet to spend any time with it. Haskell is pretty nice in its domain too.
@Sören
I didn't know Michael had appointed you his electron-shepherd. Perhaps he'd like to confirm your exalted position of censor-in-chief.
The discussion is relevant: the product exists because of how the web was designed. Had it been designed like one of its predecessors, the Network Extensible Window System, products such as this would never have been created.
Why popularity should matter to an engineer is beyond me. Mathematics isn't popular but it's very good at keeping planes flying, and bridges from falling down. I'm glad most of engineering has yet to succumb to popularity contests. If it did, there would be a lot of unnecessary suffering. It's a shame that people feel software is different. Popularity of a tool should be irrelevant, only whether it enables the engineer to produce a good product should matter.
>Why popularity should matter to an engineer is beyond me.
Of course it matters.
It's fun to occasionally dabble in tech that isn't popular, or even to, say, write your own little programming language. But when you actually want to ship, popularity means you have lower likelihood of major bugs, and higher likelihood of third-party tools, libs, tutorials, a community, etc.
There's (for better or worse) an exponential effect to that. If few people use something, that ecosystem of libraries and community never develops. If, OTOH, it experiences some adoption, that leads to more libraries, and more people sharing their experiences, which in turn entices more programmers to give it a shot.
> Mathematics isn't popular
That's clearly not what I meant by "unpopular".
>Popularity of a tool should be irrelevant, only whether it enables the engineer to produce a good product should matter.
Yeah, and you know one of the factors that "enable the engineer to produce a good product"? Popularity.
(Obviously, my remark regarding Haskell was a bit tongue-in-cheek. But it's the kind of tech that some feel will be the next big thing soon™. Haskell may take more advantage of FP than JS does, but, also, you'll have a much easier time getting a JS-based project going or starting a job writing JS. I'm glad you enjoy Haskell, but you brought it up in the context of web browsers. There was no scenario where a language that doesn't mind being niche was also going to become the main scripting language of browsers. JS has its quirks but was ultimately good enough to ship to the masses, and evolve.)