Updated the webpacker comparison

[nevans]

This should be purely a formatting change, with no significant changes to content. Github Flavored Markdown tables are annoying, and blending HTML tables with markdown isn't much better. But I personally find the tables so much easier to read than the list-item's flow of text.

Unfortunately, this does require horizontal scrolling or landscape orientation to be read on phone-sized screens. It's not unusable, but it's not great either. This should be fixable with some CSS (style attributes, because GFM disables style tags). But I want to know if this PR is broadly acceptable first, before making that effort. 🙂

Having the project names repeated at the beginning of each cell felt noisy to me, so I removed them from the start of sentences when the remaining sentence fragments read okay with them (to me, at least). This removes context from the plain-text version that the rendered version retains by using columns. So I added HTML comments so the plain-text markdown is still readable. Additionally, some of the list items placed the jsbundling behavior first, and some placed the webpacker/shakapacker behavior first, so this normalizes that.

[justin808]

Looks good with one comment. @dhh I recommend merging.

[dhh]

Appreciate the work, but don't think this actually clarifies things substantially. This isn't a mathematical comparison.

[nevans]

Fair enough. I find the table version much easier to read and process, but it's a very subjective thing. And, if I understand you correctly, I agree with the desire to avoid a "mathematical comparison".

I have one other idea to consider. One reason I find the current version hard to read is because there's just so much repetition (necessary for the current format). Even worse, most of the repeation is highlighted, which draws the eyes to the redundant bits making them feel even more prominent.

Perhaps we could also delete some of that boilerplate text by using two separate lists: one describing jsbundling-rails, and the other doing the same for shakapacker. The bullet points could roughly line up with each other (first in one list with the first in the other) but in a far less "mathematical" way than the table. It wouldn't feel so much like a scale, weighing each "feature" in "judgement" of one over the other. It would feel more like a celebration of the unique benefits, trade-offs, philosophy of each, individually--providing a contrast without implication of false precision or measurement. E.g:

### `jsbundling-rails`
- A simple integration composed only of installed files and a couple of new rake tasks.
- Can be used with multiple bundlers.
  Currently `esbuild`, `rollup`, and `webpack` are supported out of the box, but anything that can put a bundle into `app/assets/builds` could be configured to work with it.
- Doesn't tie you to specific versions of the JavaScript packages you use for bundling, transpiling, etc.
- _etc_
- _etc_
- _etc_

### `webpacker`/`shakapacker`
- Provides view helpers and a customizable webpack config that include support for the most important advanced features of webpack: code splitting and HMR.
  You don't need to use the `webpacker` webpack config. You could choose only to use the view helper portion of `webpacker`/`shakapacker`.
- Originally built specifically to integrate with `webpack`.  That allowed it to provide support for HMR and code splitting.
  `shakapacker` also supports `SWC` and `esbuild` _(experimental as of October 2022)_ with integrations into some of their advanced features.
- Releases are also not tied to a specific major version of `webpack`, `babel`, etc. as these are handled because `webpacker`/`shakapacker` specifies these as _peer dependencies_.
- _etc_
- _etc_
- _etc_

@dhh what do you think? Better? Worse? Indifferent? I think that would handle my readability concern almost as well as the table. Does it handle your "mathematical comparison" concern? It's certainly easier to read/write the raw markdown this way, and it will look better on small screens.

Also, I personally yearn for the day when nearly everything can be handled simply via import maps and there is almost no need for javascript bundling at all... So, at some future date, we might simply add another list or two for the importmap-rails/propshaft approach(es)? 🙂

[dhh]

I'd be fine to see it listed with less duplication, as you suggest. But also, yeah, I think there's also diminishing returns to how much continued refinement of this page will bring. Rails 7 has been out for quite a while, and Webpacker just isn't part of that default equation any more.