7 ms·

Moving on from Rails sounds great until you try to build a serious web app with one of the alternatives. While I think that many of the architectural criticisms

Moving on from Rails sounds great until you try to build a serious web app with one of the alternatives. While I think that many of the architectural criticisms are valid, Rails demonstrates the primacy of ecosystem and strong conventions over language design and cs theory. 'Tomorrow's' languages and frameworks would do well to take heed. Winning this war has as much to do with culture and marketing as algorithms and data structures. Clojure, for example, is a much stronger programming language than Ruby on paper, but for a straightforward web app, you'll likely spend at least twice as long to get something working--and while it will be based on better engineering principles, it will also take new engineers much longer to grok since it doesn't follow any universal set of conventions. With Rails, you end up in the weeds in the long run, but the alternatives put you in the weeds right off the bat (with the promise of eventual salvation). The reality of most product development (ymmv) is that the former is highly preferable to the latter.

deleted 11y ago
[deleted]
raverbashing 11y ago
> With Rails, you end up in the weeds in the long run, but the alternatives put you in the weeds right off the bat (with the promise of eventual salvation). The reality of most product development (ymmv) is that the former is highly preferable to the latter. You're absolutely right. And yes, Rails has quirks and I agree with most of the criticism of the other article Option 1: Twitter is built on RoR, have growing pains and lots of whales when it has an established product (when it gets the investors and the money to invest in a rebuild) Option 2: Twitter is built on Clojure, product takes more time, iteration gets slower, hiring is slower, some other competitor gets ahead. Ooops
dcrall 11y ago
I agree that Rails' strong opinions are still a strength. I like Clojure a lot, but for someone new to the language trying to get a Clojure web app started is like pulling teeth. Elixir and Phoenix, with their connections to the Ruby community, really get this, and I think they provide a much better introductory experience.
- akmiller 11y ago
  I've been doing Clojure for the better part of 3 years now and I'm not sure I get why people feel doing web development in Clojure is hard. Our first foray in Clojure was/is an API to manage our users that was built by 2 developers who were new to the language and has been running largely unmodified since being released. I actually believe the opposite. Jumping into and doing Clojure web development is extremely simple at the core. The issue with frameworks like Rails (and I'm not against Rails as I have used it on multiple successful projects and still think it's great) is that you get so much for free and don't have to understand how all the pieces fit and work together (at least initially). Soon enough you have to have more knowledge of that and that's were the complexity comes in.
  - Bluestrike2 11y ago
    Is it fair to ding Rails for that, though? Regardless of what framework you're working with, eventually you're going to be peeking under the hood. Of either the framework, the language, or both. Whether that's front-loaded or not, it's still there. So the question becomes which framework eases you into the deep end of the pool, rather than which is the least complex. I've seen plenty of Rails apps that could have written better initially. But I haven't really seen any where it was impossible to refactor and improve them as a developer learns more.
    - akmiller 11y ago
      I'm not dinging Rails for that. Like I said I've done some successful applications with Rails. The difference I'd say between Clojure is you learn those from the bottom up, whereas with Rails you learn from the top down. Either way, you are going to have to learn them!
      - wyaeld 11y ago
        Where exactly does it say that you can't start by actually learning how Rails works, before you build things with it? I think the biases of people who were experienced big system developers before they moved to Rails, are very different from those who started with it, potentially not understanding web app development very well, and then produced something challenging to maintain
