Would it be possible to split morphic.js into 65 files and use a bundler of some sort?

[menasheh]

I'm trying to understand morphic, and other pieces of snap, and the files are huge. If they were organized differently and the end result file was generated instead, that would make it way easier for me.

[jdittrich]

I know the issues is pretty old already but I am having the same problem in reading the code.

I see several ways to deal with it:

• Just splitting the files up and importing a long list of files in the beginning of the HTML; if a bundled version is needed one could just concatenate the files.
  • PRO: Very low-tech
  • CONTRA: No explicit dependencies
• Using a bundler:
  • PRO: Ship one file, explicit dependencies possible (import/export)
  • CONTRA: Build step
• Using ES6 Modules:
  • PRO: explicit dependencies; bundling step possible but not required, no long import list.
  • CONTRA: Browser/JS Engine needs to be newer than ~2018, modules need to be served by a (local) server (not needed if bundled, obviously)

[jdittrich]

I just see that the topic is a really old one: Issue #4 alread deals with it!

[jmoenig]

hmm... sure, I guess. The I way I use Morphic.js for Snap! is mostly in a rather 1950-ish code style, as a whole subsystem that's even in charge of the whole namespace. I'm happy to avoid any deployment or build scripts, but I realize that some of you might be benefitting from just that....

[cycomachead]

The only thing I think we really ought to avoid right now are import maps. I would LOVE from them to work, but they’re just too new still, especially with Safari and iOS to be used in a deployed environment. A build tool could be nice but we do have both Snap! and morphic to consider. If we are ok going down this route, I’d look at esbuild. Now, it could make sense (for testing or development ease) to have an approach that uses import maps when running locally and an esbuild when deploying. There are a few things to consider though:* for better or worse Snap! and morphic are kind of coupled in development. it’s been easy to share the 2 files between the two repos “manually”. I’m not sure it makes sense to this if we have 50+ files. But perhaps it’s fine.* we will either need to store compiled versions of Snap! and morphic in the repo, or write a (hopefully small) deployment script that does the compilation. * proper modules and encapsulation might necessitate some API changes but it shouldn’t be huge.* this could ease some minor annoyances in deployment today like dealing with cache busting in a few different places. -- Michael BallFrom my iPhonemichaelball.coOn Oct 23, 2023, at 9:21 AM, Jens Mönig ***@***.***> wrote: hmm... sure, I guess. The I way I use Morphic.js for Snap! is mostly in a rather 1950-ish code style, as a whole subsystem that's even in charge of the whole namespace. I'm happy to avoid any deployment or build scripts, but I realize that some of you might be benefitting from just that.... —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jdittrich]

but I realize that some of you might be benefitting from just that....

For me it is mainly a matter of having an easier time to understand the code and its internal dependencies. I understand that avoiding deployment or build scripts makes sense. On the other hand, the script would need to run once for each release, so using the single large file ("jquery-style") would still be possible.

If we are ok going down this route, I’d look at esbuild

Makes sense. I thought of rollup, but ESBuild has the advantage that it seems to be a single complied file which is easier to handle than large node.js programs with many dependencies.

Either way, development could still happen directly in the files as long as the files are served by a small http server, like the ones that are build into many languages (like python’s python -m http.server).

avoid right now are import maps

I see no reason to use import maps (but I am no expert in morphic, snap or import maps either!) At the moment there seems to be no mechanism to conditionally load parts of morphic if needed, and until need arises, I guess import maps are not required.

[menasheh]

I'd like to put in a good word for vite, if bundler/build step would be ok. Its really simple to use, for the most part developer experience just works if you wire it up.

[jdittrich]

Vite is nice, too. Question is if we need what vite adds to rollup on which it is based (and thus, like rollup is node.js based)

[davidedc]

Just an (unrequested) alternative view that in http://fizzygum.org (at https://github.com/davidedc/Fizzygum , spawned from Morphic.js) I've let the system itself fetch its own source automatically looking at the dependencies (looks at source code and sees where a class needs another), compiles itself (I use CoffeeScript, but anything that can compile to JS would work too) and to build itself.

If it loads itself from sources it takes ~10 seconds to boot, if it loads "from pre-built" it takes ~0.5 seconds.

In any case (whether the system builds itself or is pre-built), no server is needed, and the Coffescript sources (could be any other language that transpiles to JS) get loaded after boot and are available from within the system and can be modified (via the Inspector of course).

There is a shell build script that does minor things like minifying the build and making sure that the right files end up in the right place. There is no further "dynamic loading" happening actually (say, if you only wanted to load an app when it's launched), I should do that, but again I feel I would go for an "in house" solution for many reasons, including fun.

Not arguing that this is a better/best way (I would go for a batch/shell script that just cats together a bunch files and call it a day TBH, depending on a shell is maybe crude but fairly safe/plain while depending on the build system flavour of the day has its own problems), it's fairly byzantine, but it was fun to make and I think for people who use/tweak things like Morphic.js this kind of byzantine approach of "let's make everything work from within the system as much as possible" approach could be interesting and if anything it's quite fun ;-)

[cycomachead]

I think someone ought to start with very specific goals before picking a tool - but I would say 'less is more' here. A simple shell script is probably fine, but presents problems on windows (if anyone cares....lol). -- Michael Ball | michaelball.co Lecturer | UC Berkeley Computer Science Software Engineer | Gradescope <https://www.gradescope.com/?utm_source=michael_ball> m: (909) 993-3988 | CV <https://www.michaelball.co/resume>

…

On Fri, Oct 27, 2023 at 9:45 AM Davide Della Casa ***@***.***> wrote: Just an (unrequested) alternative view that in http://fizzygum.org (at https://github.com/davidedc/Fizzygum , spawned from Morphic.js) I've let the system itself fetch its own source automatically looking at the dependencies (looks at source code and sees where a class needs another), compiles itself (I use CoffeeScript, but anything that can compile to JS would work too) and to build itself. If it loads itself from sources it takes ~5 seconds to boot, if it loads from pre-build it takes ~0.5 seconds. In any case (whether the system builds itself or is pre-built), the Coffescript sources (could be any other language that transpires to JS) are available from within the system and can be modified. There is a shell build script that does minor things like minifying the build and making sure that the right files end up in the right place. There is no further "dynamic loading" happening actually (say, if you only wanted to load an app when it's launched), I should do that, but again I feel I would go for an "in house" solution for many reasons, including fun. Not arguing that this is a better/best way (I would go for a batch/shell script that just cats together a bunch files and call it a day TBH, depending on a shell is maybe crude but fairly safe/plain while depending on the build system flavour of the day has its own problems), it's fairly byzantine, but it was fun to make and I think for people who use/tweak things like Morphic.js this kind of byzantine approach of "let's make everything work from within the system as much as possible" approach could be interesting and if anything it's quite fun ;-) — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALPU43X6ITF6XYIVWQ7RJ3YBPQJRAVCNFSM4E2V7IV2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYGMZDCNBRGA2A> . You are receiving this because you commented.Message ID: <jmoenig/morphic. ***@***.***>