Differences between segmentio/ware & unifiedsjs/unified

[webketje]

Hi there, I'm the maintainer of Metalsmith.js, an SSG which uses Ware.js for its plugins. Ware.js is very, very similar to unified at the surface. Whilst browsing the Ware.js history, I noticed @wooorm was a frequent contributor and wondered: was one the continuation of the other, and why not continue contributing to the first? Is unified more specialized in its use cases internally (AST's) or is that just the use case most worked on?

This is important for me as I consider incorporating a fork of Ware.js in the metalsmith codebase, but if there is an equivalent or better, externally maintained option, that would be better.

AFAICS both are operating-environment agnostic (browser/Node), but the use call in unified supports options as a second parameter, allowing it to centrally do options processing, whereas Ware.js will interpret a second param as another plugin to use. What other important distinctions/ considerations are there?

For illustration of the similarity:

// ware.js through Metalsmith
await Metalsmith(__dirname)
  .metadata({ hostname: "https://example.com/" })
  .use(collections({  posts: 'posts/*.md' }))
  .use(markdown())
  .use(permalinks()) 
  .use(layouts({  transform: 'nunjucks', pattern: '**/*.html' }))
  .process()

// unified
await unified()
  .data('hostname', 'https://example.com/')
  .use(remarkParse)
  .use(remarkPresetLintMarkdownStyleGuide)
  .use(remarkRetext, unified().use(retextEnglish).use(retextEquality))
  .use(remarkRehype)
  .use(rehypeStringify)
  .process(input)

[JounQin]

Segment has paused maintenance on this project, but may return it to an active status in the future. Issues and pull requests from external contributors are not being considered, although internal contributions may appear from time to time. The project remains available under its open source license for anyone to use.

ware
1.3.0 • Public • Published 10 years ago

Isn't ware abandoned for a long time?

[webketje]

Yes, but it is the backbone of the middleware pipeline in metalsmith.js and I'm only getting to this now. 🫤

[ChristianMurphy]

This is important for me as I consider incorporating a fork of Ware.js in the metalsmith codebase, but if there is an equivalent or better, externally maintained option, that would be better.

Unified has a rewrite that has been stable for a while https://github.com/wooorm/trough

Which is fully typescript checked (using jsdoc mode), has full support for ESM, come complete and modern testing.

[ChristianMurphy]

And if your flow uses https://github.com/syntax-tree/unist compatible objects.
It could be useful to directly use the abstraction one layer up https://github.com/unifiedjs/unified to leverage all of the utilities that already exist in the unified ecosystem https://github.com/syntax-tree

[ChristianMurphy]

AFAICS both are operating-environment agnostic (browser/Node), but the use call in unified supports options as a second parameter, allowing it to centrally do options processing, whereas Ware.js will interpret a second param as another plugin to use. What other important distinctions/ considerations are there?

Unified is more focused (at a types level) on handling syntax trees. (https://github.com/syntax-tree/unist)
And is optimized to process one file at a time.

https://github.com/wooorm/trough is more generic for creating any kind of plugin system.

[webketje]

Hey thanks for the pointer to trough, this looks promising for my use case. I'll post results of my comparison when I get to it (this may be a while). You said

Unified has a rewrite that has been stable for a while https://github.com/wooorm/trough

You mean future unified will use it as a dependency, right, not be fully replaced by it?
trough's scope looks lower-level, it relates to unified like warejs relates to metalsmith, no?
Or do you/wooorm think the rest of the API Surface (data, parse, process) can actually be 'plugin-ized'?

[ChristianMurphy]

You mean future unified will use it as a dependency, right, not be fully replaced by it?

Already in there and has been for a while

unified/package.json

Line 18 in 45d8fa5

"trough": "^2.0.0",

trough's scope looks lower-level, it relates to unified like warejs relates to metalsmith, no?

Yes it is lower level

think the rest of the API Surface (data, parse, process) can actually be 'plugin-ized'?

More this.
Unified itself is a wrapper adding new plug-able interfaces on trough
https://github.com/unifiedjs/unified/blob/main/lib/index.js

There's not much js code to wrap trough.
Though making the plugin system strongly typed is more nuanced and complex.

[webketje]

think the rest of the API Surface (data, parse, process) can actually be 'plugin-ized'?

I've been going this direction with metalsmith too (eg would allow the read/write(file) to be plugin-ized and the core to become FS-agnostic), just don't have enough spare time to get to a v3.

Thank you for your time & thoughts, it gets lonely out there as a open-source dev looking for a second opinion.

[wooorm]

The readme of trough shows the exact difference: “trough is like ware with less sugar. Middleware functions can also change the input of the next.” It’s also more modern: promise support.
Comparing the code shows many differences.
This is all based on 10+ years of heavy use in unified, it’s been tested a lot in the wild.