3 ms·

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 ap

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.

sho 8y ago
> 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.
- mooreds 8y ago
  > 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.
zmmmmm 8y ago
> 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.
- debaserab2 8y ago
  > 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.
  - stealthmodeclan 8y ago
    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.
    - debaserab2 8y ago
      > 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?

sho 8y ago

> 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.

mooreds 8y ago
> 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.

zmmmmm 8y ago

> 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.

debaserab2 8y ago
> 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.
- stealthmodeclan 8y ago
  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.
  - debaserab2 8y ago
    > 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?