Hacker News Reader

Comment by lasagnaphil | Hacker News Reader

No, this is definitely not running at desktop speeds. I have a Ryzen 7 2700, and this thing lags often even with basic UI operations (clicking buttons and menus, dragging objects). Now imagine someone with a dual-core laptop CPU... this will be even worse. It certainly feels like this is a web app rather than a native one.

View on HN

Well, it's written in Java, so desktop app probably lags as much. So title does not lie :D

Now that hurts :-). Java has been pretty amazing for many years. Many Java desktop apps ran poorly because they were written poorly.

I used to give demos of the Swing version of this app 15 years ago, and people would try to convince me that my app was written in C, because a Java app can't run that fast. Those were weird conversations. I'm not even that clever - I just try to write simple code.

This is my experience with java > 7. The JVM with default settings is pretty excellent these days (see JetBrains IDEs: they're MASSIVE but they run just as well as any other native desktop app.) The issue as far as i see it is that the "enterprise" way of thinking that has and still does dominate the majority of development that results in java code is so bad that it starts to seem like its the language/runtime.

>they're MASSIVE but they run just as well as any other native desktop app

Not for me. They're starting up long, UI is laggy. In comprasion to native IDE like Qt Creator they're really slow.

I used to write apps with Swing nearly 20 years ago (before javax), and making even simple apps perform without tearing and atrocious performance was really, really hard.

Fortunately, CPUs have caught up with Java, eventually :)

In my experience Java beats most languages out there in the speed department.

I'm not arguing about server side java apps. But java UI apps is still trash.

You forgot to add the date of your post

"Well, it's written in Java, so desktop app probably lags as much. So title does not lie (2001)"

Right, now computers come with 4+ cores, so it does not lag as much.

It runs at native speed on my iPhone. Sounds like your browser has an issue...

No. Not quite. Framerate for me oscillates between 12-30fps (2018 XPS 15 laptop). It's quite usable but not 'desktop speed'.

What browser?

I get desktop speed for Chrome, Safari, but FireFox does lag for me. The first run does load various UI files on demand, but once cached, most delays go away.

Yeah, what's up with that? I use Firefox a lot, and I've noticed it always has poor performance on heavy JS apps. The off time I need one of such apps is the only reason I keep Chrome installed on my system.

Firefox has worse performance than Chrome overall, despite what their synthetic benchmarks might say.

How are you measuring 'overall'?

I am not measuring it, that's the point. Synthetic benchmarks are useless when real life experience shows the opposite.

As an enlightened individual as I'm sure you are, we strive to remove personal bias when possible. This includes measuring statistics. Which can take the form of synthetic benchmarks, but also real life tests, like page load times of notoriously bad news sites, or heavy cpu bound tasks like image resizing in the browser.

If you're not measuring it then it's pretty much subjective, no? You can't quantify what you don't measure.

I don't know how you use Firefox and Chrome (I use both in work) but they behave pretty much identically as far as I can tell, once ads and other crap have been blocked.

The only difference is Chrome is snappier on Google sites and seems to use double the memory to open the same tabs.

That probably has nothing to do that everyone is now optimizing for Chrome.

I've noticed that too. I think it might be that these days "idiomatic high-performance JS" might just be another way of saying "makes use of Chrome's quirks, strengths and optimizations". I imagine there's some things Firefox just can't do quite as fast as Chrome because of design decisions. The reverse probably also holds true, but that doesn't help as much if you aren't the market leader.

Chrome's JS engine is optimized for real-word usage.

FF's is not.

As a member of the Mozilla JS team, let me tell you that we're working on optimizing our engine for real-world usage all the time.

Some optimizations are better in SpiderMonkey than in v8, some are worse. Unfortunately, whenever a web developer optimizes solely for v8/Chrome, this hurts Firefox.

This might be a lot to ask of a random internet comment, but is there anything common you tend to see in apps that make them look/feel overtuned to v8?

I'll freely admit that i'm guilty of the "develop for chrome, test in firefox" kind of workflow, and I really want to improve on that. I feel like I have built up a kind of "intuition" about what works well and what doesn't over the years in chrome, and i'd like to start building that up for other browsers.

I'd guess a lot of that sort of optimization happens at the framework/library level (React, Emscripten, etc) and less so in your typical application code.

I have never once "optimized solely for V8" (I honestly have no idea what runs better in Chrome vs. Firefox).

All I know is that I build an app as I think makes sense logically, and 100% of the time it runs faster / less hot in Chrome.

JS-heavy apps burn thru CPU cycles far more on FF than in Chrome.

I want to use FF as my daily driver, I really do. But it's real-world performance just doesn't cut it for me, and I don't think you can blame that on people "solely optimizing for Chrome", as V8 was a better engine at the moment of release, when nobody had had a chance to optimize for it.

Do you develop and test using Chrome, or Firefox, or both? If you aren't testing in Firefox beyond "it displays correctly" but you are using Chrome for your normal development, and testing, you are de-facto optimizing for Chrome, because you'll notice slowness in Chrome and work around if, but that same thing may have been fast in Firefox, but you never noticed. That's what being the market leading browser grants them.

Do you happen to have a link to a specific thing you built that runs faster in Chrome? I'd love to take a look at what's going on there...

Real-world JS is optimized for V8.

Except you're reversing the order of the chicken and egg.

Real-world JS was already in production when V8 was released, and it had orders of magnitude better performance at the time.

I don't disagree at all, V8 was and still is revolutionary. However, the second order effect of V8 having captured such a large portion of the market is that developers will code/tweak/optimize until their app/library is suitably performant on V8 and then stop. No value judgement, it's totally rational but the effect is that now a lot of JS code has an implicit dependency on the quirks of V8 in order to be fast.

There's really no good solution to this because the kind of performance tuning we're talking about explicitly pierces veil the VM is supposed to provide. You're pretty much always going to target the internals of one particular engine. So what this means is that anyone working on a competing engine not only has to provide the same behavior but also the same performance profile because it's something that JS devs expect to be there now.

Yeah, basically "we made this run fast on Chrome".

I'm running on a surface. Seems fine.

Reply on news.ycombinator.com