Still less than Google's site for the new Pixel [1] :)

[1] https://tools.pingdom.com/#!/ckhRCy/pixel.google.com

97.7% of which is images. Also, PageSpeed gives it a 48/100 on desktop.

I would like to see what is the size of this page in countries with slower internet.

I would guess they don"t care. These countries are not exactly the target market for such a expensive phone.

It costs $2.60 to view the website in Canada with non-retina images.

Source: https://whatdoesmysitecost.com/test/161007_QR_78c23294113b6c...

Why the heck are they using PNG for a large photo panorama? That's 5MB right there for one image.

While I agree and upvoted you, I think the realistic answer is that the alternative to this 34 MB editor is no editor like this at all. The author made what they wanted with the tools they knew.

You seem to be contradicting yourself.

If the binary size is big because of the (lack of) tools the author knows, the alternative to this is an editor made by someone who knows tools that don't bloat the binary.

He's not.

This exists because the tools existed to enable the author to make this in a reasonable timeframe/effort.

If something better/smaller exists, use it. If it doesn't exist, it might be because making it smaller requires tools that take more effort/time to use and thus no one has bothered.

I've traditionally liked crapping on bloated software too, but have come to realize that the plethora of software is fine and I can use whatever I like and abstain from what I dislike. The simple fact is that the alternative to bloated software is a subtraction of that software. And sometimes they happen to be useful, despite their size.

Thanks for sharing this point of view, man.

I am not really crapping on bloat.

I am merely correcting the point that the only alternative is no editor at all.

On your first point; alright, then my mistake.

But my comment was really in response to your second line here. I disagreed with your assertion. The alternative is that this editor doesn't exist, meaning "no editor at all" with this specific featureset/design/etc. And if this editor is better than a less bloated editor, why shouldn't it exist?

I agree with you, I just think we need to find/publicize/develop a better solution for writing lean applications for the desktop. It's really sad that our easiest option right now is something that results in a 35 MB distributable package.

I think we've lost the binary size battle, just as we've lost the bandwidth battle. I agree, there has to be a better way, but development convenience is being prioritised.

Why do you say "lost"... Technology brought us an orthogonal solution to the problem, but yet, it is a solution :-)

Maybe one day, when we'll run out of whatever-it-takes to build computers, we'll have to optimize for size, but that's another story.

I still remember the days of C64 and the 640kb limitation in DOS. What we got was first optimization then full on hacks and mostly assembly language.

To use a tool and give up on size really doesn't bother me. I rather have elegant solutions then full on hackery or difficult memory management type solutions.

And we've lost the dynamic library battle. I understand why but can't help being saddened by it, it was such an elegant solutions.

I'm really glad we're finally starting to win the dynamic library battle; it was a kludgey fix for a transient storage bottleneck that has been plaguing us with unnecessary complication for at least a decade now. Predictability is a good thing.

It's not such a good thing to have to update each and every application whenever there is a vulnerability in a library.

Meh, I feel like it is even better because even if you could update the library indvidually you have no idea about the ramifications of such an update and what potential other vulnerabilties/bugs doing so will uncover.

You could install the electron or nw.js runtime separately and then just download/distribute a compressed file with the JavaScript source code. Witch would be smaller then most programs.

Elegant in theory maybe, rough in practice.

I don't think so, have we? Windows applications are very small because all the UI libraries are in the OS itself, where they should be.

SolveSpace looks exactly like the sort of "user-unfriendly" tools I build for myself and am absolutely personally productive on but would never release to the general public. Maybe I need to re-think this ;)

That said I'm getting back into GUI editors. Anaconda for research computing. And Atom for text and code. Including Markdown.

The advantage is Atom's module system. 5000+ third-party creations. Including really edge cases. That, I believe, is due to the reach of JS/HTML/CSS.

It's very very not user-unfriendly. I finished the tutorial in 20 minutes and it was very intuitive and exciting!

Python+Qt is very nice to program with. Portability is nice between Windows and Linux (that's my experience)

But binary size is big :-) The Qt libs are not exactly small nor is the python interpreter.

Yep, I was stunned when I realized the total distribution size for a tiny script I wrote that used numpy+scipy would run over 300mb. And here I thought Electron apps were big...

That's a good question. If I want to write a cross-platform tool I wouldn't know what to choose either (besides electron that is).

Maybe Xamarin?

Qt is not bad. I got interested in libui (https://github.com/andlabs/libui), but it stalled a bit, after a couple of months of very promising activity.

i wish D had good, complete qt bindings. it seems like the best option for a new standard compile-to-native desktop gui app language. i have a personal preference for ML-family languages, but i think those have already lost the war for mindshare; D on the other hand is solidly C-family and therefore familiar, but is a way more pleasant language than C++.

D's binaries still aren't small[0], what with including the entire prelude without code elimination.

Sure, they seem tiny alongside Electron, but a giant doesn't look big next to Jupiter.

Nim competes in the same space, and seems to hit this problem a whole lot nicer. [1]

[0] http://forum.dlang.org/thread/yhcopkgdkhclbkfpisut@forum.dla...

[1] https://hookrace.net/blog/nim-binary-size/

I do agree with everything you said, but a) I'd still rather the giant than jupiter and b) Nim still has a long way to go to prove itself. Just like D, it is in the awkward position of being high performance without fully addressing either the performance or safety concerns of the preceding languages. This may be an acceptable tradeoff but neither have any killer features that make it an obvious good fit for a given problem. Rust has memory safety-like, actual memory safety-and go has utter simplicity. What is the Nim two word pitch? Small binaries isn't going to win anyone; that's what deflate is for. Meanwhile, you don't have the language stability and, erm, prudent design that D has hammered out for over a decade. Even if I don't agree with the decisions I can't say D has executed poorly.

Nim though? Who knows! I've never seen it in production, so I can't tell the downfalls!

Absolutely agree on a.

I think the popularity of Electron is a travesty.

I live in Australia, but despite it being a first world nation, the Internet speed is miserable and bandwidth is precious. (I pay $50 a month for 100gb, at 1.5mbms). Size still matters.

I do quite like D and the structured process of developing the language they use.

But I also find it incredibly depressing that Nim has a better optimising compiler.

> What is the Nim two word pitch?

Metaprogramming. The best metaprogramming anywhere.

What about Lisp-family languages' metaprogramming capabilities?

i'm pretty sure the racket folks would take issue with that (:

Go+QML worked okay-ish for me in a few brief tests. While Go tends to make large-ish binaries, it's not nearly as bad as Electron.

go-qml and forks don't support Go >1.6 due to the cgo breakage; some manage to compile, but with a memory leak.

There's github.com/therecipe/qt which is a full Qt binding (not just QML). You have to set-up a proper dynamic linking build process if you don't want 100MB binaries though, and the bindings require a default Qt installation or a folder full of symlinks to fake one if your Linux distro splits Qt in different folders.

Really? That's very surprising to me. Doesn't the OS include everything required to display text already?