About altiva and sapper

[paulocoghi]

I'm worried about doing something wrong and so I decided to open this issue.

About two years ago I prepared a rudimentary tool (altiva/altiva/tree/1.5), using Ractive, to facilitate the creation of apps solving the common problems like routing and independent loading of components according to the routes, etc.

At that time the project was just a personal experiment but, after meeting Svelte, I decided to substitute Ractive for it (altiva/altiva/tree/2.0), maintaining the same goal but striving to launch an official page and documentation in order to help more people.

But, currently I'm feeling a bit wrong 😬, since Sapper was made to fulfill the same purpose and it was born (practically) on the same date (but I had no idea of its existence when Rich started it 😁).

Therefore, I would not like to divide forces that are rowing in the same direction.

I'd like to hear from you, what would be the most ethical thing to do. I thought about migrating all my work from Altiva to Sapper but:

• Rich Harris code quality is much higher
• Altiva's code is still rudimentary, although I believe it fulfills well its work and purpose
• although the two projects solve the same problem, the approach is quite different in each case

If any of you find anything interesting in my project (even if it's just the concept), I reinforce that you can copy everything you want, especially @Rich-Harris .

What's more, if you think that Altiva's approach is interesting in some way, I see no problem in eliminating my repository and bringing everything that is useful to Sapper.

---

On the other side, in case you conclude that the projects are considerably different, would it be wrong for me to keep Altiva going?

---

Thanks! 😁

[paulocoghi]

I can explain here the whole idea (since there is no official page that explain it) if anyone is interested, that may be useful to both Sapper and/or any other project.

Basically, the routes and it's components are defined by an object:

app.areas = [ 'menu', 'submenu', 'breadcrumb', 'content', 'footer' ];

app.route[ '/login' ] = {
	content: 'Login'
};

app.route[ '/' ] = {
	menu: 'MainMenu',
	content: 'Feed',
	footer: 'Footer'
};

You can define "areas" that can receive components, and in each route you choose which components must be loaded.

The main concept of this approach is to know all the app structure from the beginning, which allow the creation of a "main app" component that has all the routing and component loading rules.

Also, routes that have one or more areas that use the same components, those components remain untouched, which accelerates even more the route transition.

There are other things but this is the main point. :)

[Rich-Harris]

@paulocoghi argh, sorry I never responded to this issue, I had been meaning to! I definitely think there's no harm in having multiple similar projects trying out different ideas; often it will yield insights that are harder to reach in the context of a single project. At the same time, spreading resources too thinly can mean we all move more slowly, and obviously I'd be glad for any extra contributors to Sapper 😀. Ultimately we all win either way.

The point about route transitions is a good one — this is something we definitely need to figure out in Sapper, hopefully sooner rather than later. I've been pointing people to sveltejs/sapper#157 as the most likely direction to take, though there's lots of research still to do.