V2 App

[NullVoxPopuli]

trafficstars

wip, ready for comments, suggestions, tho, as the details still need worked out

[SergeAstapov]

@NullVoxPopuli one important thing this has to mention - Ember Engines. Engines are basically apps and they should follow structure of regular apps.

[NullVoxPopuli]

It's possible "structure" would be a layer on top of this. Like, "structure" is a convention would an overlaying tool could enforce / provide ergonomics on top of. I plan to make a prototype of what I mean next week :crossed_fingers:

[void-mAlex]

I would propose that v2 apps behave like astro islands by default, meaning that you can have multiple apps on a page at once without each of them bringing their own runtime along

this would turbo charge the concept we have today as 'engines' as well as fit well into the desire to have a clear way to boot such an app

both webpack and vite have plugins that support module federation which is one way to achieve this goal if there is appetite for this idea, I am more than happy to help push it forward

[NullVoxPopuli]

I'm a huge fan

[void-mAlex]

also here is a mind blowing fact https://github.com/mitchlloyd/ember-islands existed since Feb 21, 2015 this just proves (yet again) that all software development is just a cycle :)

credit to @kategengler for knowing that addon exists

[MrChocolatine]

this just proves (yet again) that all software development is just a cycle :)

Yeah and in a few years the trend will be to switch back from single-file class/template to separate class and template files.

[NullVoxPopuli]

back from single-file class/template to separate class and template files.

I sure hope not.

[void-mAlex]

we should consider how we have tests running in v2 format currently the /tests path in the browser is restrictive in many ways to code that tries to run with constraints of relative paths to where the app is built it's not feasible to require the app to know the pathname it will be deployed to, at build time (not to be confused with domain name or cdn which is a different consideration)

one problem space I see is with Worker (web workers; service workers etc) that can use importScripts() the path to the scripts can be relative and with /tests path not linking back to the correct place any such work fails it's also not easy to catch these scripts from a build tooling perspective as they can be dynamically build and run at runtime in form of blobs (and importScripts behaves like require in node), which is an increasingly common way to run untrusted code off of the main thread in an isolated way

one consideration would be to have the test runner and app in completely separated server instances and do the work to wire up the tools to get a similar level of productivity you get today from tests - but how that looks exactly I'm not sure