Because in my experience the "out-of-the-box" solutions always break down the more you want to customise them.

Now I rather prefer solutions that have customisation in mind from start, so it's always easy to switch things.

I remember when that wave hit the Ruby/Python space, with things like Pyramid/Pylons. These days that seems to have gone the way of the dodo, with the big monoliths still being around and then some minimal HTTP decorators like Sinatra/Flask/Node. Problem is that the middle ground would require a level of modularity that we still haven't reached, despite all the talk of "software ICs" that came around with early OOP.

I predict that's how we're going to end up in a few years again. Some big monoliths (whatever react is morphing into currently, plus Angular and as the world is a cruel mistress, ExtJS), plus a plethora of DOM wrappers and view libraries.

And 72 build systems.

You know that pyramid powers some of the most important infrastructure for python? Like new version of PYPI (https://pypi.org/)? And lots of big organizations use it - like Mozilla or NASA, sites like Reddit still use pylons.

IF you think it went the way of the dodo, I'd suggest doing a bit of better research before predicting the future :D Because IMO you are seriously off here.

I'm talking about the trend of build-your-own frameworks, not the software itself. Heck, there are enough sites out there still using Zope, MASON and Aolserver.

Pyramid is feature complete as a framework in my opinion - with defaults requires less thinking vs. lets say flask - the resulting applications will be more elegant and better organized (partly because it doesn't use globals eveywhere). The glue is quite good nowdays.

I really don't, and few do, hence the popularity of create-react-app and next.js

So you're still working within a framework, then.

But when the app grows, you can customize it instead of forking ember to get around it's opinions, something I have had to do in production apps.

I've been working full time on Ember stuff for a long time now, and I can not imagine a single reason to ever fork Ember. I've used different programming languages (CoffeeScript, don't make fun), templating languages (Emblem.js, don't ask), built and served it with Rails, without rails (Ember-CLI was a godsend), and hacked at it in a million different ways. All this was supported by API's or tooling within Ember (even when it was a bad idea, which it often was).

I would really like to know what prompted you to fork Ember.

The first time it was for a sub-route that could be brought up in any other route (to show a little search pane in the app). We were told by the community just "not to do that" but it was in our spec and there wasn't a way to load the same countroller for multiple routes. The second time was more short lived, but it was to allow asynchronous modules to be loaded after the main app. There were no community solutions to this at the time. The last time wasn't really forking ember but we underwent a painful process of remaking most of our views in vanilla JavaScript for performance on mobile, which has gotten completely out of hand with all the two way bindings of pre-glimmer ember. It felt like we were fighting the framework the whole time.

If you go off the rails, it is extremely painful. I haven't looked at Ember in a while, because of my experiences, so ymmv. It could all be completely different now.

When and why did you fork Ember to get around it's opinions? I've been developing with Ember for 5 years now, and the only time I ever had to modify the source was with Ember Data pre-1.0.0, when it wasn't solidified at all. The concepts behind the framework are really simple, and literally everything is configurable.