"Probably" perhaps overstates the case, but it's fair to imply there should be a question about if you need it, and the default answer should not always be yes.

"Probably" perhaps overstates the case, but it's fair to imply there should be a question about if you need it, and the default answer should not always be yes. Here's some heuristics I like: If nearly all of your application's data presentation/processing needs map cleanly to HTTP/REST semantics for the various entities in the system... you probably don't. If your UX involves representing/manipulating the same data in several different ways on the page and this data is going to change, especially in ways that don't map cleanly to HTTP semantics, you should consider that you do need the hip framework. Probability rises depending on how frequently user interactions produce different views of the data. If your data is a headache to represent in HTML, you probably do (also, if you don't have an adequate general automated way to represent your data in HTML from some model description, you will likely either gravitate to solving this problem one way or another, or gravitate to a hip front-end framework). If you ask yourself what problem you're solving with your front-end framework, and the answer either includes the word "modern" or another adjective describing a merit you aren't exactly sure relates to a specific problem to be solved, then you probably can't yet make an informed decision about whether you need that hip web framework. But, OTOH, making uninformed decisions is one way of getting the experience necessary to make informed ones, so...