Consider switching from Ruby to Node.js

[MasterOdin]

middleman-sprockets is basically dead, while also bringing in the equally dead sass gem. While we could drop sprockets (and then middleman will just use the sassc gem), it breaks the JS files from working. It looks like the suggested way nowadays is to set-up an external pipeline that would then use webpack to do this step. The downside is that it would make NodeJS / NPM a key dependency to build slate. Upside is that we use things that are actively maintained and supported and forward facing (and get off sass completely).

@lord, @MikeRalphson thoughts?

[MikeRalphson]

It is clear that middleman and the whole Ruby packaging system is causing a lot of headaches for people, and means we cannot properly support some platforms (such as Windows). middleman-syntax also seems to be unmaintained.

The downside is that it would make NodeJS / NPM a key dependency to build slate

My gut feel is that if that should come to pass, we should explore porting Slate to NodeJS entirely in version 3.0, and ditch Ruby. Several proofs-of-concept exist (though I believe my own shins is the only one which has been kept up to date with core slate).

[MasterOdin]

Would that step basically entail just archiving this repo, and then continuing development on shins, or did you have something else in mind?

[lord]

I'd be in favor of switching, although not sure how much bandwidth I'd have to contribute towards a conversion, although I guess shins would get us basically all the way there for free 😄 Thanks again Mike! We already require a javascript runtime anyway, right?

May want to wait a lil bit to see if there is strong consensus among Slate users? I can pin this conversation for more visibility. I'd expect most who really want Ruby to still be on some old fork of Slate anyway, so new incompatible updates aren't of much consequence to them.

I'd also be curious to what extent the markdown parser would be compatible with the one we already have — ideally a user with no Slate customizations could copy over their index.md and have everything work perfectly. IIRC different markdown parsers handle things like tables differently.

[lord]

Oh, and to add to the markdown parser comment — maintaining #-URL in-document link compatibility could also be a nice-to-have feature.

[MikeRalphson]

@MasterOdin because Slate has the visibility, what I was thinking of is more along the lines of merging shins in to a v3.0-alpha branch of this repo, probably with the user interface tidied up - so there is a single node slate script with say build and serve commands with their own options. Then we could just merge to master and release a v3.0.0 on npm and archive shins.

@lord markdown-it the markdown processor used in shins has many plugins available so if we identify any different behaviour to Ruby slate we could swap them in and out, or even fork or write our own, for things like auto-links, tables etc.

One question I guess is would we stay with custom JavaScript code which is very specifically written to produce as-slate compatible output as it can, or would we look at some kind of NodeJS equivalent of middleman (like hexo, gatsby or next.js) which would probably diverge from the Ruby slate way of doing things but give users a more widely used platform to build on?

[MasterOdin]

middleman-syntax also seems to be unmaintained.

I mean, it currently supports the newest versions of rouge, so I think for now it's probably in a fine state for what Slate needs. It's really just middleman-sprockets that's totally dead.

One question I guess is would we stay with custom JavaScript code which is very specifically written to produce as-slate compatible output as it can, or would we look at some kind of NodeJS equivalent of middleman (like hexo, gatsby or next.js) which would probably diverge from the Ruby slate way of doing things but give users a more widely used platform to build on?

For me, the answer to this I think is how much would things change in regards to styling and such if it was to move to a whole new platform, and also how much custom code would be required to replicate what middleman is providing (though I think it's somewhat less a question of middleman providing and the supporting infrastructure like rouge and redcarpet that are more important?).

It does seem like Gatsby and next.js are aimed at a much different use-case than a single page API docs (and they bring in react) and then hexo just bills itself as a blog platform, which given my experience with trying to hack jekyll into being a static site, I'd want to avoid.

[MikeRalphson]

Just a note that the shins Docker image weighs in at 143MB compared to slate at 438MB.

[MasterOdin]

Playing around with this more, I do wonder if in such a move, would the better move to be to just be like gatsby et al and have it be that for most users who are not interested in "peaking under the hood" as it were at the internals to just have it npm install slate and then use slate build or whatever within a given directory. That would certainly make things easier on an end-user.

[MikeRalphson]

I can see a slate init, slate build workflow being quite sleek.

[lord]

A few random thoughts:

• one of the nice things of the template model (instead of a global command) is that there is a lot less customization work needed in Slate proper. if people want custom header dividers, for instance, they can just add it themselves, if people want a different static site generator they can just plop it in. i worry that a single binary would be harder to customize in this way, esp. if for instance a user had multiple slate installations with different customizations — would they have multiple slate binaries sitting around?
• of course, one of the downsides is that upgrades are harder, setup is harder, etc. i think many ppl don't upgrade because the git rebase upstream/master, etc invocations are impossible to remember

Those commands are pretty sleek, though, and could be a serious improvement over what we have now. Perhaps we could get the benefits of both with npm scripts? so npm run build would build, npm run upgrade-slate would fetch the latest Slate from our upstream repo and put it in a git branch, etc. ? And then if people need different functionality, it can be changed directly in their repo without messing around inside a global binary? Happy to support a global command too, just always looking for ways to reduce the total amount of work we're responsible for 😅

[MasterOdin]

Yeah, there would probably be a need to allow people to continue running slate in a similar manner as now, as well as probably a "default configuration" via CLI. This could then be expanded to support plugins and such similar to gatsby, jekyll, etc. I am curious how many people are actually jumping into and really customizing the slate "internals" versus just modifying stuff in sources.

[supsup]

I'm confused, does
https://github.com/Mermade/shins/blob/master/source/layouts/layout.ejs
not give you the same template level design with the ability to call in other code via functions?

--I would assume you would just need to make a mechanism to choose the template vs having just one. perhaps: slate build <template> //none means use default

I've been looking at switching from this from our custom version of slate. Once i get time to walk over shins more I may have a different perspective though!

It would be interesting to get feedback from you guys who use the current version more why the layout.ejs file is not a direct replacement to layouts/.

[MasterOdin]

@supsup My understanding of @lord's comment is on editing the files under https://github.com/slatedocs/slate/tree/master/lib, not just the layout or stylesheets or javascripts directories. Those would probably remain separate from this proposed cli runner. My imaginary super simple cli is that running slate init would give you the contents of the source/ directory. Running slate build would then pull in the lib/ folder and config and such.

[supsup]

would it not just be refactoring those libs to be in javascript, and then attaching the functions to
locals.current_page inside of index.js? Then those methods could be used inside of templates?
you could even do something like current_page.slate.<function> to keep some kind of shoutout back to original slate?

Or is that y'alls point? Sorry just not fully following -- I am not saying I am right.

[MikeRalphson]

Please see the discussion around the Slate v3 Technology Preview.