JavaScript mode doesn't work with more than one .pde file

[teo1978]

It seems you didn't take into account that Processing supports sketches made of more than one .pde file, e.g. with one main sketch file plus one file per class definition. You can add files from the IDE.
In Java mode they are compiled together.

processing.js also supports that by simply inserting the list of files in the data-processing-sources attribute of the canvas node.

However, JavaScript mode ignores that, only copies the one main .pde file into the web-export folder, and only includes that one in the data-processing-sources attribute.

This renders JavaScript mode useless for sketches including more than one file.

Additionally, since the web-export folder is wiped out every time the sketch is exported, there doesn't even seem to be an easy workaround.

JavaScript mode should copy all .pde files, not only the one with the same name as the folder, into web-export, and include all of them in the data-processing-sources attribute (I don't remember if they need to be separated by commas or spaces or what)

[fjenett]

No, JS mode does of course support multiple tabs. Their content will be concatenated into one .js file as part of the pre-processing (same as normal Processing does).

You seem to experience some other problem which is hard to debug here because you give hardly any information beyond ranting. Please email me your sketch and i will have a look at what is not working.

[teo1978]

No, JS mode does of course support multiple tabs. Their content will be concatenated into one .js file

You're right. I was experiencing another problem. I didn't realise the files were being merged.

However, instead of merging the files into one monolitic file, it would be much better to keep the files as they are and include all them in the data-processing-sources parameter. That way, the source code would remain as is. Of course this implies also creating one link per file to the source code in the html.

Should I file a separate issue or edit the title of this one?

[fjenett]

There is no need to file an issue: merging the files into one was done to speed up start-up time for sketches because one file loads faster than many.

[teo1978]

What about a configurable option?

[GoToLoop]

In this case, both JS & CS Modes are doing exactly what Java Mode would do:
Concatenating all ".pde" files into 1 valid & compilable file.
If we want separate files, in Java Mode we'd create a ".java" suffixed tab.
In JS Mode a ".js" suffixed tab. And finally in CS Mode a ".coffee" or a ".js" suffixed tab.

[teo1978]

@GoToLoop that's almost a good point, but there's a catch.

In this case, both JS & CS Modes are doing exactly what Java Mode would do

With the difference that in Java mode that's invisible: the ultimate result of exporting the sketch is a jar, anyway.
On the other hand, in JavaScript mode, when you export the sketch you also export a web page with links to the source code, and by concatenating all files into one, you're altering the source code that's being published. Some may want that for the sake of faster loading, but for those interested in sharing the source code, having the source code merged into one file cripples the readability of the source code.

If we want separate files, in Java Mode we'd create a ".java" suffixed tab.
In JS Mode a ".js" suffixed tab. And finally in CS Mode a ".coffee" or a ".js" suffixed tab.

then they wouldn't be portable any more. You don't do that just because you want separate files. You do that when you want:

• separate files
• not to be parsed by the Processing preprocessor
• specific to one mode/language

That's a completely different use case.

[GoToLoop]

With the difference that in Java mode that's invisible...

• PDE always generate 1 concatenated ".java" file outta the ".pde" tabs in the system's "temp" folder.
• That's necessary in order for all of the classes & interfaces across those ".pde" tabs to be nested to the sketch's top class.
• If we export the sketch via CTRL+E, we're gonna see that very same ".java" file among the others!
• That very same approach is also used for both JS & CS Modes.
• All ".pde" tabs are concatenated and become 1 enclosed ".js" function.
• And all of the classes & interfaces in the sketch are nested to that enclosing function.
• That's an important mechanism that allows Processing to be easier for artistic & hobby programmers.
• That we can directly use Processing's API w/o using a reference prefix! :D

[GoToLoop]

There's a way for the PJS to work w/ separate files w/o concatenating them:
Insert everything in the global naming space in place of an enclosing function!
That's the very approach used by p5*js framework btW. ;-)

[teo1978]

PDE always generate 1 concatenated ".java" file outta the ".pde" tabs in the system's "temp" folder.
That very same approach is also used for both JS & CS Modes.
All ".pde" tabs are concatenated and become 1 enclosed ".js" function.

Yeah, so what? Is your point that I was wrong because I said "invisible"? C'mon, I meant it's an internal intermediate compilation step, that has no relevance to the user. Note that the .java file is not just the concatenation of the pde files, it's also preprocessed into java code. That's comparable to the js function (except that the latter doesn't need to be stored into the file).

The source is the source, and when publishing the source it would be nice to publish it unmodified. PJS is able to run the sketch from the separate .pde files and doesn't need to have them merged, so the most elegant way to publish the sketch with its source is to publish the source files as they were written. It's the most elegant way, but not the fastest to run, so it makes sense to have both options.

Note, btw, that when you export a sketch as a java application, it creates a "source" folder where the source .pde files are copied unaltered.

[GoToLoop]

• I thought you were asking about having the same amount of output ".js" files as there are original ".pde".
• Those ".pde" files are more like pseudocode than valid running code.
• And needs a pre-processor in order to transform them into real source code.
• For now we should just copy the ".pde" tab files into the "web-export" folder, replacing the concatenated ".pde" there.

[GoToLoop]

P.S.: Both JS & CS modes transpiles all ".pde" tabs as a unified ".js" file, rather than have that ".pde" to ".js" transpilation happening at ".html" runtime!

[GoToLoop]

I guess it's gonna need some modifications in the generated "index.html" template in order to list each ".pde" file I guess:

<p id="sources">Source code: <a href="Ball_in_the_Chamber.pde">Ball_in_the_Chamber</a> </p>