My initial gut reaction: Is this really a responsibility a web framework should have? It's a super opinionated frontend concern.
On the other hand, you could remove it after the fact, and the kind of Rails apps you'd be spinning up quickly would likely be internal apps and the such. The canonical "simple crud app". I feel like in this context it's logical to adopt Rails' opinionated nature and run with it.
In the demo when he drags and drops an image into the editor, active storage gets going on the back end uploading and storing the image and creating previews. Looking at it that way it seems that the front end and back ends are heavily tied together.
Rails is very opinionated, it's what so many people like about it. It's also configurable, I'm sure there'll be a --skip-action-text option for rails new when it's realeased.
What do you think of Trix too, Ben? I believe you've been working on a new editor for DEV, did you/would you consider something like Trix/Action Text?
While I do love Rails this feels a bit like when Microsoft ships IE/Edge with every OS and makes it hard to switch. There are many people working on great rich text editor and I'm not sold on the value on shipping this by default in Rails 6.
Maybe I'm missing something but the part of Rails I loved where the abstractions where you could pick your DB, pick your storage, pick your cache, etc. This seems quite different in that regard.
I played around with Trix when it first came out and like it. The new editor will also be markdown, but if we offer a WYSIWYG in the future, we'll definitely look at it as an option.
Potentially would use it sooner for admin tools.
Sorry, but I don't think "You need a text editor written in CoffeeScript" qualifies as an opinion for a general purpose web framework. I'd rather see them spending time on adding missing features to ActiveStorage (i.e. proper CDN support, see this discussion on the issue).
I have to think the people focused on ActiveStorage features aren't being bottlenecked by work like this. I that the feature is questionable but I can't imagine it was a huge burden on the rest of Rails' productivity.
Maybe. Though ActiveStorage was extracted from Basecamp, the maintainer has not been very open to user feedback/requests so far and now they add something that ties in with ActiveStorage, which may mean they are even less likely to change it in ways that don't exactly match their use case. Anyway, we're moving away from ActiveStorage for our projects and use Shrine instead.
I have similar feelings. Isn't this out of the scope to include in a framework? Like Phil and you mention though, it will probably be configurable enough to be configured out of an app easily.
The video doesn't do a great job of explaining everything that's going on. It's a bit more than just bundling Trix into Rails core. It seems like it's doing a lot of processing of the content fed into it.
I've done quite a lot of custom CMS work with Rails and it's interesting to see their approach. It's not too far off from stuff I've done before, which I'll take as validation :)
There is some Trix specific code for attachments, but I don't see why you couldn't swap in some of your own handlers if you wanted. Just a few months ago I wrote some JS plugins to hook CKEditor5 file uploads to ActiveStorage, along with a hacky Nokogiri parser to associate the attachments. I would have loved to be able to just hook into something like this.
A vast majority of web apps deal with rich content in some fashion. In that light, I think having a framework for storing/parsing/etc with it is quite justifiable, especially at the stage Rails is at. That it comes with a default UI that handles many use cases is really just icing.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.