The first framework I ever learned was Ruby on Rails. I learned it in high school and moving forward, I compared everything else that I learned to Rails. And I often came away distraught and unhappy. Other frameworks just weren't like Rails. I couldn't get a project going easily. How did people work with this? I couldn't figure the patterns out.
Why was it easier for me with Rails? Because Rails is an Opinionated Framework.
Rails has a specific set of guidelines to follow when developing within it: you use MVC. You structure your files and folders in a certain way. You use the routes.rb file for routing. Et cetera.
Later, when I left Rails-world and started working with Javascript-centric frameworks, I realized that other frameworks weren't so opinionated. With package.json, I could include just about anything in my project. That doesn't mean that it would work, but to me, it meant that I had to figure out the structure for myself. And that turned out to be hard.
I then latched on to Angular for this reason as well: its projects had a well-defined structure. The framework clearly had ideas about how you were supposed to write its applications, which files were required, where you put them, and what the output looked like.
Something that I also struggled with was the distinction between customizability and reliability. When it comes to things like customizability, most frameworks can be tweaked to the stars; the strength of their opinion matters because it changes how difficult it might be to make those tweaks.
But a strongly opinionated framework can also be more reliable, because it only takes a few steps to create a working application or project. The more steps you take away from that initial project, the more unstable the application will be. Unless you really know what you're doing, creating an incredibly solid application from the bare minimum might not be the direction you want to take.
Ultimately, the strength of a framework's opinion is something that one should think about when embarking on learning that framework, or working on a project with it.
How comfortable are you with making your own project structure? Will you be able to consider all of the different structural and opinion factors that you have put into your project when bugs and major changes crop up?
If the answer to these questions is no, you might consider a more opinionated framework. It means that developing a project is easier simply because the programmer doesn't need to consistently worry about those things. It means that bug fixing and Stack Overflow questions become easier, because everyone has a shared knowledge of every Rails application, or every Angular application.
If the answer to these questions is yes, then you can work on your own terms. This style works great for small projects, because you don't have to manage the overhead of the extra files and structure. You can put your code just about wherever, and in just about whatever structure you'd like.
Anyways, you can probably find a Webpack module that will hack it back together.
Top comments (7)
I do not see any reliability coming from the structure, it does not affect how your app responds to failures.
A framework structure does not say anything about your project, what business problem solve, what are its functionalities.
Also the fact that frameworks makes you split a feature in 5 folders like: model, controller, view, css and so on is so wrong. Business logic is what makes us go to work and get paid, and also should be the primary element in a project.
But that is just me, and I know Im in minority on this oppinion.
Well, the point is not about business logic here, it's about code in general. In Rails for example when I see PostsController I surely can expect Post model and views in certain places, moreover I know for most part what exactly will contain those files as well as every Rails developer does. A lot of that stuff is reliable and cuts out a lot of bugs and misunderstanding in developing.
That approach lets you focus exactly on coding important stuff including business logic, not on technical parts and trying to run your app.
Basically Rails works out of the box and you can start to write your app right on the go with reliable and well known approach.
With some other frameworks like React for example you can stuck on the "configure the living hell out of this webpack" step.
I would expect that the Post* anything (model, view etc) should be in the Post folder. If I want to modify a feature I shouldn't not modify 10 folders (orthogonal) in the project, only in 1 place.
The same logic would be applied, You will know where is the Post View, Post Model and so on, .. in the Post folder.
It is the exact opposite,
My approach would let you focus on the business logic, and not the framework logic (models folders, views structure etc). You have to know how the framework works, and stick by it.
But hey, all the frameworks are the same in this regard, very wrong in my opinion, and it all started with the misunderstanding of the MVC pattern and Rails.
Oh, this is more of a personal preference I would say. Won't argue with that. That approach may work for someone. I personally wouldn't want to look at a mess inside Post folder where hell know what code you can save. For me Rails way is simpler. I want to edit view - I go to the view folders and look for my REST resource.
Even If I want to extend framework functionality by adding Service Objects for example I just add 'services' folder that continues to work in Rails way among views, models, controllers, etc. folders.
Yes, you have to learn framework for some time and get used to it. That's a point actually. But after that learning time it brings you benefits like sharing code between other Rails developers and well structured and standardized code base.
Hi Evan, I think you make a valid argument which holds true, until a certain scale.
After a certain size you need to start thinking how to better organize your app using patterns and best practices. This has the advantage of slowly decoupling you from the framework itself. It won't be 100% possible of course but it would increase time spent on business logic and probably testability and quality.
In the end this will let your framework do what is supposed to do and your app solve the business requirements.
How to get there? Experience. In the meantime I don't think there's anything inherently wrong in choosing an opinionated framework like Rails. Plenty of companies built successful businesses around it.
Hmmm... that makes me think. If I'm going to use my own way, why to rely on a framework? Wouldn't it be better to glue the parts myself?
IMHO all software development is opinionated. The use of a framework is just a matter of use your own opinion or the opinion of more people.
I'm quite a junior developer, so I welcome feedback or wisdom from the community!