roxiness / roxi

34 stars 3 forks source link

Roxi vs Sapper #1

Closed benmccann closed 4 years ago

benmccann commented 4 years ago

Hey Jakob, thanks for all your help and answers on my various Routify questions!

I've been contributing a fair amount to Sapper and was checking out Routify to compare. Routify and Sapper's routing layer seem very similar in many respects. I was wondering if there were ways to collaborate or share more stuff, but don't have any specific ideas

I was curious to learn more about Roxi and what its goals are. If we figured out a way to decouple Sapper's router and make it pluggable so that you could use Routify instead would that be interesting enough to combine forces on the server-side / framework stuff?

jakobrosenberg commented 4 years ago

Hi @benmccann, at the moment Roxi is only planned as a frontend framework.

Currently a fair share of what we offer isn't available through Routify, but is provided by the starter template: SSR, instant deployments, Nollup, service worker, etc. Unfortunately, relying on a starter template presents us with a difficult upgrade path. This is where Roxi comes in. Roxi takes on the features provided by the starter template, but provides a much smoother upgrade path.

I won't rule out an optional server at some point, but it's not on the current roadmap.

benmccann commented 4 years ago

Got it. Thanks!

quantuminformation commented 4 years ago

frontend framework, means no SSR?

benmccann commented 4 years ago

My understanding is that Routify/Roxi does provide SSR, but doesn't use Svelte's built-in SSR support like Sapper does and instead uses JS DOM

quantuminformation commented 4 years ago

I was looking at the code and was interested to see that it supports all the build systems:

https://github.com/roxiness/roxi/blob/master/templates/config.wrappers.js#L5

jakobrosenberg commented 4 years ago

@quantuminformation the config system has been rewritten and a new preview release should be published in a day or two.

The new release will be similar to what you linked, but rather than wrapping each config individually, the whole app instance gets passed.

Example:


const devServer = require('nollup/lib/dev-server')

module.exports.default = {
  hooks: [
    {
      name: 'set rollup.compileConfig to true',
      event: 'start',
      // Nollup needs the Rollup config, so make sure Rollup compiles its config
      action: app => app.config.rollup.compileConfig = true
    },
    {
      name: 'start nollup server',
      event: 'after:bundle',
      action: async (app, params, ctx) => {
        //start the nollup dev server
        devServer({
          port: params.port || app.config.roxi.port,
          ...
        })
      }
    }
  ]
}

The above is taken from the Nollup plugin, but it could also be copy pasted to a local file like custom.plugin.js which could then be loaded in the Roxi config..

#roxi.config.yaml

port: 3000 #app.config.roxi.port
plugins:
  - custom.plugin.js:
       port: 5000 #params.port
jakobrosenberg commented 4 years ago

@benmccann, my local Roxi build has changed quite a bit over the last few months and it's no longer Routify centric. In fact Routify and all other services have been turned into small plugins which can be combined and replaced at will. In my current project, I'm using Nollup, Vite, Rollup and Spassr simultaneously. There's no real benefit to using them all, but it's doable. 😅