Hacker News Reader

Hacker News

Comment by adamrmcd | Hacker News Reader

Full thread

adamrmcd

I understand the reasoning behind this, but this is super annoying, since:

1. I am required to use GWT 2.5.1 for our java webapp

2. I choose to use Chrome on Mac OS X

3. Chrome 39 just auto-updated to support 64-bit on OS X

4. Chrome 39 stopped supporting NPAPI

5. GWT-2.5.1 and the GWT Chrome extension are not 64-bit compatible, and require NPAPI.

6. I have a major deadline this week finish styling our webapp

I've heard that enabling SuperDevMode can workaround all these problems, however I'm just an HTML5/CSS3/GWT-UI-Binder developer, not a Java/Eclipse/GWT expert. PITA.

(Perhaps I should enhance my calm and work on some LaTeX or Python)

View on HN

This is a par-for-the-course complaint about NPAPI plugins (since they're binary, they're beholden to all the issues of 32-bit 64-bit compatibility, compile to the operating system, etc., etc., etc.).

Given the improvements in JavaScript performance and webgl over the past half-decade, it's a small wonder that browser maintainers want to kill NPAPI support as fast as possible. It's a bad experience for them, generally a complex experience for end-users, and essentially a massive hack.

Yes, but then how do you enable support for things that the browser doesn't give you (e.g. someone else talked about pen/stylus input devices)? How do you write something like It'sAllText for Chrome? Current NPAPI-less solutions involve the need to run a separate server to communicate with, which launches the $EDITOR process.

You don't, by design. You improve the browser to expose the functionality you need with a sandboxed API, or you communicate with a separate program that runs entirely outside the browser.

If you want to support a pen or stylus, you add a pen/stylus API to Chrome.

I've been waiting for an API addition, that I had been personally assured by Chromium PM would go through, for 4.5 years. It's needed to support full canvas screenshot functionality in ChromeDriver, so it's not exactly a fringe use case. Given the time it takes for some of this stuff to go through, NPAPI was at least an option. That's the point of a plugin API after all ... so not every use case needs to be accounted for by the parent project.

I realize there are security issues and all that. But it's not as simple as hoping Chrome will just add the API you want either, in my experience.

If I want to support a pen in Chrome, and the way to do it is to modify Chrome, I am going to give up. I do not have the skill to do that. If I have to learn an entire different programming language to do something, I just don't have the time to do it right now.

> You improve the browser to expose the functionality you need with a sandboxed API, or you communicate with a separate program that runs entirely outside the browser.

What is your response to the 'browser is bloat' crowd then? Your solution is to add functionality to the browser even for people that don't need it. Doesn't this lead to bloat in the browser itself?

I find this kind of astonishing on the part of GWT. NPAPI has been deprecated in Chrome for more than a year, and yet GWT's development mode still depends on it?

SuperDevMode[0] has been a thing for the past year or 2 (which doesn't use the NPAPI plugin). The GWT team just released GWT 2.7 which makes SuperDevMode the default development mode (they also added incremental compilation which rocks).

GWT is ready for it, the problem is that most people that use GWT are doing it in "enterprise" world, where upgrading libraries is super painful.

[0] http://www.gwtproject.org/articles/superdevmode.html

The GWT team saw this coming a long time ago, that's why we undertook SuperDevMode. It's not just chrome that yanked our APIs, Firefox removed NPAPI, Safari make it incompatible with DevMode, and the rise of mobile devices which don't run plugins, pretty make DevMode useless for mobile development.

Our only options are to either ship our own browser fork, like Dartium does and like we used to do with GWT < 2.0 Hosted Mode, or to make Javascript debugging work. We opted for the latter.

In GWT 2.7, we can recompile million line apps in seconds, and with Source Maps, and IDE support, you can back some of the original Java debugger experience. In IntelliJ 14 in particular, it works very nicely. Folks are working on Eclipse integration of SourceMap debugging.

NPAPI is a security risk and puts restrictions on other parts of the browser internals and how they're represented. We can't prevent Chrome, Firefox, and others removing this API just because of GWT.

Ironically, Microsoft might end up supporting this API forever, so GWT DevMode might continue to work with IE.

Download an older version of chrome, and turn off auto updates.

I had to resort to Firefox 24 on OS X, however I found a Chromium 38 build. Guess that'll do for now.

http://www.freesmug.org/chromium

Could not find any older builds of Chrome for OS X

(updated to say I'm on OS X)

www.oldversion.com/windows/google-chrome/

Maybe this will help http://google-chrome.en.uptodown.com/mac/old (fair warning, I didn't actually tried to download/use any of these).

That's perfect! .. Insta-bookmark!

Although I did find Chromium 38 did work to get me back online, this uptodown site will prove useful for other tests requiring full Chrome.

Thanks!

https://www.modern.ie/en-us/virtualization-tools#downloads

Two months from now: "what kind of moron turns off auto update? You deserved to be pwned!"

This whole thread is based on OP's need for GWT Chrome extension to develop his company's webapp. So presumably OP can have a old Chrome version just for web development and a separate browser for his regular browsing needs. I doubt OP will get pwned by his own company's internal development site.

Simultaneously running a safe browser and an unsafe browser and hoping you never open a link in the wrong one seems fraught with peril.

google "portable chrome".

problem solved.

Did you actually try it? It's almost impossible to get a hold of the old versions of chrome now. Google tool down almost all of them.

No, thankfully I'm not in a position to need to. I'm just commenting on how ludicrous the situation is.

Reply on news.ycombinator.com