busterarm 11y ago
It's all about how you prioritize the problems you need to solve. At my current job we primarily use Wordpress. Why Wordpress? Because we have a large and non-technical content team, 260+ websites and several tens of thousands of pages of content that need to go up quickly. We're just 4 developers - about 1 for every 8 content & marketing people we have. We spend very little of our time on frontend. Tell me that you're going to get that kind of leverage with another tool. Wordpress is just about the last thing that you would pick as a developer or ops person to base your tech stack, but in our case it is the right choice. Aside: Coming from Rails and having spent six months deep in Wordpress core, it's actually kind of awesome. Seemingly every problem is solvable.
- askyourmother 11y ago
  WordPress is a pretty crazy codebase, yet, it seems sane compared to Rails. Interesting that WordPress as a service are moving to a node.js backend from PHP - even they chase shiny too
  - busterarm 11y ago
    Do you know of any decent (modern stack) WPaaS besides Pantheon?
  - btdiehr 11y ago
    Is it not an advantage for average users to be able to do both the front end and back end knowing only a single language?
    - askyourmother 11y ago
      The same advantage as just using a screwdriver to handle nails and screws? No. Right tool on the server (hint: it's not JS nor node), right tool on the client (JS if needs must)
- kennell 11y ago
  Comparing Rails and Wordpress seems like apples and oranges to me. Rails is a framework that lets you build anything web-app-ish, while Wordpress has its well defined, rather limited use cases. If it works for you, great, but the scenarios are different.
lobster_johnson 11y ago
These things depends a lot on how you build an app, too. All our webapps these days are thin React apps (with server-side rendering) that don't have a dedicated backend. Instead, they talk to a group of generic microservices. We've been doing this style of development since around 2010. With this methodology, a lot of Rails' ergonomic concerns (templating, the split between rendering HTML vs. data, etc.) just melt away. Front-ends become formally isolated clients of microservices, forcing you to engineer better internal APIs and get things like security correct from the start.
- throwanem 11y ago
  Not OP, but my guess is that would count as "in the weeds right off the bat"; the impression I get is that a lot of Rails's value proposition revolves around being able to start using it without actually needing to know or understand very much. (Which is not a bad thing, exactly! Its power as a rapid prototyping tool comes in large part from this trait. Unfortunately, so does its strong tendency to produce unmaintainable code.)
  - lobster_johnson 11y ago
    Each approach comes with its benefits and challenges. I would never suggest anyone jump right to a microservice architecture if they haven't come to appreciate the problems posed by a Rails-type design. One aspect I keep hammering on about with regard to microservices is reusability. If you're developing just one user-facing product, nevermind. But if you have a bunch of products, reusability across microservices is a huge boon compared to monoliths. Reuse all your job processing, notifications, data storage, login/auth/group/role/permission management, identity verification, image processing, NLP processing, feed processing, etc. etc. etc. across your entire stack. With monoliths, the only other option is to build these as libraries, and unless you want to write bindings or write code more than once, you're now chaining yourself to a specific language.
- colinramsay 11y ago
  I'd love to know more about your webapp methodology. It sounds wonderful.
geebee 11y ago
I think this is a strong point. If rails is yesterday's technology, then what is today's? To be clear, by no means am I trying to claim that Rails is the clear winner over other technology choices, or that a good answer to this question needs to be one single, unambiguous answer. I've learned a lot about other possibilities. Node of course, but it's still relatively new, and you need to prefer (or at least be ok with) javascript instead of ruby. Pheonix and Elixir sound promising. My own personal prediction (probably better to call it a suspicion, since I'm wary of predictions) is that an "isometric" approach like Volt will become more common (the approach, not necessarily that specific implementation, though it is of course a possibility as well). But for now? Some will do this, but I wouldn't use Volt, though that has more to do with the requirements of my job than anything wrong with Volt (there really is no need for me to go so bleeding edge in what I do). I personally am hesitant to invest too much in Javascript, even on the client side, since there is still a great deal of churn. Again, this may simply not be a possibility for everyone, it depends on the kind of app you're writing. So it's not so much that I don't see good, perhaps preferable alternatives to Rails. I just don't see a sufficiently unambiguous case that Rails is out of date to be calling it yesterday's technology - yet. And lastly, as I mentioned in he other thread about this, when Rails isn't working for me, either because of code clarity or performance, I tend to go to older, more established technologies, not newer ones. For very elaborate sql, I use… sql, not contortions in ActiveRecord that I think are much harder to read and understand than a sql statement. I also often go to raw sql for performance reasons (mass inserts, queries that result in very large result sets that need to be optimized for speed). Unix, networking, specialized languages and environments for scientific computing, machine learning, stats, or other specialized tasks. That tends to be where I go.
- drumdance 10y ago
  I came to Node after four years on Rails and about 10 years of PHP before that. It definitely felt like a step back from Rails, but that's partly because Node wasn't meant just to be a web framework. I've gotten pretty comfortable with it, but I feel like the original decision to use it (which predates my joining the company) was primarily driven by how shiny and cool it is. The vast majority of what we do is standard CRUD stuff. On a personal level I've enjoyed learning it, and from a career perspective it's nice to have it on my CV, but had I been on board when the original decision was made I would definitely have chosen Rails. (Plus they also chose to use MySQL for no good reason. We've managed with it just fine, but in literally the last three weeks we ran into some limitations that would not be a problem in Postgres. The CEO, not being technical, doesn't quite understand why changing the database midstream is not something you do without really compelling reasons.)
noam87 11y ago
Elixir/Phoenix gets this right. Working on a side project right now and so far it's a very enjoyable experience. I find the abstractions much more intuitive. The framework as a whole is just as "magical" for fast prototyping, but it's composed of much simpler individual modules that are easy to wrap one's head around. It's surprising how mature the whole ecosystem feels considering it's still quite niche. It helps to have decades of battle-tested Erlang libraries at your disposal.
- askyourmother 11y ago
  Wait till hex is filled with crap like gems are today. The Rails programmers are coming to elixir as it had already been called the new Rails, and they will follow the pragprog book to it the new promised land. If you enjoyed early adopter status in elixir phoenix, wait till it is Rails mk 2. It will suck big time.
  - szx 11y ago
    You have a point there, but I do wonder if this is inevitable, or if (1) the language does make a difference in that regard and (2) the community can help steer newcomers in the right direction and establish best practices, standards of quality, etc. etc. (cf. Clojure?) As a side note, I feel like this has happened to some degree to the React ecosystem. I can no longer count on packages to be of decent quality.
gshulegaard 11y ago
Just curious, but what do you consider a serious web app? I have had great success with Python across a variety of different applications. A lot of people seem to end up comparing/picking between Python and Ruby so I am curious for my own knowledge what type of serious application does Ruby make easy where Python makes difficult? I also think the overall gravitation towards microservice architecture generally makes language choice less important on the whole...but that's just me.
askyourmother 11y ago
So django gets it right. Laravel and symfony seem to get it right, yesod for Haskell gets it right - basically Rails is pretty awful, always was, but the crowd got caught up in five minute blogs and shiny magic to question the questionable insecure code, the rather suspect architecture.
- dasil003 11y ago
  Seems to me you don't actually remember what the web framework landscape was like in 2004.
- goldbrick 11y ago
  Can you be more specific? What do Django, Laravel, or Symfony do right that Rails does so awfully? I have had to use Symfony and everything about it was an inferior/weird Rails.
freyr 11y ago
> for a straightforward web app, you'll likely spend at least twice as long to get something working For a straightforward web app, Rails is probably a fine fit. For something less straightforward, it can shackle you down the road. The alternatives are an up-front investment that can save you time and effort down the road, but also give you enough leeway to make mistakes.
cag_ii 11y ago
Why compare Rails with Clojure (a framework vs. a language)? I think if you more fairly compare Rails with Django, Flask, Laravel, etc. you might find the differences aren't so great.
tetha 11y ago
> With Rails, you end up in the weeds in the long run, but the alternatives put you in the weeds right off the bat (with the promise of eventual salvation). The reality of most product development (ymmv) is that the former is highly preferable to the latter. As one of our product managers put it: Often, you want something you can sell well fast enough to buy time to make it good. Overall, in this tool/framework/language debate, I'm growing more and more convinced two things matter the most: - Pick something the weakest 40% of your team are comfortable using. Especially with support, I'd trust myself to figure out enough of Elixir/React/Whatever to be decently productive within a week or two on the go. But that's the thing - that's why I advocate to pick something the weaker team members are fine with. They will struggle, not the stronger team members. - Smash problems with standard solutions. Don't be smart. Pick the right tools, throw hardware at them. A decent combination of load balancing, language+ORM, an SQL persistence layer and possibly a message queue can handle _a lot_ of traffic. And it's easy to hire for and to get new people on board because there are no smart things going on. Note that the language and web framework are not part of this consideration at all. My approach would prefer more established frameworks like rails or something in java though.
pdkl95 11y ago
> (ymmv) This is probably the most important to remember. Every problem is different. Every situation is different. Good engineering isn't just the implementation, but also the design process. For most problems, there is rarely a single "correct" solution. This means decisions about which tools to use should should include maintenance costs, familiarity, and other non-technical criteria. For example, it's probably a better idea to be consistent with tooling even if a side project is a great fit for another language/framework. Or maybe it's worth the cost in your particular situation. In CS we often talk about trade=offs. Should we use the normal trig functions or trade memory for speed and use a lookup table? Should the data be stored in an array or linked list? Should the math be done using int16, int32, int64, or a bignum library? Good design happens when you take the time to consider all of your options, including which tools you will use.
pjlegato 11y ago
> Winning this war has as much to do with culture and marketing as algorithms and data structures. This is true enough. I'd go farther and say that winning depends almost entirely on culture and marketing. The annals of computing are littered with the forgotten remains of technically amazing projects that suffered from poor or non-existent marketing execution. Rails is so popular mainly due to marketing tactics that won developer mindshare, rather than due to any technical merit. The larger question is not a mutually exclusive either-or situation. A good framework should be easy to use for the most common cases initially and well thought out enough that it's easily extensible in the future. When Rails first came out, I loved it. It made common stuff easy! Sure, it became intractable if you needed to deviate in any way from the planned normal cases, but that was fine for now. I thought it was a great V1 of the Ultimate Web Framework, and in time they'd build it out to have better and more flexible extensibility. I thought it was fine starting point to build upon, and that eventually they'd redo and flesh out the various badly designed subsystems. As the years went by, I realized that it was not a V1 of that mythical Ultimate Web Framework. Not at all. Its developers were quite content to feed on the low end of the market that just needed a quick way to shuttle data between a database and web forms. They had no intentions of updating its design to accomodate any other use cases. The few concessions that were made to other use cases were generally bolt-on hacks rather than integrated elements of the framework. They were focusing their time on flying around the world giving talks at conferences, writing books, giving training seminars, and otherwise monetizing their brand. Actual engineering work on Rails itself slowed to a near-halt, and it was then usually reactive in the sense that Rails had to be dragged forward kicking and screaming. Rails was no longer an innovator, but that was fine because they were making plenty of cash off of what Rails was. Indeed, they now had a strong disincentive to make any radical design changes, since they would have to redo all of their books and course curricula around the new design. There is no reason in principle why one couldn't build a framework that's both easy to get started with and easy to extend. It's just that nobody's bothered to do it yet.

deleted 11y ago

[deleted]

raverbashing 11y ago

> With Rails, you end up in the weeds in the long run, but the alternatives put you in the weeds right off the bat (with the promise of eventual salvation). The reality of most product development (ymmv) is that the former is highly preferable to the latter. You're absolutely right. And yes, Rails has quirks and I agree with most of the criticism of the other article Option 1: Twitter is built on RoR, have growing pains and lots of whales when it has an established product (when it gets the investors and the money to invest in a rebuild) Option 2: Twitter is built on Clojure, product takes more time, iteration gets slower, hiring is slower, some other competitor gets ahead. Ooops

dcrall 11y ago

I agree that Rails' strong opinions are still a strength. I like Clojure a lot, but for someone new to the language trying to get a Clojure web app started is like pulling teeth. Elixir and Phoenix, with their connections to the Ruby community, really get this, and I think they provide a much better introductory experience.

akmiller 11y ago
I've been doing Clojure for the better part of 3 years now and I'm not sure I get why people feel doing web development in Clojure is hard. Our first foray in Clojure was/is an API to manage our users that was built by 2 developers who were new to the language and has been running largely unmodified since being released. I actually believe the opposite. Jumping into and doing Clojure web development is extremely simple at the core. The issue with frameworks like Rails (and I'm not against Rails as I have used it on multiple successful projects and still think it's great) is that you get so much for free and don't have to understand how all the pieces fit and work together (at least initially). Soon enough you have to have more knowledge of that and that's were the complexity comes in.
- Bluestrike2 11y ago
  Is it fair to ding Rails for that, though? Regardless of what framework you're working with, eventually you're going to be peeking under the hood. Of either the framework, the language, or both. Whether that's front-loaded or not, it's still there. So the question becomes which framework eases you into the deep end of the pool, rather than which is the least complex. I've seen plenty of Rails apps that could have written better initially. But I haven't really seen any where it was impossible to refactor and improve them as a developer learns more.
  - akmiller 11y ago
    I'm not dinging Rails for that. Like I said I've done some successful applications with Rails. The difference I'd say between Clojure is you learn those from the bottom up, whereas with Rails you learn from the top down. Either way, you are going to have to learn them!
    - wyaeld 11y ago
      Where exactly does it say that you can't start by actually learning how Rails works, before you build things with it? I think the biases of people who were experienced big system developers before they moved to Rails, are very different from those who started with it, potentially not understanding web app development very well, and then produced something challenging to maintain

busterarm 11y ago

It's all about how you prioritize the problems you need to solve. At my current job we primarily use Wordpress. Why Wordpress? Because we have a large and non-technical content team, 260+ websites and several tens of thousands of pages of content that need to go up quickly. We're just 4 developers - about 1 for every 8 content & marketing people we have. We spend very little of our time on frontend. Tell me that you're going to get that kind of leverage with another tool. Wordpress is just about the last thing that you would pick as a developer or ops person to base your tech stack, but in our case it is the right choice. Aside: Coming from Rails and having spent six months deep in Wordpress core, it's actually kind of awesome. Seemingly every problem is solvable.

askyourmother 11y ago
WordPress is a pretty crazy codebase, yet, it seems sane compared to Rails. Interesting that WordPress as a service are moving to a node.js backend from PHP - even they chase shiny too
- busterarm 11y ago
  Do you know of any decent (modern stack) WPaaS besides Pantheon?
- btdiehr 11y ago
  Is it not an advantage for average users to be able to do both the front end and back end knowing only a single language?
  - askyourmother 11y ago
    The same advantage as just using a screwdriver to handle nails and screws? No. Right tool on the server (hint: it's not JS nor node), right tool on the client (JS if needs must)
kennell 11y ago
Comparing Rails and Wordpress seems like apples and oranges to me. Rails is a framework that lets you build anything web-app-ish, while Wordpress has its well defined, rather limited use cases. If it works for you, great, but the scenarios are different.

lobster_johnson 11y ago

These things depends a lot on how you build an app, too. All our webapps these days are thin React apps (with server-side rendering) that don't have a dedicated backend. Instead, they talk to a group of generic microservices. We've been doing this style of development since around 2010. With this methodology, a lot of Rails' ergonomic concerns (templating, the split between rendering HTML vs. data, etc.) just melt away. Front-ends become formally isolated clients of microservices, forcing you to engineer better internal APIs and get things like security correct from the start.

throwanem 11y ago
Not OP, but my guess is that would count as "in the weeds right off the bat"; the impression I get is that a lot of Rails's value proposition revolves around being able to start using it without actually needing to know or understand very much. (Which is not a bad thing, exactly! Its power as a rapid prototyping tool comes in large part from this trait. Unfortunately, so does its strong tendency to produce unmaintainable code.)
- lobster_johnson 11y ago
  Each approach comes with its benefits and challenges. I would never suggest anyone jump right to a microservice architecture if they haven't come to appreciate the problems posed by a Rails-type design. One aspect I keep hammering on about with regard to microservices is reusability. If you're developing just one user-facing product, nevermind. But if you have a bunch of products, reusability across microservices is a huge boon compared to monoliths. Reuse all your job processing, notifications, data storage, login/auth/group/role/permission management, identity verification, image processing, NLP processing, feed processing, etc. etc. etc. across your entire stack. With monoliths, the only other option is to build these as libraries, and unless you want to write bindings or write code more than once, you're now chaining yourself to a specific language.
colinramsay 11y ago
I'd love to know more about your webapp methodology. It sounds wonderful.

geebee 11y ago

I think this is a strong point. If rails is yesterday's technology, then what is today's? To be clear, by no means am I trying to claim that Rails is the clear winner over other technology choices, or that a good answer to this question needs to be one single, unambiguous answer. I've learned a lot about other possibilities. Node of course, but it's still relatively new, and you need to prefer (or at least be ok with) javascript instead of ruby. Pheonix and Elixir sound promising. My own personal prediction (probably better to call it a suspicion, since I'm wary of predictions) is that an "isometric" approach like Volt will become more common (the approach, not necessarily that specific implementation, though it is of course a possibility as well). But for now? Some will do this, but I wouldn't use Volt, though that has more to do with the requirements of my job than anything wrong with Volt (there really is no need for me to go so bleeding edge in what I do). I personally am hesitant to invest too much in Javascript, even on the client side, since there is still a great deal of churn. Again, this may simply not be a possibility for everyone, it depends on the kind of app you're writing. So it's not so much that I don't see good, perhaps preferable alternatives to Rails. I just don't see a sufficiently unambiguous case that Rails is out of date to be calling it yesterday's technology - yet. And lastly, as I mentioned in he other thread about this, when Rails isn't working for me, either because of code clarity or performance, I tend to go to older, more established technologies, not newer ones. For very elaborate sql, I use… sql, not contortions in ActiveRecord that I think are much harder to read and understand than a sql statement. I also often go to raw sql for performance reasons (mass inserts, queries that result in very large result sets that need to be optimized for speed). Unix, networking, specialized languages and environments for scientific computing, machine learning, stats, or other specialized tasks. That tends to be where I go.

drumdance 10y ago
I came to Node after four years on Rails and about 10 years of PHP before that. It definitely felt like a step back from Rails, but that's partly because Node wasn't meant just to be a web framework. I've gotten pretty comfortable with it, but I feel like the original decision to use it (which predates my joining the company) was primarily driven by how shiny and cool it is. The vast majority of what we do is standard CRUD stuff. On a personal level I've enjoyed learning it, and from a career perspective it's nice to have it on my CV, but had I been on board when the original decision was made I would definitely have chosen Rails. (Plus they also chose to use MySQL for no good reason. We've managed with it just fine, but in literally the last three weeks we ran into some limitations that would not be a problem in Postgres. The CEO, not being technical, doesn't quite understand why changing the database midstream is not something you do without really compelling reasons.)

noam87 11y ago

Elixir/Phoenix gets this right. Working on a side project right now and so far it's a very enjoyable experience. I find the abstractions much more intuitive. The framework as a whole is just as "magical" for fast prototyping, but it's composed of much simpler individual modules that are easy to wrap one's head around. It's surprising how mature the whole ecosystem feels considering it's still quite niche. It helps to have decades of battle-tested Erlang libraries at your disposal.

askyourmother 11y ago
Wait till hex is filled with crap like gems are today. The Rails programmers are coming to elixir as it had already been called the new Rails, and they will follow the pragprog book to it the new promised land. If you enjoyed early adopter status in elixir phoenix, wait till it is Rails mk 2. It will suck big time.
- szx 11y ago
  You have a point there, but I do wonder if this is inevitable, or if (1) the language does make a difference in that regard and (2) the community can help steer newcomers in the right direction and establish best practices, standards of quality, etc. etc. (cf. Clojure?) As a side note, I feel like this has happened to some degree to the React ecosystem. I can no longer count on packages to be of decent quality.

gshulegaard 11y ago

Just curious, but what do you consider a serious web app? I have had great success with Python across a variety of different applications. A lot of people seem to end up comparing/picking between Python and Ruby so I am curious for my own knowledge what type of serious application does Ruby make easy where Python makes difficult? I also think the overall gravitation towards microservice architecture generally makes language choice less important on the whole...but that's just me.

askyourmother 11y ago

So django gets it right. Laravel and symfony seem to get it right, yesod for Haskell gets it right - basically Rails is pretty awful, always was, but the crowd got caught up in five minute blogs and shiny magic to question the questionable insecure code, the rather suspect architecture.

dasil003 11y ago
Seems to me you don't actually remember what the web framework landscape was like in 2004.
goldbrick 11y ago
Can you be more specific? What do Django, Laravel, or Symfony do right that Rails does so awfully? I have had to use Symfony and everything about it was an inferior/weird Rails.

freyr 11y ago

> for a straightforward web app, you'll likely spend at least twice as long to get something working For a straightforward web app, Rails is probably a fine fit. For something less straightforward, it can shackle you down the road. The alternatives are an up-front investment that can save you time and effort down the road, but also give you enough leeway to make mistakes.

cag_ii 11y ago

Why compare Rails with Clojure (a framework vs. a language)? I think if you more fairly compare Rails with Django, Flask, Laravel, etc. you might find the differences aren't so great.

tetha 11y ago

> With Rails, you end up in the weeds in the long run, but the alternatives put you in the weeds right off the bat (with the promise of eventual salvation). The reality of most product development (ymmv) is that the former is highly preferable to the latter. As one of our product managers put it: Often, you want something you can sell well fast enough to buy time to make it good. Overall, in this tool/framework/language debate, I'm growing more and more convinced two things matter the most: - Pick something the weakest 40% of your team are comfortable using. Especially with support, I'd trust myself to figure out enough of Elixir/React/Whatever to be decently productive within a week or two on the go. But that's the thing - that's why I advocate to pick something the weaker team members are fine with. They will struggle, not the stronger team members. - Smash problems with standard solutions. Don't be smart. Pick the right tools, throw hardware at them. A decent combination of load balancing, language+ORM, an SQL persistence layer and possibly a message queue can handle _a lot_ of traffic. And it's easy to hire for and to get new people on board because there are no smart things going on. Note that the language and web framework are not part of this consideration at all. My approach would prefer more established frameworks like rails or something in java though.

pdkl95 11y ago

> (ymmv) This is probably the most important to remember. Every problem is different. Every situation is different. Good engineering isn't just the implementation, but also the design process. For most problems, there is rarely a single "correct" solution. This means decisions about which tools to use should should include maintenance costs, familiarity, and other non-technical criteria. For example, it's probably a better idea to be consistent with tooling even if a side project is a great fit for another language/framework. Or maybe it's worth the cost in your particular situation. In CS we often talk about trade=offs. Should we use the normal trig functions or trade memory for speed and use a lookup table? Should the data be stored in an array or linked list? Should the math be done using int16, int32, int64, or a bignum library? Good design happens when you take the time to consider all of your options, including which tools you will use.

pjlegato 11y ago

> Winning this war has as much to do with culture and marketing as algorithms and data structures. This is true enough. I'd go farther and say that winning depends almost entirely on culture and marketing. The annals of computing are littered with the forgotten remains of technically amazing projects that suffered from poor or non-existent marketing execution. Rails is so popular mainly due to marketing tactics that won developer mindshare, rather than due to any technical merit. The larger question is not a mutually exclusive either-or situation. A good framework should be easy to use for the most common cases initially and well thought out enough that it's easily extensible in the future. When Rails first came out, I loved it. It made common stuff easy! Sure, it became intractable if you needed to deviate in any way from the planned normal cases, but that was fine for now. I thought it was a great V1 of the Ultimate Web Framework, and in time they'd build it out to have better and more flexible extensibility. I thought it was fine starting point to build upon, and that eventually they'd redo and flesh out the various badly designed subsystems. As the years went by, I realized that it was not a V1 of that mythical Ultimate Web Framework. Not at all. Its developers were quite content to feed on the low end of the market that just needed a quick way to shuttle data between a database and web forms. They had no intentions of updating its design to accomodate any other use cases. The few concessions that were made to other use cases were generally bolt-on hacks rather than integrated elements of the framework. They were focusing their time on flying around the world giving talks at conferences, writing books, giving training seminars, and otherwise monetizing their brand. Actual engineering work on Rails itself slowed to a near-halt, and it was then usually reactive in the sense that Rails had to be dragged forward kicking and screaming. Rails was no longer an innovator, but that was fine because they were making plenty of cash off of what Rails was. Indeed, they now had a strong disincentive to make any radical design changes, since they would have to redo all of their books and course curricula around the new design. There is no reason in principle why one couldn't build a framework that's both easy to get started with and easy to extend. It's just that nobody's bothered to do it yet.