Hacker News Reader

Comment by lucidone | Hacker News Reader

Are you building a website? The practices espoused by the author will be ideal.

Are you building a web app? Will you have a mobile client alongside your web app? Using a javascript framework for your client(s) and decoupling your data from it's presentation will be a fruitful investment. All of these frameworks and their associated happened for reasons, and they didn't involve traditional MVC being good enough for everything.

As an aside, I find this viewpoint prevalent in the Rails community and the Rails job I had (so, caveat, I'm coloured by my personal experience). It also lead to a culture of staunch refusal to learn or do anything new in that job, and the quality of the product suffered. It consequently led to me leaving the job, and being much happier for it.

View on HN

> It also lead to a culture of staunch refusal to learn or do anything new in that job

I find one of the most difficult aspects of software is the very powerful "local minima" of effective (but not optimal) techniques combined with entrenched knowledge. People are so incredibly biased towards what they know well, and that bias is backed by objective evidence: when they do it X-way they are objectively faster AND better, and what's more, X-way has many objective benefits. This is the local minima in a vast multidimensional space of the benefits and tradeoffs of different possible technical approaches. The multidimensional problem of overall comparing X-way with Y-way is nearly impossible to accomplish, so we nearly always fall back to our intuition (aka bias) which nearly always leads us back to what we already know. And consequently most organisations are stuck in some version of a local minima that is very hard to escape, but ultimately represents a big disadvantage over time. But the question of when is the right time to move out of that minima - and incur the expense of navigating the hills between where you are now and the better minima - is really hard to solve.

> but ultimately represents a big disadvantage over time.

That presumes that Y-way is inherently advantageous to X-way. There's still plenty of sites that can and are market leaders using an out-of-flavor framework like rails/spring mvc/.net. New frameworks do not necessarily supersede old ones - they are usually a response to new use cases that have cropped up. These use cases may or may not be important to your business.

If new developers start at Y-way, we can assume they'll add more advantages to Y-way like improved tooling etc..., so maybe Y-way will eventually surpass the X-way.

In tech, it's not what one particular developer thinks but the consensus among the contributors which decides which one out of X or Y will end up having more benefits.

> In tech, it's not what one particular developer thinks but the consensus among the contributors which decides which one out of X or Y will end up having more benefits.

It's always the people using the tools that decide whether X or Y will have more benefit. You don't easily get contributors without first having users. Or did I misunderstand your point of view?

I totally agree, but I thought it was funny that you invoked the concept of local minima - I have only ever heard that concept in terms of local maxima, ie locally-but-perhaps-not-globally maximal productivity, comfort zone, etc. I assume you are referring to a locally/globally minimal resistance, time taken, or some such?

Anyway I just thought it interesting that you might make valid reference to a very useful concept I've heard and used many times, and yet in your expression the "polarity", as such, is totally inverted! And yet I understood you anyway. A computer would be totally confused.

Local minima come from optimization problems as you encounter for example in Machine Learning. You usually want to minimize some error function (e.g. misclassified objects). Unless you take great care these functions are riddled with local minima where naive optimization gets stuck.

Ah I see - of course. Should have thought of that.

For comparison, I believe my usage arises from evolutionary fitness, where one might discuss local maxima on a fitness landscape. The challenge is perhaps much the same as in ML, with one strategy being to introduce random mutations in order to escape the same kind of trap.

Heh, it is interesting how people can have inverted mental models of the same thing.

Actually, my preference for minima vs maxima is because minima translate readily to the natural world where you can imagine balls rolling down surfaces or water running down hills and getting stuck in local "minima" even though there is a lower energy state available to them. It makes a much easier mental model for me than thinking about maxima.

This is an interesting point - my limited experience has been that with successive generations of hires, each attempts to update the practices and tools used to build the application. This leads to pockets of properly functioning Y-way code and many layers of inefficient and difficult to support bridging between X-way and Y-way.

Overall, in each one of these scenarios my gut is that it would have been more efficient to attempt to optimize X-way, rather than layer Y-way on top. It always seems the goal is to incrementally migrate from X-way to Y-way, except we never seem to quite finish and frontend moves quickly enough that Z-way starts to look enticing midway through the painful migration.

I think it is extremely important to differentiate between the benefits of building a fresh application Y-way initially, and the (often extremely painful) friction of migrating from X-way to Y-way. One great example of this is the recent AirBnB departure from React Native. It seems like the majority of their complaint with the framework was that it was difficult to integrate with the rest of their app - had they built from the ground up in React Native, they likely would not have experienced such integration challenges.

> decoupling your data from it's presentation will be a fruitful investment

Very good point. You'll be building an API anyway if you want a mobile app. However, you can probably get away with a much smaller one, for only the most interactive parts of the app - I've gotten a lot of mileage out of simply embedding web pages for fiddly things like settings pages and other complex forms in mobile apps, saving the native API-driven section for only when needed. The hybrid approach can actually save on mobile implementation time in that way, too.

> a culture of staunch refusal to learn or do anything new in that job

Sigh. I have encountered this too. But I think it's mainly a person-by-person, or perhaps team culture, issue, coupled with the fact that Rails has been around a long time. I've been using Rails since it's in beta and am very happy to use React et al when called for.

Sadly, when (if?) React gets to 10 years old, you're going to see the same thing on that side of the fence! There's a certain type of person who's always going to be grumpy about learning something new.

> There's a certain type of person who's always going to be grumpy about learning something new.

I resemble that remark :). But I hear you, sometimes you have to invest to figure out if something is any good, and one way to do so is to build something real with it.

However there's danger on the other side too--a company with 5 different apps in 5 different frameworks or languages that all have to be supported by a small team of developers. That can't leverage deployment or performance tuning knowledge across apps. Where work is siloed because "Dev X doesn't know golang and Dev Y doesn't know rails". And where you can't rewrite the app because the business leaders wonder what they'd get.

Reply on news.ycombinator.com