Why is "applet is gone" an important change in Processing 3.0?

strinda

Could you please explain the importance of this change?

If possible in plain, simple terms as I am not sure I will be able to understand a very technical, complicated explanation.

GoToLoop

Java's Applet class provided most Processing sketches needed to be embedded in a AWT's Container and even run on a web page using Java's plugin:

http://docs.Oracle.com/javase/8/docs/api/java/applet/Applet.html
http://www.Oracle.com/technetwork/java/painting-140037.html

All of a sudden , Processing devs decided to be completely independent from it and then write their own PSurface to replace most of its functionality.

But then all libraries, tools, modes or whatever that assumed class PApplet is a sub-class of Java's Applet has stopped working.

Therefore we're gonna have some period w/ not many compatible libraries available.
Plus any bugs that exist and will continue to pop up due to such "ambitious" about re-writing everything from scratch.

Chrisir

what are the advantages?

GoToLoop

I hope it's speed. But didn't see any signs of it yet!
API-wise, Precessing 3 didn't bring any new function.
Only some band-aids like settings() so we can use variables in size():
https://processing.org/reference/settings_.html

clankill3r

I think one of the advantages is that things can be more streamlined with P5.js and Processing.py. I doubt it is speed. Cause that would not make sense by changing the map method to one that is 3 times slower then the previous one.

KevinWorkman

From: https://github.com/processing/processing/wiki/Changes

Java Applet support is being removed, starting in 2.0 alpha 7. It simply doesn't make sense to support these anymore, given our priorities, lack of web browser support, and I don't have any time to support them. A steady parade of issues like this one, while browser makers and OS vendors make applets all the more difficult and unappealing is a losing battle and life is too short for such things. It's an unfortunate change, but simply the reality of where we're at. Applets were always an important, essential part of Processing because it was important to be able to make your work available online. At the moment, using Processing JS (or Processing 1.5) is instead generally a better option for things that run on the web. (And before anyone asks, no, we will not be adding JNLP support in its place. If someone wants that, they should write a JNLP Export Tool.)

strinda

Yes, I read that, it is just I don't quite catch the idea. If the author of the post "doesn't have enough time for ..." then why bother using a whole different approach?

• "Applets were always an important, essential part of Processing because it was important to be able to make your work available online."
• "At the moment, using Processing JS (or Processing 1.5) is instead generally a better option for things that run on the web"

I don't follow the logic.

• Applets are a bad on-line solution (due to browser / OS issues)
• Being web-friendly is now not very important as we have p.js
• We are not going to use apps any more

If being web friendly is not a priority, why not stick to apps?

I thought the main reasoning was something like: "We used to stick to "app" because we wanted our sketches to be run on-line, but this is no longer a priority so we are going to use a more efficient/faster/cooler way".

To make myself clear - I think they know what they are doing, just being curious:)

KevinWorkman

Well, be careful when you say "app". That's a different thing than "applets".

Processing was originally based on Java Applets because that was the best way to get powerful graphical code on the internet.

Since then, applets have become worse (in fact, applets are all but dead), and JavaScript has become more powerful.

Due to this switch in "what's better", JavaScript/html5 is now the "correct" way to deploy to the web. Trying to deploy as an applet is a losing game.

So, Processing decided to drop support for Applet, because the dependency on Applet introduced a bunch of complications that were no longer worth it. Processing.js has taken the place of Applet, so Processing no longer needs Applet. Might as well cut the fat off, as they say.

Being web friendly is still important. In fact it's one of the things that makes Processing great. But we no longer need to rely on Applet to do so. Instead, we rely on Processing.js.

strinda

Thank you for the explanation,

Does it mean, for non-web solutions so to say, there are easier ways to get around than applets?

KevinWorkman

For non-web, you can simply deploy as an application.

I'd like to see a tutorial on the new recommended way to embed Processing in a Java application, but that goes a bit beyond what you're asking about.

blindfish

If the author of the post "doesn't have enough time for ..." then why bother using a whole different approach?

Presumably because in the long term taking the time to remove Applet support now will save time; compared to having to continue to fix bugs caused by support of dead functionality.

You're now left with the choice:

• use Processing to create high-performance applications with no direct web output. If you don't need library support you can probably output to ProcessingJS to get them onto the web.

• If you do depend on supported libraries you have to decide between offline only or lower performing web output (assuming you can find equivalent JS libraries) using p5.js/ProcessingJS; or manually porting code to use different libraries for each.

fry

No need for speculation; the reasons for the change are explained in great detail here.

strinda

Thanks, I didn't know it was there!