Hacker News Reader

Comment by jbob2000 | Hacker News Reader

jbob2000

Wow! A single developer working on small websites doesn't need MVC? What a revelation! I bet he doesn't have any pesky problems, such as; working in large teams, long term support, developer turn over, documentation, changing requirements, deadlines, scaling, etc. etc. Oh, but the rendered HTML looks nice!

MVC frameworks took off because they allowed more than one person to reason about an application. I can hire an Angular developer and expect them to have a fair understanding of my application on day 1. If I'm new to a React shop, I can read tons of documentation online, without pestering my new coworkers. My Product Management team likes to change stuff on the fly, so I can use Knockout to build small, independent components which I can piece together like lego.

I don't know why this post irked me so much, but it did.

View on HN

Completely understand where you're coming from. Frameworks exist for a reason: collaboration.

Also, what happens when you inevitably change jobs 3 years later? "I have 3 years experience with Bob's folder structure." Yeah, that's time in the trash where yes, you learned something, but no, you can't really show value to potential companies.

: organization

Quite often the co-worker you're collaborating with is you in 6 months.

Yeah. The skills aspect is important. That bespoke CMS/MVC product that you spent years working with... it's kind of worthless. Employers and recruiters have a list of requirements to tick before narrowing down the candidates.

Once you get to the interview and they want to look at the code from a project, then sure, it will help a lot - assuming you created it.

Frameworks exist for that reason. I don't think that means every framework has to be MVC.

Yep. Sometimes it doesn't always make sense. If your models involve pulling data from multiple different, potentially expensive sources or processes, but your user's request only requires knowing a subset of those results or a subset of the model's properties, you may not want to populate every property of the model.

One reason I like Flask over Django: You can do MVC if you want to, but aren't forced to.

Although there are arguments against MVC I don't see how your example is against MVC.

Let's say I have a model called restaurant. Getting restaurant.name, restaurant.type, restaurant.phone are free. Getting restaurant.menu involves spending $X to get it from an paid API. Getting restaurant.photos involves counting against some social network API's rate limits.

Fully populating a restaurant model and sending it along to a view is costly. A user's requested parameters may not have needed the menu, for example.

That's just scratching the surface of the problem. Okay, let's say I create a model called restaurant that's actually a Python class, where menu and photos are fetched only when called. That's fine and dandy, but now, what if the user's request actually needs to render 10 menus, and it so happens that the API cost of getting N menus doesn't linearly scale? For example, what if I could fetch all those menus in 1 API call and spend only $X? Now all of a sudden our abstracted Python class is terrible at minimizing costs, because it will make a separate call for each restaurant object.

Now add in silly time-based rate limits. Photos API allows upto an average of 10 requests/second in a continuously-moving time window of 5 minutes, while menus API allows 50K requests per day, resetting midnight in Pacific time for American restaurants, and another menus API allows 20K requests per day, resetting midnight in Chinese time for restaurants in China. However, you have nearly unlimited requests for the American menus API if the user has used some login method that gives you a user-specific access token instead your application access token. Oh, and the API that provides Chinese menus doesn't support asking for multiple menus in one call. Also, since you have access limits, you choose to not provide menus for less important anonymous user requests, based on some importance criteria, in order to best serve the users that are most likely to stick. You now have a real mess of a framework.

In general, MVC breaks very easily for practical purposes when you're not in charge of the database, and the people owning the data have business motives and arbitrary access restrictions.

If you own all the data and it's in a nice little MySQL database on your own servers, then sure, slap an ORM on it and go MVC as far as you can, I totally agree.

You're complaining about ORMs, not MVC. If you have a use-case for a limited restaurant model just create another class for that use-case, probably with some code sharing. Specialize and all that. Break the abstraction when needed by a real-world requirement, it's not a problem.

How is it the MVC framework's fault that aggregating data from third parties is expensive?

Lazy evaluation will help to some degree, as will caching data locally once you've retrieved it.

Extending your ORM to invoke third party pay-per-view APIs is obviously the wrong way to solve this problem. That does not mean that MVC or ORM are obviously the wrong way to solve this problem.

MVC will help you with the stuff that it is suited to, as will ORM. Neither are suited to optimising usage of expensive pay-per-view APIs. You need to build the API interaction part separately, and arrange for the MVC side of things to work with thst API-using-API.

Off the cuff, why not have a batching task that takes requests from the last fraction of a second and sends them off to each provider? How long can you stretch that fraction of a second without upsetting you customers? Are they willing to wait three seconds? If you get a dozen requests per minute, three seconds might halve your API bills.

As you said, MVC breaks when you do not control the data. So your job is to get the data into a form and place that you control.

That's a lovely explanation of why mediocre ORMs can cause more problems than they solve. And it's well known that Django's ORM is very mediocre, and sadly it's so tightly coupled to the framerwork that you can't just drop in a better one.

...but what does this have to do with MVC? You're entire argument comes down to "sometimes you need to have some smart models to deal with external APIs". Well...yeah?

I guess if you're going to argue against MVC, you have to figure out what MVC means first. The original MVC isn't the same as many of the popular MVCs we have today:

https://github.com/ciscoheat/mithril-hx/wiki/Rediscovering-M... https://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf

Are we including Django in MVC now? The term has become completely vague then.

Django's web framework is URL routing plus views, which may use the template engine if they want to. There is also an ORM which is separate from the Web framework and other tools.

Well, from wikipedia:

> Django (/ˈdʒæŋɡoʊ/ jang-goh)[4] is a free and open source web application framework, written in Python, which follows the model–view–controller (MVC) architectural pattern.[5][6]

And realistically it has models, views, and controllers; it's at least as "MVC" as most frameworks we label that, and more than many. If Django isn't MVC, what is?

Smalltalk was. Django's FAQ says that if you want it to fit an acronym, maybe use "MTV" (model, template, view).

I found this to be more insightful: https://news.ycombinator.com/item?id=10730047

Being that, the original conception of MVC was for the user's mental model, not the programmer's mental model.

MVC frameworks took off because of cargo culting. Almost nobody who says "MVC" actually knows where MVC came from or why it was conceived.

There are many reasonable ways to split up responsibilities. I know this because many different usable frameworks split up responsibilities differently (although many of them all call themselves "MVC" regardless of the differences).

I actually love that he started the post talking about WebObjects. Probably the only relatively mainstream MVC framework that was designed by people who actually understood what MVC is supposed to do/be, and why.

Reply on news.ycombinator.com