It all depends on what you are prototyping, to be honest. I have a great example, I am working on a blockchain based web application and to validate the concept it needed to have these features for people to use it and provide feedback:
- User authentication (login, register, social login)
- Basic views; list of items, ability to add new items
- A multi-tiered submission screen (multi-faceted taxonomies, a map component, dropdowns, checkboxes, inputs, autocomplete, date picker)
- A responsive grid system
- Offline support
Authentication was handled by Firebase. Basic views were easy to create thanks to Aurelia’s convention approach and CLI scaffolding. The submission screen used as many community plugins and third-party libraries as possible.
Because Aurelia is so unopinionated and not as “frameworky” as other choices, you can use any third-party Npm module with it. I think the biggest mistake people like @obedm503 make is assuming you need to use Aurelia specific plugins when you don’t.
There are a few of the most common plugins out there for grids, Google Maps, sortable data grids and so on for Aurelia. There is definitely no shortage of plugins as well as bridges for Bootstrap, Material design, etc.
That blockchain concept took me one solid day from start (Aurelia CLI using Webpack and TypeScript) through to something usable people could get their hands on. I typed as little as possible and let the CLI and libraries do the heavy lifting.
Other libraries like React require you think harder, and I disagree that React is a good choice for prototyping. The whole point of a prototype is that it should be built as quickly as possible, you need conventions over configuration to do something like that.