Rails has won: The Elephant in the Room(akitaonrails.com)
akitaonrails.com
Rails has won: The Elephant in the Room
http://www.akitaonrails.com/2016/05/23/rails-has-won-the-elephant-in-the-room
212 comments
I found it pretty coherent, actually. The author is trying to reset our focus from the technical details of how Rails works to the bigger picture of how the market for web technology has evolved over time. All the more important for those of us with "skin in the game," which I'm guessing means coders, because we tend to be myopic about our little world of symbols and tools, and often get caught clueless when the rug gets pulled out from under us by market forces that are indifferent to which design patterns are objectively better than others.
I concur. Coming from São Paulo, Brazil, I thought Akita's post was well written and derived out of positive, lightly spoken, opinion. Breath of fresh air against the backdrop of hostile tech machoism.
I read the article first to give it a chance and I have to say you're correct in your diagnosis.
The author's main issue with his writing style is he makes logical leaps without bringing the user along. He jumps from topic to topic without letting the user know why he's doing so.
I think the piece can be improved with some structural changes. So I would recommend the author or other readers consider this style for structurally formulating arguments for essays or presentations [1] often used at McKinsey.
(Note: I know McKinsey gets a lot of hate around here sometimes, but given their ability to consult with C-suite leadership, they're probably pretty good at formulating arguments/persuasion)
[1] https://medium.com/lessons-from-mckinsey/the-pyramid-princip...
The author's main issue with his writing style is he makes logical leaps without bringing the user along. He jumps from topic to topic without letting the user know why he's doing so.
I think the piece can be improved with some structural changes. So I would recommend the author or other readers consider this style for structurally formulating arguments for essays or presentations [1] often used at McKinsey.
(Note: I know McKinsey gets a lot of hate around here sometimes, but given their ability to consult with C-suite leadership, they're probably pretty good at formulating arguments/persuasion)
[1] https://medium.com/lessons-from-mckinsey/the-pyramid-princip...
This also has to do with the differences between a high-context language (Portuguese) and a low-context language (English). Portuguese is my first language, and I can remember that I needed a lot feedback from native English speakers in order to fine tune my speech -- let alone writing -- so they could actually get it.
RE: http://www.thunderbird.edu/article/understanding-high-and-lo...
RE: http://www.thunderbird.edu/article/understanding-high-and-lo...
That's really interesting - I hadn't heard of this difference between languages. Thanks for sharing.
Do you feel differences in context-type of a language means persuasion techniques differ as well?
Do you feel differences in context-type of a language means persuasion techniques differ as well?
I am not an expert on persuasion techniques, but if you take the same "logical leaps" situation you described in your comment and put it into the context of a business negotiation, chances are the other party may not feel confident enough to do business or simply to agree with you in some conditions because they don't get your line of thought.
He's writing in his second (third?) language. How's your second language?
Akita is a pretty smart dude. He makes a number of good points, and maybe doesn't tie them perfectly together, but it's a blog post he wrote in a day, not for Harpers.
A few points from his rant:
1. If you don't drink the kool aid, you'll be frustrated if you want something else 2. market forces: you have to follow rails, but if rails changes or goes away, you're stuck (-ish, it's OSS) 3. rails is good at what it does, and provides many with a useful framework, even if, in retrospect, it isn't well architected
Akita is a pretty smart dude. He makes a number of good points, and maybe doesn't tie them perfectly together, but it's a blog post he wrote in a day, not for Harpers.
A few points from his rant:
1. If you don't drink the kool aid, you'll be frustrated if you want something else 2. market forces: you have to follow rails, but if rails changes or goes away, you're stuck (-ish, it's OSS) 3. rails is good at what it does, and provides many with a useful framework, even if, in retrospect, it isn't well architected
The point @putzdown is making is not that the OP has many typos, etc., but rather that the article is incoherent babble with no structure, no point, and no evidence to support its non-point.
If Akita had written:
If Akita had written:
Sometimes, tools and frameworks, like
Wordpress and Rails, respectively, gain
enough traction that their monopoly
economies of scale keep them afloat
long after their value sunsets.
Precisely. It would have sufficed, and it would have been an unremarkable reaffirmation of the sad reality that yes, widespread habits trump merit in many cases (Betamax vs VHS etc etc). It's not clear what he said, but if all he said was, "Sure Rails stinks but the majority uses it so suck it up," I don't think it'd be an article worth applauding.
You know the post is bad when the second paragraph is:
If you go over other posts in that blog you will notice the same pattern: spit random (and most of the time wrong) stuff in an attempt that something will make sense (which never does).
First of all, it's inevitable but I still hate dramatic headlines, even though I
write like this myself sometimes. "My time with Rails is up" like it's saying
"And you should leave Rails now too if you're smart". I dismissed the article
entirely because of that. I was about to post a counter-rant to that without
reading it properly, but now that I have, I wrote this new article from scratch.
If you go over other posts in that blog you will notice the same pattern: spit random (and most of the time wrong) stuff in an attempt that something will make sense (which never does).
I cannot agree. I think lots of people (myself included) didn't read the original article and responded purely based on the title. I think that by admitting that he didn't read it and that he corrected that later, he's showing humility (that he too is a fallible human) and that gives his article -more- credibility.
Responding to something without reading it is just stupid. There's no other way to describe such an action.
Ah now that's a bit harsh. I thought it was pretty clear. Perhaps not getting to the point as quick as possible - but clear nevertheless.
I also agree that it's rambling, but clearly not first language so I'll give it a pass.
The general thesis seems to be that The frustration that Solnic felt with Rails is understandable, and quite possibly inevitable, as rails has become mainstream, large, and a ripe target for disruption by other frameworks/libraries. Despite this, Rails is still an excellent framework due to it's easy-rampup for beginners, and flexibility for more experienced developers.
Here is my summary of the sections, as I understood them:
Accepting Reality:
- Ruby is not much without rails.
- Large frameworks are written by entities that can afford to, so they are not held to the whims of other large entities (angular/polymer for google, react for fb, etc). It's just a power struggle.
- Rails can be compared to Wordpress, though wordpress's codebase is worse, rails suffers from similar lockin as tools like wordpress and magento.
- The community of rails is well-connected, and if large enough entities invest in rails & ruby, it will be fine, and will continue progressing through the natural cycles of OSS projects
Laws of market reality:
- Rule 1) Hindsight is 20/20
- Rule 2) No solution is perfect
- Rule 3) You either build tools for yourself or for others, fits-you or fits-the-market
- Avoid building businesses completely on frameworks/platforms made available by large entities, as they may dissapear at a moment's notice (i.e. don't tunnel-vision angular because google might kill it like GWT)
- Beware of churn and external reasons for software projects being put out to pasture.
- There is too much churn, and there are too many companies trying to make the next big thing. This can maek the monopolies provided by ASP.NET and Rails very attractive.
- There are many similarities between rails, asp.net and spring in that they shield you from churn and offer a tyrannical but relatively-unchanging toolset
- Frameworks either die heroes or live long enough to become the villain
Why is this a problem for rails now? What is the history of rails and it's competitors?
- The technical points from Solnic's article mostly have merit
- DHH has flaws, and rails is very much his brainchild. He created it while he had a business to run
- People flocked to rails from various languages/frameworks (.NET, PHP, Java), so they could drop unnecessary abstractions
- People got addicted to writing ruby, for it's simplicity and productivity advantages over PHP, Java, and C#
- 2007-2011 were magical years (the silver age) for ruby adoption, every drinks rails koolaid. Merb tries to capitalize and fails (though it was ahead of it's time).
- 2011-2016 was a bittersweet period (the bronze age). Other languages have created their own frameworks, and are similarly productive to ruby, so they start to gain attention. Languages like Node, rust, clojure, elixir and even haskell.
- The bronze age also sees big companies start to release languages (apple with swift, google with dart and go, microsoft with typescript ASP.NET MVC, facebook with react)
- Rails is having this issue because it was meant to. It is being disrupted just as it's predecessors were. It is inevitable.
- Being the incumbent, rails is vulnerable because it cannot move or change as fast.
- The dominant model has also shifted, from rails-y backends to much simpler APIs talking to SPAs (Single Page Apps). Apis are much smaller cand can be written easily in various other languages
- For small to medium projects that fit rails's model, rails is still king. As wordpress is still king for blogs -- yes you could write a blog with go APIs and using react, but it's not wise.
- If you're using ra ils as a medium sized company, make sure you're using all the lastest rails practices -- it may not make sense to pursue a rewrite right away.
Conclusion:
- Solnic has a point, the rails community has become a frustrating place to be for many people, but it has built lots of momentum. It also common for people to side with the underdog frameworks.
- Rails made the transition from underdog to mainstream in 5 years, and has done a lot for web development. It's hard to offer all of what rails offers and power the web as it has done.
- ActiveRecord is indeed a rough point for rail's architecture, but there's no alternative that offers benefit worth the pain of a rewrite. New applications thould definitely use rails + trailblazer or go straight to the Hanami framework, but most will probably just ditch ruby.
- ActiveRecord could be better, but it looks like even the creator of DataMapper has moved away from ORMs. For the usual case, ActiveRecord is still a good technology to use.
- Other communities will face the same issues rails is having, as they become mainstream. It's inevitable that DHH has chosen not to make large sweeping changes to rails, and although it alienates experienced developers, starting with rails is still easy for beginners.
- People forget the magic of rails that beginners feel when they start, and rails wins because of it's simplicity when learning as a beginner, as well as enabling experienced developers to make tweaks to it.
- It's anyone's guess whether rails will last another 10 years given all the competition it's currently facing
The general thesis seems to be that The frustration that Solnic felt with Rails is understandable, and quite possibly inevitable, as rails has become mainstream, large, and a ripe target for disruption by other frameworks/libraries. Despite this, Rails is still an excellent framework due to it's easy-rampup for beginners, and flexibility for more experienced developers.
Here is my summary of the sections, as I understood them:
Accepting Reality:
- Ruby is not much without rails.
- Large frameworks are written by entities that can afford to, so they are not held to the whims of other large entities (angular/polymer for google, react for fb, etc). It's just a power struggle.
- Rails can be compared to Wordpress, though wordpress's codebase is worse, rails suffers from similar lockin as tools like wordpress and magento.
- The community of rails is well-connected, and if large enough entities invest in rails & ruby, it will be fine, and will continue progressing through the natural cycles of OSS projects
Laws of market reality:
- Rule 1) Hindsight is 20/20
- Rule 2) No solution is perfect
- Rule 3) You either build tools for yourself or for others, fits-you or fits-the-market
- Avoid building businesses completely on frameworks/platforms made available by large entities, as they may dissapear at a moment's notice (i.e. don't tunnel-vision angular because google might kill it like GWT)
- Beware of churn and external reasons for software projects being put out to pasture.
- There is too much churn, and there are too many companies trying to make the next big thing. This can maek the monopolies provided by ASP.NET and Rails very attractive.
- There are many similarities between rails, asp.net and spring in that they shield you from churn and offer a tyrannical but relatively-unchanging toolset
- Frameworks either die heroes or live long enough to become the villain
Why is this a problem for rails now? What is the history of rails and it's competitors?
- The technical points from Solnic's article mostly have merit
- DHH has flaws, and rails is very much his brainchild. He created it while he had a business to run
- People flocked to rails from various languages/frameworks (.NET, PHP, Java), so they could drop unnecessary abstractions
- People got addicted to writing ruby, for it's simplicity and productivity advantages over PHP, Java, and C#
- 2007-2011 were magical years (the silver age) for ruby adoption, every drinks rails koolaid. Merb tries to capitalize and fails (though it was ahead of it's time).
- 2011-2016 was a bittersweet period (the bronze age). Other languages have created their own frameworks, and are similarly productive to ruby, so they start to gain attention. Languages like Node, rust, clojure, elixir and even haskell.
- The bronze age also sees big companies start to release languages (apple with swift, google with dart and go, microsoft with typescript ASP.NET MVC, facebook with react)
- Rails is having this issue because it was meant to. It is being disrupted just as it's predecessors were. It is inevitable.
- Being the incumbent, rails is vulnerable because it cannot move or change as fast.
- The dominant model has also shifted, from rails-y backends to much simpler APIs talking to SPAs (Single Page Apps). Apis are much smaller cand can be written easily in various other languages
- For small to medium projects that fit rails's model, rails is still king. As wordpress is still king for blogs -- yes you could write a blog with go APIs and using react, but it's not wise.
- If you're using ra ils as a medium sized company, make sure you're using all the lastest rails practices -- it may not make sense to pursue a rewrite right away.
Conclusion:
- Solnic has a point, the rails community has become a frustrating place to be for many people, but it has built lots of momentum. It also common for people to side with the underdog frameworks.
- Rails made the transition from underdog to mainstream in 5 years, and has done a lot for web development. It's hard to offer all of what rails offers and power the web as it has done.
- ActiveRecord is indeed a rough point for rail's architecture, but there's no alternative that offers benefit worth the pain of a rewrite. New applications thould definitely use rails + trailblazer or go straight to the Hanami framework, but most will probably just ditch ruby.
- ActiveRecord could be better, but it looks like even the creator of DataMapper has moved away from ORMs. For the usual case, ActiveRecord is still a good technology to use.
- Other communities will face the same issues rails is having, as they become mainstream. It's inevitable that DHH has chosen not to make large sweeping changes to rails, and although it alienates experienced developers, starting with rails is still easy for beginners.
- People forget the magic of rails that beginners feel when they start, and rails wins because of it's simplicity when learning as a beginner, as well as enabling experienced developers to make tweaks to it.
- It's anyone's guess whether rails will last another 10 years given all the competition it's currently facing
I've been using Rails for a decade now, across many jobs, and one thing I've experienced fairly consistently is the worst Ruby web apps I have ever dealt with are the ones that weren't written in Rails.
I've both seen and spent a lot of time rewriting overgrown Sinatra monstrosities with assorted non-AR ORMs. These apps were generally riddled with XSS since they didn't handle escaping correctly, often had unmaintainable code that sometimes was thousands of lines long crammed into a single file, and lacking any sort of basic structuring principles mixed parameter handling with business logic all over the place.
I've seen several attempts to "build a better Rails" that's "more OO", but even frameworks that solve the problems I've just described in the previous paragraph have one huge drawback: Rails is a lingua franca for web development in Ruby, and whatever incremental gains you get from having a better framework are heavily outweighed by the costs of making people learn a new framework-per-project, the lack of features and documentation, and the lack of the library ecosystem that surrounds Rails.
At points I've tried to keep three ORMs/DB libraries in my head at a time: AR, DataMapper, and Sequel, which just left me wishing I was dealing with AR (the devil you know...)
ORMs need massive feature sets to jam the proverbial square peg of relational databases through the round hole of objects, and AR is the only one I've used that's both expressive enough to cover all the cases I'm interested in and mature enough to even have a story around database concurrency, even if most Rails developers are getting database concurrency wrong with AR (e.g. http://www.bailis.org/papers/feral-sigmod2015.pdf ) At least AR has any story around things like optimistic and pessimistic locking and lets you build apps where you can read an object and persist your changes without silently clobbering another requests's database writes with your locally cached copy of stale data.
tl;dr: if you want to do web development but dislike Rails, your best bet is probably to switch to a different programming language than Ruby.
I've both seen and spent a lot of time rewriting overgrown Sinatra monstrosities with assorted non-AR ORMs. These apps were generally riddled with XSS since they didn't handle escaping correctly, often had unmaintainable code that sometimes was thousands of lines long crammed into a single file, and lacking any sort of basic structuring principles mixed parameter handling with business logic all over the place.
I've seen several attempts to "build a better Rails" that's "more OO", but even frameworks that solve the problems I've just described in the previous paragraph have one huge drawback: Rails is a lingua franca for web development in Ruby, and whatever incremental gains you get from having a better framework are heavily outweighed by the costs of making people learn a new framework-per-project, the lack of features and documentation, and the lack of the library ecosystem that surrounds Rails.
At points I've tried to keep three ORMs/DB libraries in my head at a time: AR, DataMapper, and Sequel, which just left me wishing I was dealing with AR (the devil you know...)
ORMs need massive feature sets to jam the proverbial square peg of relational databases through the round hole of objects, and AR is the only one I've used that's both expressive enough to cover all the cases I'm interested in and mature enough to even have a story around database concurrency, even if most Rails developers are getting database concurrency wrong with AR (e.g. http://www.bailis.org/papers/feral-sigmod2015.pdf ) At least AR has any story around things like optimistic and pessimistic locking and lets you build apps where you can read an object and persist your changes without silently clobbering another requests's database writes with your locally cached copy of stale data.
tl;dr: if you want to do web development but dislike Rails, your best bet is probably to switch to a different programming language than Ruby.
> AR is the only one I've used that's both expressive enough to cover all the cases I'm interested in
Have you never worked on a system big enough to need a service layer?
Have you never worked on a system big enough to need a service layer?
I've been using service objects / operations in my apps pretty consistently for half a decade, but that's a red herring. That statement is about using AR to query and manipulate data, which is orthogonal to a service layer. Service objects aren't going to fix the lack of optimistic/pessimistic locking in DataMapper.
I don't know what you mean by "service objects", but my point is that ActiveRecord requires you to have a line to the database in order to actually populate a database. This is really shit for a SOA; you should not require a connection to the user database to be able to make heads or tails of an object from your authn/authz service. It is so completely unacceptable that I consider it completely disqualifying (to say nothing of AR's other problems; if I had to use an ORM, which I don't because DALs are fairly trivial in Ruby, I would use Sequel).
This is why I use Virtus and ROM.
This is why I use Virtus and ROM.
Oh, so you're talking about SOA / "microservices" and Claims-Based Identity (or rather, Claims-Based Identity is what you should be using). Well, an ORM is totally the wrong way to go about expressing user identities in a distributed system.
As it were I wrote the AuthN/AuthZ library Square uses to solve this problem:
https://github.com/square/rails-auth
The objects we build for representing user identities are POROs. No need for every app to have a database connection to a shared user service, or to go through an ORM.
I'm somewhat confused what alternative you're even proposing here: are you doing something weird like Marshalling ORM objects between services?
As it were I wrote the AuthN/AuthZ library Square uses to solve this problem:
https://github.com/square/rails-auth
The objects we build for representing user identities are POROs. No need for every app to have a database connection to a shared user service, or to go through an ORM.
I'm somewhat confused what alternative you're even proposing here: are you doing something weird like Marshalling ORM objects between services?
You're right in that claims-based identity is the better approach; users was not the best example, but I wrote that post more hastily than I should have. =) But any distributed service with single-source-of-truth ownership of a domain object is going to be totally hosed by ActiveRecord; to handle it without every service having a database connection to every other service's datastore you end up with something like a conversion step from Magic Model Object to a PORO, and that sucks wind.
(In my own case, I have a service architecture because I literally have to; I need to run services in multiple AWS regions. It would be nice to be able to not care and fart everything into a single monolithic application, but them's the breaks. I tend to think that almost every sufficiently complex or sufficiently scaled application ends up in this state, too.)
With Virtus/rom-model (or I guess the newer dry-types, though I haven't used it), I don't, because my--versioned, because my APIs already require compatibility--model objects are aware of their own contents, and I can trivially marshal objects over the wire. (I also don't have to go look at the database schema to know what my object is. Big plus.)
(In my own case, I have a service architecture because I literally have to; I need to run services in multiple AWS regions. It would be nice to be able to not care and fart everything into a single monolithic application, but them's the breaks. I tend to think that almost every sufficiently complex or sufficiently scaled application ends up in this state, too.)
With Virtus/rom-model (or I guess the newer dry-types, though I haven't used it), I don't, because my--versioned, because my APIs already require compatibility--model objects are aware of their own contents, and I can trivially marshal objects over the wire. (I also don't have to go look at the database schema to know what my object is. Big plus.)
to handle it without every service having a database connection to every other service's datastore you end up with something like a conversion step from Magic Model Object to a PORO, and that sucks wind.
I actually prefer the distinction: serialized domain objects do not have access to the full richness of the ORM API, so having a separate class representing the specific behavior of an API-wrapper makes a lot more sense to me.
Something like ActiveModel::Serializers wraps up a lot of the boilerplate while also letting you retrieve nested object graphs in a single request:
https://github.com/rails-api/active_model_serializers
That said at Square we generally use protobuf-based RPC for our service-to-service requests, because we have a polyglot SOA so it's important for our services to produce and consume protos to support more languages than just Ruby.
I actually prefer the distinction: serialized domain objects do not have access to the full richness of the ORM API, so having a separate class representing the specific behavior of an API-wrapper makes a lot more sense to me.
Something like ActiveModel::Serializers wraps up a lot of the boilerplate while also letting you retrieve nested object graphs in a single request:
https://github.com/rails-api/active_model_serializers
That said at Square we generally use protobuf-based RPC for our service-to-service requests, because we have a polyglot SOA so it's important for our services to produce and consume protos to support more languages than just Ruby.
For the vast majority of apps, SOA is detrimental to productivity and maintainability. For some cases it is the right choice but I don't think anyone is arguing that these are the cases for which AR was designed.
Can't you recognize the usefulness of a hammer even if you need a screwdriver for your task?
Can't you recognize the usefulness of a hammer even if you need a screwdriver for your task?
When that hammer inevitably is used on screw-related tasks, I get a bit touchy. ActiveRecord in particular is one of the bigger offenders (well, Rails full-stop is one), being applied in all sorts of ways that somebody (hi) ends up having to fix, which is why I mention it.
I don't agree with regards to SOAs and either productivity or maintainability, but I also tend to work on systems that have concrete needs for scale and I also divorce it from the microservice craze (which I regard as a rather pathological case). But that's kind of off-topic.
I don't agree with regards to SOAs and either productivity or maintainability, but I also tend to work on systems that have concrete needs for scale and I also divorce it from the microservice craze (which I regard as a rather pathological case). But that's kind of off-topic.
Could you point to any resources for someone who has been learning stock Rails/ActiveRecord to learn more about the approach you prefer?
I used Sequel once on a major project and as nice as it was, there was major pain. Pain I wouldn't have had with ActiveRecord.
I seriously would have gotten the job done in half the time, with less problems had I just used Rails...and I've written my own ORMs before - I have somewhat of a clue.
I seriously would have gotten the job done in half the time, with less problems had I just used Rails...and I've written my own ORMs before - I have somewhat of a clue.
I'm having the opposite experience, but I think that's because I'm working on a legacy database that really doesn't follow conventions. Even when overriding defaults in AR, I still found myself trying to hammer what I was doing into a AR-shaped block, whereas Sequel feels like it lets me craft a resultset as I desire regardless of what I'm starting with. But like I said, it's a legacy database and it was originally driving an app where writing raw SQL was the SOP, some of which really leans of higher-level SQL engine features for function and performance.
I'm curious what pain you experienced with Sequel, as I have the exact opposite experience.
Your nickname rings the bell. Aren't you https://github.com/tarcieri ?
If so the "tl; dr:" sounds strange considering your celluloid-based eco-system.
Edit: which I consider, at least to date, a bit orthogonal to the Rails ways.
If so the "tl; dr:" sounds strange considering your celluloid-based eco-system.
Edit: which I consider, at least to date, a bit orthogonal to the Rails ways.
> At points I've tried to keep three ORMs/DB libraries in my head at a time: AR, DataMapper, and Sequel ... At least AR has any story around things like optimistic and pessimistic locking
That's rather dating your "at points". DataMapper hasn't seen an update since 2011, and Sequel's shipped with optimistic and pessimistic locking since early 2010.
That's rather dating your "at points". DataMapper hasn't seen an update since 2011, and Sequel's shipped with optimistic and pessimistic locking since early 2010.
"tl;dr: if you want to do web development but dislike Rails, your best bet is probably to switch to a different programming language than Ruby."
But... wasn't this the underlying point of Solnic's opinion piece?
Due to Rails "well deserved" domination in the web framework space, POROs never had a chance of contributing to friendly and just competition across the Ruby community. We simply ended up with shitty alternatives because no one was given the proper chance to be BETTER Rubyists.
They just kept eating the gluten and feeling the allergy pains, so to speak.
Ah well...
EDIT: shrug quoting...
But... wasn't this the underlying point of Solnic's opinion piece?
Due to Rails "well deserved" domination in the web framework space, POROs never had a chance of contributing to friendly and just competition across the Ruby community. We simply ended up with shitty alternatives because no one was given the proper chance to be BETTER Rubyists.
They just kept eating the gluten and feeling the allergy pains, so to speak.
Ah well...
EDIT: shrug quoting...
I recall a lot of articles like this about J2EE. And then a lot like this about MSFT technologies.
There was an essay pg wrote where he said that Microsoft was Dead (http://www.paulgraham.com/microsoft.html). He didn’t mean dead as in “Dead," he meant dead as in “Nobody is afraid of them any more,” and the generalization of that is that it was no longer relevant.
I think Rails is there. I think Rails is dead. Obviously, not dead as in dead, but dead as in, it is no longer revolutionizing anything. It is no longer making new things possible. People no longer adopt it and discover a productivity dividend they didn’t expect. It no longer swings business decisions (“How can we get this done in three months? What about using Rails? Let’s try it.”)
I think that’s fine. I can quote “A new perspective is worth 80 points of IQ.” I don’t think that’s true of Rails today, but then again, I don’t think that’s what people want from Rails. If people want 80 points of IQ, they’re off looking at Elixir and Phoenix.
Likewise, I can say that “A language that doesn’t change the way you think about programming isn’t worth learning,” but who is learning Ruby and Rails in order to change the way they think about programming? They’re trying to bang out CRUD apps, and they don’t want to think about programming, that’s why they value a stable community with widely adopted “best practices.”
When you have a stable, mature language and framework, you spend more time thinking about your business and less time thinking about programming.
And thus, Rails (and sorry, but Ruby too) is not for people who want 80 points of IQ or to change the way they think about programming. And thus, in the sense of being influential, in the sense of disrupting anything or changing anything Rails is dead.
It has matured. It is mainstream. It is plumbing, it is concrete, it is rebar, it is infrastructure. Necessary and useful. But not something you want to spend a lot of time thinking about, just something you use if it suits your purposes.
There was an essay pg wrote where he said that Microsoft was Dead (http://www.paulgraham.com/microsoft.html). He didn’t mean dead as in “Dead," he meant dead as in “Nobody is afraid of them any more,” and the generalization of that is that it was no longer relevant.
I think Rails is there. I think Rails is dead. Obviously, not dead as in dead, but dead as in, it is no longer revolutionizing anything. It is no longer making new things possible. People no longer adopt it and discover a productivity dividend they didn’t expect. It no longer swings business decisions (“How can we get this done in three months? What about using Rails? Let’s try it.”)
I think that’s fine. I can quote “A new perspective is worth 80 points of IQ.” I don’t think that’s true of Rails today, but then again, I don’t think that’s what people want from Rails. If people want 80 points of IQ, they’re off looking at Elixir and Phoenix.
Likewise, I can say that “A language that doesn’t change the way you think about programming isn’t worth learning,” but who is learning Ruby and Rails in order to change the way they think about programming? They’re trying to bang out CRUD apps, and they don’t want to think about programming, that’s why they value a stable community with widely adopted “best practices.”
When you have a stable, mature language and framework, you spend more time thinking about your business and less time thinking about programming.
And thus, Rails (and sorry, but Ruby too) is not for people who want 80 points of IQ or to change the way they think about programming. And thus, in the sense of being influential, in the sense of disrupting anything or changing anything Rails is dead.
It has matured. It is mainstream. It is plumbing, it is concrete, it is rebar, it is infrastructure. Necessary and useful. But not something you want to spend a lot of time thinking about, just something you use if it suits your purposes.
Thanks for this Reg, I have spent the last year of my life trying to vacuum the drama out of this discussion. The "working retirement" of mature technology is so normal and pretty wonderful in the scheme of things. Even the "prominent defector" bit is easily predictable. Once you know this, you can pick technology for the stability & productivity or the +80 IQ, depending on your situation.
https://speakerdeck.com/tehviking/surviving-the-framework-hy...
https://speakerdeck.com/tehviking/surviving-the-framework-hy...
“A new perspective is worth 80 points of IQ.”
That's not how IQ works. It's not additive.
That's not how IQ works. It's not additive.
The quote is from Dr. Alan Kay. I think he knew that when he said, it, and personally I think IQ is a racist, bullshit metric. But the general idea of the quote is still meaningful, and the thing I am saying when quoting it is that having gone mainstream, adopting Rails is no longer about adopting a new perspective.
It’s tautological: You don’t get a new perspective, or an advantage, by adopting the mainstream thing and using it the mainstream way with the mainstream best practices, carefully writing your code to be familiar to the mainstream programmers.
That’s not a bad thing, but it is a different thing from when Rails was first popping up in Reddit’s old days and HN’s early days.
It’s tautological: You don’t get a new perspective, or an advantage, by adopting the mainstream thing and using it the mainstream way with the mainstream best practices, carefully writing your code to be familiar to the mainstream programmers.
That’s not a bad thing, but it is a different thing from when Rails was first popping up in Reddit’s old days and HN’s early days.
iqisracist(1)
I think you might be getting downvoted for stating it so baldly.
IQ scores reflect the place of a particular person relative to the population rather than a simple score derived from performance. You may mean that IQ doesn't work like decibels, which are intended for the invariant expression of relative loudness. It's a complicated area and I don't think "additive" quite captures the property that you are saying IQ doesn't have...
IQ scores reflect the place of a particular person relative to the population rather than a simple score derived from performance. You may mean that IQ doesn't work like decibels, which are intended for the invariant expression of relative loudness. It's a complicated area and I don't think "additive" quite captures the property that you are saying IQ doesn't have...
Well, IQ isn't really a thing, so...
I think Ruby may still have a few under-recognized advantages for small teams :-)
Ruby was the number 1 reason why about 6 years ago, fresh out of uni with a Java/C background, I chose to learn Python and Django.
Ruby seemed rather useless outside of Rails and I really, really liked what I saw in the Zen of Python.
Ie. less magic, explicit > implicit. Etc.
Ruby seemed rather useless outside of Rails and I really, really liked what I saw in the Zen of Python.
Ie. less magic, explicit > implicit. Etc.
I have to agree here. Its a good thing that Django doesn't have the kind of overwhelming power that Rails has in the community, which is pretty awesome! There's a lot of diversity, like flask, pyramid and others; although Django does have a large part of the pie.
I think he was saying thay Django has a relatively small part in the overall Python pie.
As in web development plays a small part in everything Python. Python's scientific use comes to mind as a strong alternative.
I agree. The Python ecosystem has a healthier amount of diversity, both in terms of Django vs other frameworks and web development vs other use cases.
It's great that you learned Python and Django instead of Rails, but it seems pretty uncalled for to call Ruby useless outside of Rails.
Programming languages take off because they show off their power by implementing a great library or by doing a better way of doing things which is what Ruby did using Rails.
The impact of Rails on frameworks/libraries in other languages is also significant since a lot of Ruby developers moved to JS/Elixir/Go and started contributing and implementing the best patterns found in Rails/Sinatra etc.
Programming languages take off because they show off their power by implementing a great library or by doing a better way of doing things which is what Ruby did using Rails.
The impact of Rails on frameworks/libraries in other languages is also significant since a lot of Ruby developers moved to JS/Elixir/Go and started contributing and implementing the best patterns found in Rails/Sinatra etc.
I think "useless" in this case is meant in the sense of "isn't used much". The Ruby community and ecosystem is dominated by Rails to a much greater degree than Python is dominated by Django.
Django is merely one of the more popular solutions to a larger niche of what Python is used for. The closest equivalent to Rails in Python in terms of dominance is probably SciPy and even that comparison is a stretch.
The Python ecosystem is much more diverse than Ruby. Not because Ruby can't be used for anything other than what Rails is used for, but because there are simply more people doing the different things Python can be used for.
And ultimately the practical usefulness of a language depends not just on the suitability of the language itself for the given task but also on the availability of libraries for the common problems you encounter when solving that task. So the usefulness of a language (for a given task) is at least partially defined by how much it is actually used (to solve that task).
Django is merely one of the more popular solutions to a larger niche of what Python is used for. The closest equivalent to Rails in Python in terms of dominance is probably SciPy and even that comparison is a stretch.
The Python ecosystem is much more diverse than Ruby. Not because Ruby can't be used for anything other than what Rails is used for, but because there are simply more people doing the different things Python can be used for.
And ultimately the practical usefulness of a language depends not just on the suitability of the language itself for the given task but also on the availability of libraries for the common problems you encounter when solving that task. So the usefulness of a language (for a given task) is at least partially defined by how much it is actually used (to solve that task).
Ruby is used in many other projects outside of Rails and some don't have anything to do with web development (Chef, Puppet, Homebrew, Vagrant, Metasploit, Logstash, Capistrano).
Rails isn't the fastest or the smartest framework. It has weird choices, confusing aspects and some downright terrible defaults, but for me at least, it is the best framework and it has been for years for one simple reason: DOCUMENTATION!
Every few years or so, a bunch of these articles come out shouting from the roof tops, "Rails is dead!" and "Long live Rails!" They often like to praise some new framework, like Hanami, as the answer to all our woes, but they never seem to address documentation.
In my opinion, documentation is where Rails blows every other framework away. I have never been forced to read Rails' source code to understand how something works (I have read some of the source, but for fun, not out of need), and I can't say that about any of the other framework I've worked with. There's always some obscure method or class somewhere in them that does something unintuitive that I always have to look up. In Rails, finding the documentation on that method is as simple as a Google search, but in django, expressjs, or any of the others I've encountered, that documentation usually doesn't even exist at all.
Efficiency, scalability and reliability are all great, but when I'm starting a web app from scratch, they're really not that important. I can worry about those things once I have funding. In the meantime, I only need them to be good enough, and Rails defaults are usually good enough.
What I really need when I'm starting a new project and I'm working on a shoestring budget, is speed. I need to build something fast so I can get funded. Once I'm funded, then I can think about implementing JRuby or splitting code out into microservices or rewriting with another framework, but by then, I'll have the money to take my time. Until then, Rails is the perfect framework for me and I'll keep using it until it's not.
Every few years or so, a bunch of these articles come out shouting from the roof tops, "Rails is dead!" and "Long live Rails!" They often like to praise some new framework, like Hanami, as the answer to all our woes, but they never seem to address documentation.
In my opinion, documentation is where Rails blows every other framework away. I have never been forced to read Rails' source code to understand how something works (I have read some of the source, but for fun, not out of need), and I can't say that about any of the other framework I've worked with. There's always some obscure method or class somewhere in them that does something unintuitive that I always have to look up. In Rails, finding the documentation on that method is as simple as a Google search, but in django, expressjs, or any of the others I've encountered, that documentation usually doesn't even exist at all.
Efficiency, scalability and reliability are all great, but when I'm starting a web app from scratch, they're really not that important. I can worry about those things once I have funding. In the meantime, I only need them to be good enough, and Rails defaults are usually good enough.
What I really need when I'm starting a new project and I'm working on a shoestring budget, is speed. I need to build something fast so I can get funded. Once I'm funded, then I can think about implementing JRuby or splitting code out into microservices or rewriting with another framework, but by then, I'll have the money to take my time. Until then, Rails is the perfect framework for me and I'll keep using it until it's not.
Elixir and Phoenix is what you're looking for. Most of the goodness of Rails for productivity, without the long term bad decisions that come with it to force eventual rewrites when the funding comes. There's a reason Rails core guys have put so much time into it.
It gets every...single...dang...decision...right. I may never use another language unless forced because it's what I've spent years trying to find.
It gets every...single...dang...decision...right. I may never use another language unless forced because it's what I've spent years trying to find.
Nope. It doesn't. I've spent two years working with it. And "gets every single dang decision right" is a matter of opinion. Chris and José are incredibly wonderful people, but they are just as opinionated as the people behind Rails.
So "gets decisions right" sounds good as long as you agree with those decisions.
I happen to love working with Elixir and Phoenix. I find working with Ecto frustrating not because of the code, but because of the opinions the framework creators have made about where things go. They have good solid reasons for their opinions. And they are not wrong.
I just don't agree with them. And that's totally ok.
So "gets decisions right" sounds good as long as you agree with those decisions.
I happen to love working with Elixir and Phoenix. I find working with Ecto frustrating not because of the code, but because of the opinions the framework creators have made about where things go. They have good solid reasons for their opinions. And they are not wrong.
I just don't agree with them. And that's totally ok.
Depends on the decisions, but in my experience the way they've setup to do things encourages the proper balance of productivity, separation of concerns, maintainability and data integrity.
The balance on the database side of things has been most impressive because I didn't expect it at all coming from several years of Rails. In my experience to this point, the idea of letting your database enforce the integrity of your data was generally viewed as heresy. You could do it and the Rails team itself provided all of the tools to do it properly, but it seemed as if the community in general was totally opposed to it. The community shift towards embracing PostgreSQL so heavily has seemed to slowly be steering that trend away but there's still a lot of opposition. I've seen some tragic consequences because of those decisions in the last few years.
The balance encouraged in Programming Phoenix sets an excellent standard for a growing community.
The view + template layer has been a breath of fresh air.
Of course, to each his own.
Phoenix has me more excited about work than I've been in years though and I'm that guy that doesn't shut up about things that he loves. :-)
The balance on the database side of things has been most impressive because I didn't expect it at all coming from several years of Rails. In my experience to this point, the idea of letting your database enforce the integrity of your data was generally viewed as heresy. You could do it and the Rails team itself provided all of the tools to do it properly, but it seemed as if the community in general was totally opposed to it. The community shift towards embracing PostgreSQL so heavily has seemed to slowly be steering that trend away but there's still a lot of opposition. I've seen some tragic consequences because of those decisions in the last few years.
The balance encouraged in Programming Phoenix sets an excellent standard for a growing community.
The view + template layer has been a breath of fresh air.
Of course, to each his own.
Phoenix has me more excited about work than I've been in years though and I'm that guy that doesn't shut up about things that he loves. :-)
If you discover a hot new language/framework that solves all of your problems, then here is what you've actually learned: you didn't have any hard problems.
No tool is perfect for every situation, and if you find one that is perfect for every situation that you encounter, then that says a lot more about you than about the tool.
No tool is perfect for every situation, and if you find one that is perfect for every situation that you encounter, then that says a lot more about you than about the tool.
He's right though, Elixir and Phoenix are amazing. It promises the productivity of Rails, while being blazingly fast and scalable. You'll never, ever need to rewrite your backend, even if you're handling traffic at the scale of Whatsapp.
I would be hard-pressed to find a case where you'd want to write your web or mobile backend in anything else. So yeah, I'd claim that it's perfect for every web or mobile backend.
Also, no framework is ever going to solve all of your "hard problems", and he didn't claim that at all. It's simply a much better base than Rails.
I would be hard-pressed to find a case where you'd want to write your web or mobile backend in anything else. So yeah, I'd claim that it's perfect for every web or mobile backend.
Also, no framework is ever going to solve all of your "hard problems", and he didn't claim that at all. It's simply a much better base than Rails.
It's about balance and this has the right one for about 95% of what I do everyday in terms of client-server-database work, productivity, concurrency, stability, performance and scalability. That's where I spend most of my time on the web.
Short of complex calculations or extreme niche scenarios...it does handle pretty much everything in terms of "around web" work. For niche scenarios use what's appropriate but for the space that Rails has occupied in the general purpose realm it's wonderful.
Short of complex calculations or extreme niche scenarios...it does handle pretty much everything in terms of "around web" work. For niche scenarios use what's appropriate but for the space that Rails has occupied in the general purpose realm it's wonderful.
Why does someone come to promote Elixir and Phoenix in every Ruby/Rails article? The first times was nice to see someone showing an alternative, now is almost like SPAM.
Because the Elixir/Phoenix community is largely spawned from the Ruby/Rails community. They are more likely to be continuing to follow what is going on with Rails, even living in both worlds. There are many shared values and experience. That historical affinity is probably why it shows up so much in the same context. The Elixir/Phoenix community is more likely to respect and understand what Rails is and isn't as opposed to the vast majority of pretenders who say they are creating a framework inspired by, or to rival Rails, but really have no clue and proceed to put up something nowhere near the breadth or depth of Rails. Nobody who knows anything is going to come and put up an advocacy post for a PHP framework as an alternative to Rails. They know the Rails community has no interest in going that way. Elixir/Phoenix on the other hand can say with a straight face: we understand Rails and why it is successful and put forward Elixir/Phoenix as a legitimate way forward for those who want to move to a more functional paradigm and the inherent scalability advantages of a Erlang/OTA based foundation.
It's a religion.
More seriously, the community just needs to be a lot bigger before it's on par with the Ruby ecosystem. For example, there's currently no Elixir library that will inline CSS in emails before sending.
More seriously, the community just needs to be a lot bigger before it's on par with the Ruby ecosystem. For example, there's currently no Elixir library that will inline CSS in emails before sending.
Honestly, I'm just excited.
I really love Elixir and Phoenix and see myself using them heavily in the future, I just think you are completely not fair to Rails.
Whoever downvoted me :) just made my score 666 !..! rock on baby!
I've taught a course on Rails and I still use it everyday for work. It just has some long term weaknesses that are hard to swallow after a while.
I completely agree, I really enjoy H whatever Lotus.rb is called these days and especially like Trailblazer. So you could say that in general I agree with this sentiment, just, it would never cross my mind to be as hard to Rails as some of commenters are.
Rails is a mature framework now. A lot of people love to hate on mature stuff in programming.
I haven't seen any about Rails being dead, just people ready to move on from Rails and how it's not for them any longer. If it makes sense for a particular shop, they should continue using it. I say this as a non Rails user but believer in the right tool for the right job.
Just looked at the rails documentation for the first time in years. It's drastically improved.
My experience with earlier versions was that you kinda had to piece it together yourself. Learning Play Framework was 10X easier for me since the docs were already there: https://www.playframework.com/documentation/2.5.x/Home
So I think maybe you're just not considering non-Ruby options. Which is totally your prerogative. Just saying it's not my experience. It may be the best Ruby framework. But that's a different argument.
> What I really need when I'm starting a new project and I'm working on a shoestring budget, is speed. I need to build something fast so I can get funded.
Aside from syntax, I don't see any reason anyone would be faster with Rails. It's certainly not my experience. I worked with Ruby for 8 years. I've seen some very talented and very enthusiastic Rails developers. I've never seen one that could build an app faster than even an ASP.NET developer from years ago, and I certainly don't see any advantage over Play, which is generally more stable, much faster, projects generally have fewer dependencies.
The performance advantage of other platforms is underappreciated IMO. The fastest code is no code. If I can do something in Scala through brute that would be impractical to do within the request/response cycle in a Rails Action, that's a development speed advantage. If I never need to consider using some sort of background job service like Resque or message queue because I can just say `Future(someComplexOperation)`, that's a development speed advantage. If I don't need to tune my app or worry about my caching strategies because it's just that fast... You get the point I'm trying to make I'm sure.
Outside of performance, deployment (far simpler with Play), language syntax, and ActiveRecord (I'd just use the simpler, faster Lightbend Slick library) they're basically the same framework. Play doesn't chart much new territory. Sure WebSockets integration with Actors is lightyears ahead. But many won't ever touch it. There's some JSON stuff with validations that's very powerful, but embedding the equivalent of a JSON schema in your Action is verbose beyond trivial examples. I'm not sure how much use it gets.
I found Play much easier to learn than Rails (again, this was years ago) and much more consistent. Given the other advantages, all things being equal (familiar with both Scala and Ruby), it's tough to imagine many developers choosing Rails unless they were worried about externalities like building a team or something.
It'd be interesting to hear the thought process of such developers though if they're out there.
My experience with earlier versions was that you kinda had to piece it together yourself. Learning Play Framework was 10X easier for me since the docs were already there: https://www.playframework.com/documentation/2.5.x/Home
So I think maybe you're just not considering non-Ruby options. Which is totally your prerogative. Just saying it's not my experience. It may be the best Ruby framework. But that's a different argument.
> What I really need when I'm starting a new project and I'm working on a shoestring budget, is speed. I need to build something fast so I can get funded.
Aside from syntax, I don't see any reason anyone would be faster with Rails. It's certainly not my experience. I worked with Ruby for 8 years. I've seen some very talented and very enthusiastic Rails developers. I've never seen one that could build an app faster than even an ASP.NET developer from years ago, and I certainly don't see any advantage over Play, which is generally more stable, much faster, projects generally have fewer dependencies.
The performance advantage of other platforms is underappreciated IMO. The fastest code is no code. If I can do something in Scala through brute that would be impractical to do within the request/response cycle in a Rails Action, that's a development speed advantage. If I never need to consider using some sort of background job service like Resque or message queue because I can just say `Future(someComplexOperation)`, that's a development speed advantage. If I don't need to tune my app or worry about my caching strategies because it's just that fast... You get the point I'm trying to make I'm sure.
Outside of performance, deployment (far simpler with Play), language syntax, and ActiveRecord (I'd just use the simpler, faster Lightbend Slick library) they're basically the same framework. Play doesn't chart much new territory. Sure WebSockets integration with Actors is lightyears ahead. But many won't ever touch it. There's some JSON stuff with validations that's very powerful, but embedding the equivalent of a JSON schema in your Action is verbose beyond trivial examples. I'm not sure how much use it gets.
I found Play much easier to learn than Rails (again, this was years ago) and much more consistent. Given the other advantages, all things being equal (familiar with both Scala and Ruby), it's tough to imagine many developers choosing Rails unless they were worried about externalities like building a team or something.
It'd be interesting to hear the thought process of such developers though if they're out there.
Periodically raise up such articles à la "Rails is dead, long live the Rails". Rails has won in the past because it was so more pragmatic than its alternatives, and in the end better designed, and still wins now because it is more mature than its recent better designed competitors (Phoenix, Hanami, ..), and its community is so a big speed up now.
> People think that because something is "technically superior" everybody else should blindly adopt. But this is not how the market works.
This is really the citation describing the web development of the last 10-15 years. No surprise it comes from DHH.
> People think that because something is "technically superior" everybody else should blindly adopt. But this is not how the market works.
This is really the citation describing the web development of the last 10-15 years. No surprise it comes from DHH.
"But I would never, ever, begin a new business that depends solely on Angular to survive. Why? Because Google doesn't need it. It didn't blink to give up GWT, it didn't have to think twice to decide to rewrite Angular 2 in an incompatible way to Angular 1, and so on."
This is just wrong - almost 3/4 of Google's web apps depend on Angular from what I have heard from multiple Googlers. If a rare instance where an Angular release failure occurs, it shuts down Google's development process dramatically & costs millions in productivity.
That rewrite is aimed at making Angular vastly improved - that doesn't equate to giving up on Angular, that is a poor analogy. In fact, Google decided to start investing vastly more resources into the Angular team, rapidly hiring and growing the team into a proper one, as opposed to it being a pet project of the Adwords team. In the next year or two, that ambition will bear much more fruit as mindshare grows with the realization of the technical problems solved & improved upon by ng2 - if React doesn't gear up to evolve, we'll probably see either a lot of defection to Angular, or a competitor that disagrees with the complexity that Angular introduces appearing to swallow React, just as React has done the same to grab disenchanted Backbone/Angular/etc. users.
Otherwise, the article does a good job explaining a lot of things, but it is very defeatist, as if it is futile to try to improve upon things. I can't say I agree with that sentiment, it goes against the heart of research/trailblazing/experimentation/etc.
It also makes some weak assertions, such as "One rarely benefits from big bang rewrites from scratch.", which is a generality being applied to every single situation, a fallacy. Confusing commonly accepted wisdom in development with an overextension of their meaning can lead to bad conclusions, as well as bad decision making.
This is just wrong - almost 3/4 of Google's web apps depend on Angular from what I have heard from multiple Googlers. If a rare instance where an Angular release failure occurs, it shuts down Google's development process dramatically & costs millions in productivity.
That rewrite is aimed at making Angular vastly improved - that doesn't equate to giving up on Angular, that is a poor analogy. In fact, Google decided to start investing vastly more resources into the Angular team, rapidly hiring and growing the team into a proper one, as opposed to it being a pet project of the Adwords team. In the next year or two, that ambition will bear much more fruit as mindshare grows with the realization of the technical problems solved & improved upon by ng2 - if React doesn't gear up to evolve, we'll probably see either a lot of defection to Angular, or a competitor that disagrees with the complexity that Angular introduces appearing to swallow React, just as React has done the same to grab disenchanted Backbone/Angular/etc. users.
Otherwise, the article does a good job explaining a lot of things, but it is very defeatist, as if it is futile to try to improve upon things. I can't say I agree with that sentiment, it goes against the heart of research/trailblazing/experimentation/etc.
It also makes some weak assertions, such as "One rarely benefits from big bang rewrites from scratch.", which is a generality being applied to every single situation, a fallacy. Confusing commonly accepted wisdom in development with an overextension of their meaning can lead to bad conclusions, as well as bad decision making.
> This is just wrong - almost 3/4 of Google's web apps depend on Angular from what I have heard from multiple Googlers. If a rare instance where an Angular release failure occurs, it shuts down Google's development process dramatically & costs millions in productivity.
So you were quick to call somebody wrong based on complete heresay? Do you have any conclusive proof that they use it? Gmail? Analytics?
So you were quick to call somebody wrong based on complete heresay? Do you have any conclusive proof that they use it? Gmail? Analytics?
Literally 5 seconds of Googling [1]. Turns out the app that allows Google's Ad customers (i.e. their main source of revenue) to use the Google platform is written in angular. It's also one of the oldest and largest Angular apps in existence.
[1]: https://www.youtube.com/watch?v=62RvRQuMVyg
[1]: https://www.youtube.com/watch?v=62RvRQuMVyg
I also found https://www.madewithangular.com/#/categories/google. It's a far far far cry from OPs original assertion that 3/4 apps in Google are made of angular.
The Angular team has said over 70% of web apps at Google use Angular, but I can't recall what talks they have said that at off the top of my head. Various members of the Angular team have told me this directy as well, and are pretty open about that fact in general.
One told me about the broken release at one point last year bringing Google to a halt until that got fixed, since Google runs off of the master branch of Angular. Google has a lot of apps, most of them internal (I have seen some external ones too, such as a Nexus site in the past, and Google Domains. Google App Engine and Adwords also use it, as given in talks in the past - the Angular team is grouped under the Ads group within Google). Your original question for proof was completely misguided when accounting for that - examples of external facing apps does not confirm or deny percentage, it was a poorly conceived attack.
Certain apps like Gmail/Inbox go through very long development cycles and have specialized requirements. An Angular team member has explained to me that sometimes some teams think they can do better with vanilla JS - none of the popular web frameworks really met Google's perf/business requirements for those behemoth apps, although with the way Angular 2 is shaping, it likely will hit the bar (the Angular team has managed to get a hello world app smaller than a react-based one, and this is before they extract out the template compiler to allow tree shaking of that for builds - very impressive perf numbers were also thrown at Google I/O last week). Google has a lot of resources they can throw at big consumer facing apps, so they can build homespun frameworks if they need to (for big sites like YouTube, Inbox, Calendar, etc.).
I should also detail that I'm not someone unknowledgable about Angular and how it is used - I am one of the biggest Angular experts outside of Google, a core maintainer of one of the three most largest third party Angular libraries & involved in another top three most used third party library (UI Bootstrap and UI Router, respectively) and a contributor to many projects across the ecosystem. I am very aware of all of the things that are Angular's strengths, and its shortcomings (especially 1, and 2 to a lesser degree...but nobody is really an expert at 2 yet, excepting maybe Tobias Bosch on the Angular 2 team with his crazy work on it).
One told me about the broken release at one point last year bringing Google to a halt until that got fixed, since Google runs off of the master branch of Angular. Google has a lot of apps, most of them internal (I have seen some external ones too, such as a Nexus site in the past, and Google Domains. Google App Engine and Adwords also use it, as given in talks in the past - the Angular team is grouped under the Ads group within Google). Your original question for proof was completely misguided when accounting for that - examples of external facing apps does not confirm or deny percentage, it was a poorly conceived attack.
Certain apps like Gmail/Inbox go through very long development cycles and have specialized requirements. An Angular team member has explained to me that sometimes some teams think they can do better with vanilla JS - none of the popular web frameworks really met Google's perf/business requirements for those behemoth apps, although with the way Angular 2 is shaping, it likely will hit the bar (the Angular team has managed to get a hello world app smaller than a react-based one, and this is before they extract out the template compiler to allow tree shaking of that for builds - very impressive perf numbers were also thrown at Google I/O last week). Google has a lot of resources they can throw at big consumer facing apps, so they can build homespun frameworks if they need to (for big sites like YouTube, Inbox, Calendar, etc.).
I should also detail that I'm not someone unknowledgable about Angular and how it is used - I am one of the biggest Angular experts outside of Google, a core maintainer of one of the three most largest third party Angular libraries & involved in another top three most used third party library (UI Bootstrap and UI Router, respectively) and a contributor to many projects across the ecosystem. I am very aware of all of the things that are Angular's strengths, and its shortcomings (especially 1, and 2 to a lesser degree...but nobody is really an expert at 2 yet, excepting maybe Tobias Bosch on the Angular 2 team with his crazy work on it).
@Bahamut, thanks for your perspective! fwiw, we are big angular users as well. I was only questioning it's usage in Google. I think I now know that it's used a lot more than I thought inside google.
I was going to say "If it's not ad or search, Google will have no trouble killing it off", but this makes it a little bit business critical to Google.
I'd only start worrying if they move that away from Angular.
I'd only start worrying if they move that away from Angular.
I think you're probably right, but at the same time, Google does have a history of killing off projects for reasons that make sense to them but seem kind of arbitrary.
Of course, Angular is OSS and is likely to live on into obsolescence no matter what Google ends up doing with it.
Of course, Angular is OSS and is likely to live on into obsolescence no matter what Google ends up doing with it.
Who do you think will take over Angular when Google kills it off?
Is there any large company or, heck, any somewhat organized group of people outside of Google supporting Angular or using Angular at a scale that warrants the investment of maintaining the project rather than migrating to a different technology?
Is there any large company or, heck, any somewhat organized group of people outside of Google supporting Angular or using Angular at a scale that warrants the investment of maintaining the project rather than migrating to a different technology?
I never thought I'd hear myself say this, but the ASP.NET MVC/IDE is a better ecosystem than Rails now. No more missing bundle x, install devkit x,....just install visual studio 15 and get to work.
As long as you agree with the choices Microsoft makes. If you have a different opinion? Too bad.
The problem is that it basically locks you out of the ecosystem of Linux/Unix and that is significantly larger and more important than the ecosystem of Rails.
Ok. Imagine me a developer just trying to put up an MVP to see if the idea gets traction. Pitch me on why I should rely on a toolchain that has multiple versions, bundles, and a plethora of (possibly) compatible packages vs one ide with autocompletion and a built in package manager that automatically picks the jquery, json, whateverelse-supporting-javascript library I need etc with a single install?
Are you asking me to get you to pick against .NET in favor of Rails/Django/Phoenix/Play/Grails/Laravel/etc?
No, asking which has less external dependencies to get up and going fast.
I suppose this is how you gain fame these days, writing sensational counter-arguments instead of coding? Oh right, the author is a 'Ruby Activist', he couldn't help it. PHP has won, Node has won and now yet another language up to debate? Having something with its own niche and cult doesn't mean anything if it's not suitable for work. It does help populate shortcut-seeking approaches such as Heroku and more CRUD apps than ever before so Rails has its places.
Here's a piece to deflate any ego issues http://www.paulgraham.com/identity.html.
Here's a piece to deflate any ego issues http://www.paulgraham.com/identity.html.
The article you linked is pure gold ;thanks for sharing!
Yeah, such a poignant read that cuts to the heart of the problem - our needs to associate and express.
[deleted]
> Experienced people often forget the learning curve when they were themselves beginners, and at that time Rails was so attractive, so sexy. Remember that feeling? Of accomplishment in the face of the knowledge that some nice witch left super useful black magic behind?
As one of those beginner programmers who had graduated from a development bootcamp, I fell in love with Sinatra much more than I did with Rails. Part of that love may be due to our curriculum...we have to master Sinatra first before you can start learning Rails. But I also liked the finer control that Sinatra provided to me. I suppose you can translate this to the current buzzword jargon of "hating Rails' magic", but writing out simple authentication using Bcrypt is just as much an accomplishment as using the Devise library.
But your bigger point still remains intact. Passion should take a backseat towards choosing the right tool for the job. If you need Wordpress, use Wordpress. If you need Rails, use Rails. And so on and so forth. I may not like a certain tool...in fact, I may hate it, but I should still go ahead and use it anyway. You're here to complete a job. And you should make sure you do it well.
As one of those beginner programmers who had graduated from a development bootcamp, I fell in love with Sinatra much more than I did with Rails. Part of that love may be due to our curriculum...we have to master Sinatra first before you can start learning Rails. But I also liked the finer control that Sinatra provided to me. I suppose you can translate this to the current buzzword jargon of "hating Rails' magic", but writing out simple authentication using Bcrypt is just as much an accomplishment as using the Devise library.
But your bigger point still remains intact. Passion should take a backseat towards choosing the right tool for the job. If you need Wordpress, use Wordpress. If you need Rails, use Rails. And so on and so forth. I may not like a certain tool...in fact, I may hate it, but I should still go ahead and use it anyway. You're here to complete a job. And you should make sure you do it well.
I too like Sinatra but in my time writing Rails for both my day job(s) as well as various consulting gigs, I inevitably see Sinatra apps that start out with the best of intentions but always end up being just a shitty, hand-rolled version of Rails.
The amount of time I hear - Rails, you ain't gonna need it, followed 6 months later by some version of "can we use this library to add a feature which OOTB Rails would have given us if we used it".
What is bloat, and what is a useful feature you haven't quite grown into yet, is all a matter of perspective.
I haven't yet found a project where you know 100% of what you're going to need upfront, so having a bit of depth in the toolbox is serving me well.
What is bloat, and what is a useful feature you haven't quite grown into yet, is all a matter of perspective.
I haven't yet found a project where you know 100% of what you're going to need upfront, so having a bit of depth in the toolbox is serving me well.
Want to hear about an interesting project I heard of recently? Converting a Sinatra crap bomb into a Rails app.
As someone who didn't love Rails until I learned it "the right way", I'd argue that you have to thoroughly understand SQL joins and ActiveRecord before you can even attempt to architect a rails project.
Very few bootcamps get this right, I feel, but a few do.
Very few bootcamps get this right, I feel, but a few do.
Rails was most influential in Rails v1 and v2, and after that it pretty much stagnated. In spite of that, millions of dollars have been spent upgrading Rails apps through subsequent versions, millions spent on developer training, etc.
Sinatra picked up the REST torch from Rails (and from Camping) and sparked a significant change in how web apps are built and a cultural shift from monolithic frameworks to micro-frameworks.
Node and Flask picked up from there, and gathered steam because both the Python and Node dependency management systems are less broken than Rubygems, allowing more practical use of smaller, orthogonal modules.
Now Elm and React are focused on improving the reliability and reducing the incidental complexity of web applications.
Aside from the occasional PR stunt rant from 37 Signals, Rails does not really have a thought leadership role in the development community anymore, aside from a loyal following of career rails programmers, who likely adopted Rails after v3 and would have been just as happy with nearly any monolithic framework and authoritative pundit.
None of this is good or bad. Who knows what the future has in store. Rails pre v3 inspired a lot of the thinking that came after, but has not really embraced any of the ideas that emerged subsequently.
I think the best analogy is Windows. It's a cash cow, it's not going to change quickly, and many people consider it the only sensible tool for the job.
Sinatra picked up the REST torch from Rails (and from Camping) and sparked a significant change in how web apps are built and a cultural shift from monolithic frameworks to micro-frameworks.
Node and Flask picked up from there, and gathered steam because both the Python and Node dependency management systems are less broken than Rubygems, allowing more practical use of smaller, orthogonal modules.
Now Elm and React are focused on improving the reliability and reducing the incidental complexity of web applications.
Aside from the occasional PR stunt rant from 37 Signals, Rails does not really have a thought leadership role in the development community anymore, aside from a loyal following of career rails programmers, who likely adopted Rails after v3 and would have been just as happy with nearly any monolithic framework and authoritative pundit.
None of this is good or bad. Who knows what the future has in store. Rails pre v3 inspired a lot of the thinking that came after, but has not really embraced any of the ideas that emerged subsequently.
I think the best analogy is Windows. It's a cash cow, it's not going to change quickly, and many people consider it the only sensible tool for the job.
Nice read. I understand the sentiment but I find the "win declaration" a bit too weird.
How can one say "Rails won"? It's not like people will stop making web frameworks. Like any other software it will eventually be made obsolete by something newer and better.
Maybe I am just nitpicking.
How can one say "Rails won"? It's not like people will stop making web frameworks. Like any other software it will eventually be made obsolete by something newer and better.
Maybe I am just nitpicking.
Yeah, I found that weird. However, if I think deeply about it, given the move to micro-services and soa type architectures I can see elixir winning longer term which is really railsy. regardless, rails has a ton of influence and some great usecases, but I would say nodejs is about as vogue as rails was and will dominate for another several years.
as a nodejs dev, it is super annoying managing the asynchornicity of node and the horrifying dependencies. I suppose rails had stability issues as well. If you read rails is a ghetto by zed shaw, it is interesting (albeit super biased) look at how and why rails developed.
edit: As noted, elixir isn't comparable to rails the framework in that arena is phoenix which is similar (at least in function). Thanks!.
as a nodejs dev, it is super annoying managing the asynchornicity of node and the horrifying dependencies. I suppose rails had stability issues as well. If you read rails is a ghetto by zed shaw, it is interesting (albeit super biased) look at how and why rails developed.
edit: As noted, elixir isn't comparable to rails the framework in that arena is phoenix which is similar (at least in function). Thanks!.
I think the "Rails won" sentiment is that 90% of the time, when you talk about a "Ruby job", it's a "Ruby on Rails" job. Not always, but the vast majority of the time.
Now, that doesn't apply to any language other than Ruby. But this post might well be aimed at Rubyists exclusively.
Now, that doesn't apply to any language other than Ruby. But this post might well be aimed at Rubyists exclusively.
Rails won the past. There's a lot of legacy in it that's impractical to replace, which guarantees a sizable community, which makes it viable for new projects, if not always ideal, for quite some time.
It's become what J2EE was when Rails was new. Decades from now, even if it's completely fallen out of favor for new development, there'll be people getting paid handsomely to maintain legacy Rails apps. It's won an important spot in history.
But technology moves on. And just as the Java stack dominant when Rails emerged has lost ground to Rails, other non-Java stacks, and even newer Java stacks, is wire likely Rails will lose ground to other Ruby and non-Ruby stacks.
It's become what J2EE was when Rails was new. Decades from now, even if it's completely fallen out of favor for new development, there'll be people getting paid handsomely to maintain legacy Rails apps. It's won an important spot in history.
But technology moves on. And just as the Java stack dominant when Rails emerged has lost ground to Rails, other non-Java stacks, and even newer Java stacks, is wire likely Rails will lose ground to other Ruby and non-Ruby stacks.
J2EE wasn't even that old when Rails was new - maybe 4 or 5 years? But it offered an optimal path between the Scylla of J2EE architecture astronautism and the Charybdis of PHP spaghetti.
These days, I'm finding a lot of joy in taking parts of a Rails app that feel clunky (meaning they usually aren't Basecamp-like, and I find myself using a lot of magic and config to make it fit a Rails-shaped hole), extracting it out as a stand-alone Sinatra app that uses Sequel instead of ActiveRecord, gemifying it, and then pulling it back into the parent monolith as an engine.
Wow! I didn't know Rails engines can be written in Sinatra/Sequel. Wondering how that works exactly.
Wrap your app in a class (extending Sinatra::Application or Sinatra::Base), require (I gemified it for componentization) then mount in routes:
mount MySinatraApp => '/some_path'
Cool. A quick search landed me on https://robots.thoughtbot.com/how-to-share-a-session-between... it discusses sharing session using config.ru.
Even after using rails for so many years, learning something new every day!
Even after using rails for so many years, learning something new every day!
> The most important change of all: 2010 saw the advent of the Walled Garden App Store, commercially available native applications for smartphone and tablets. Forget web development: mobile was getting it all.
This is the real elephant in the room. Everyone is looking for the "next Rails." There will be no "next Rails" because the web is not what it was when Rails came out. It's not "dead" or "dying," but it is just not the same.
> Experienced people often forget the learning curve when they were themselves beginners, and at that time Rails was so attractive, so sexy.
I always like to say Rails is for those kids who used to read the players' guides and instruction manuals for video games first, so they know all the secret moves and bonus areas before they even start playing.
Some people prefer the challenge and power of discovering and designing things on their own, and they are never going to enjoy Rails because they'll be too caught up negotiating with themselves about how they would have done it.
This is the real elephant in the room. Everyone is looking for the "next Rails." There will be no "next Rails" because the web is not what it was when Rails came out. It's not "dead" or "dying," but it is just not the same.
> Experienced people often forget the learning curve when they were themselves beginners, and at that time Rails was so attractive, so sexy.
I always like to say Rails is for those kids who used to read the players' guides and instruction manuals for video games first, so they know all the secret moves and bonus areas before they even start playing.
Some people prefer the challenge and power of discovering and designing things on their own, and they are never going to enjoy Rails because they'll be too caught up negotiating with themselves about how they would have done it.
If we are talking about frameworks, I believe Padrino is a much better designed framework than Rails. It doesn't have any magic of Rails and architected in a very elegant way. I just can't tolerate ActiveRecord, so Padrino having Sequel support out of the box was definitely an important step in going away from Rails. Also being built on top of Sinatra, it is also much lighter and faster than Rails, another huge reason to switch.
Yes Rails wins the popularity contest, but it doesn't mean it's the best thing for Ruby.
Yes Rails wins the popularity contest, but it doesn't mean it's the best thing for Ruby.
I'd agree that the initial approach of Rails is becoming dated but Rails is quickly moving away from this. Consider Rails 5. Native web sockets and an API mode make Rails an excellent backend for JS apps. You fail to recognize the evolution of the framework and where it continues to fit in today. If you're done with Rails it's probably because you failed to evolve with the framework.
[deleted]
"Basecamp-like apps are not too difficult to make, at least in terms of architecture. You don't need fancy super performant languages with super duper highly concurrent and parallel primitives. Also a reality is that 80% of the web applications are Basecamp-like (disclosure: my feelings for years of experience in consulting)."
Someone once wrote something like, "An engineer is a person who can do for $1.50 what any damn fool can do for $5.00."
I admit I don't actually have much experience with Rails itself; we had a couple of Rails apps that, after a couple of months of painful deployment and uptime teething, we moved to JRuby running on the same architecture as the rest of our apps. Then, after a couple of years of deferred maintenance and no updates (and a long list of security vulnerabilities) we rewrote them as plain, no framework, no ORM, Java and Javascript.
But this quote rubs me the wrong way. Building small to medium web apps is what we do. A lot. We ought to be able to build them cheaply and quickly. But we also ought to be able to build them to be efficient and to not waste resources unnecessarily.
In my experience, Rails succeeded because it's easy to go from nothing to a demoable proof of concept. And the Rails environment succeeded because it's possible to teach someone up from nothing to building a pretty application in six weeks.
So why are we still fascinated with a tool that makes something easy that wasn't hard to begin with? That makes the first 10% trivial while leaving the other 90% alone, if not making it harder? That is optimized for the wrong thing?
And it soaks up resources like crazy?
Someone once wrote something like, "An engineer is a person who can do for $1.50 what any damn fool can do for $5.00."
I admit I don't actually have much experience with Rails itself; we had a couple of Rails apps that, after a couple of months of painful deployment and uptime teething, we moved to JRuby running on the same architecture as the rest of our apps. Then, after a couple of years of deferred maintenance and no updates (and a long list of security vulnerabilities) we rewrote them as plain, no framework, no ORM, Java and Javascript.
But this quote rubs me the wrong way. Building small to medium web apps is what we do. A lot. We ought to be able to build them cheaply and quickly. But we also ought to be able to build them to be efficient and to not waste resources unnecessarily.
In my experience, Rails succeeded because it's easy to go from nothing to a demoable proof of concept. And the Rails environment succeeded because it's possible to teach someone up from nothing to building a pretty application in six weeks.
So why are we still fascinated with a tool that makes something easy that wasn't hard to begin with? That makes the first 10% trivial while leaving the other 90% alone, if not making it harder? That is optimized for the wrong thing?
And it soaks up resources like crazy?
Watching the Google IO keynote, I couldn't help noticing that their new instant apps could be accomplished in open webtools if they would have focused on browser integrations rather than native apps. I hope this doesn't mean native apps are shutting the door on the original idea of pure webapps ( remember that iPhone 1 keynote? ). I think it would take a major new platform doing exclusive html5/css3/js first and only to shift the paradigm. Then, follow that up with mobile browser improvements to make payments, contacts, hardware integrations better and we'd be on our way. Anyone know of a good app that is web only? Unfortunately, I think as native apps continue to dominate, there will be less incentive to build out mobile browser integration with open web platforms.
[deleted]
As a rails / startup guy, I can run circles around developers who are using Node/Angular/React/etc. The huge open source community with the infinite number of gems and massive volume of documentation accumulated over years is unparalleled. Sure, Rails may eventually be eclipsed but I see no reason to switch now when my immediate goal is to ship fast with intense speed and fast iteration while focusing on the much more pressing business validation and business objectives of my company. Just my two cents on the topic.
Where there is a need for dynamic languages, Ruby can be a good fit. For example, Ruby is used in devops world where there is a bit of a split between Ruby and Python. It's very short sighted to think that Ruby has no future.
I haven't used rails in about 3 years (when I first started programming) and I only built 1 application which was a super shitty weekend instagram clone that didn't really work well. I didn't want to use rails anymore because it didn't feel like programming and nodeJS was getting hot.
The thing is, I knew fuck all about programming then and now, I have the luxury of knowing very slightly less than fuck all. Which gives me the perspective that this article has, rails is pretty fucking awesome for building a crud application that uses a relational datastore. The author indicated ~80%.
Wordpress is also something I swore off when I was learning because it straight up wasn't programming. I installed wordpress on a server for the first time last week to setup a blog. I browsed a few thousand themes, it took me a while to find a theme for a blog. The just a blogging platform is actually more ironic now, than it ever was.
So, I agree with the author the design patterns shape the community and then the community shapes the design patterns. You can pretty much build any type of app with any language if you are motivated and talented, however, from my observation, the following languages seem to give you the highest leverage in the domains the community has evolved them for:
PHP/Wordpress: Blogging sites & CMS building.
Node/JS: Applications and APIs typically with a noSQL database.
Ruby/Rails: Building CRUD apps with relational datastores.
Python: Data intensive applications & programming.
erlang/elixir: Never used this, but seems ideal for highly scalable concurrent architecture and highly scalable process choreography.
So in essence, I agree with the author. I would love to switch from node to Rails as I like the framework aspect where you can just get productive super quick. I also see rails as going away, so I wouldn't make the time investment. I think learning node was the right thing to do ~3 years ago, but I wish I spent another 6 months using rails and got really comfortable with it first.
> This is not serious programming/you aren't a serious programmer
fairplay. I am a jr. web developer, explaining my conception of some frameworks/communities/languages, so I agree with you that I am not a particularly talented programmer (it isn't my core skillset) and I am not solving hard problems in this arena(as I don't conetend that I am). I disagree that I claimed any of the above was my definition of serious programming. Of the hard problems I will work on/what I think needs to be solved, I have spoken of at length elsewhere.
The thing is, I knew fuck all about programming then and now, I have the luxury of knowing very slightly less than fuck all. Which gives me the perspective that this article has, rails is pretty fucking awesome for building a crud application that uses a relational datastore. The author indicated ~80%.
Wordpress is also something I swore off when I was learning because it straight up wasn't programming. I installed wordpress on a server for the first time last week to setup a blog. I browsed a few thousand themes, it took me a while to find a theme for a blog. The just a blogging platform is actually more ironic now, than it ever was.
So, I agree with the author the design patterns shape the community and then the community shapes the design patterns. You can pretty much build any type of app with any language if you are motivated and talented, however, from my observation, the following languages seem to give you the highest leverage in the domains the community has evolved them for:
PHP/Wordpress: Blogging sites & CMS building.
Node/JS: Applications and APIs typically with a noSQL database.
Ruby/Rails: Building CRUD apps with relational datastores.
Python: Data intensive applications & programming.
erlang/elixir: Never used this, but seems ideal for highly scalable concurrent architecture and highly scalable process choreography.
So in essence, I agree with the author. I would love to switch from node to Rails as I like the framework aspect where you can just get productive super quick. I also see rails as going away, so I wouldn't make the time investment. I think learning node was the right thing to do ~3 years ago, but I wish I spent another 6 months using rails and got really comfortable with it first.
> This is not serious programming/you aren't a serious programmer
fairplay. I am a jr. web developer, explaining my conception of some frameworks/communities/languages, so I agree with you that I am not a particularly talented programmer (it isn't my core skillset) and I am not solving hard problems in this arena(as I don't conetend that I am). I disagree that I claimed any of the above was my definition of serious programming. Of the hard problems I will work on/what I think needs to be solved, I have spoken of at length elsewhere.
> I didn't want to use rails anymore because it didn't feel like programming and nodeJS was getting hot.
> Wordpress is also something I swore off when I was learning because it straight up wasn't programming
> Python: Data intensive applications & programming.
I would love to hear your definition of programming.
> Wordpress is also something I swore off when I was learning because it straight up wasn't programming
> Python: Data intensive applications & programming.
I would love to hear your definition of programming.
I still sort of stand by those statements, but again that was based on a beginners completely incorrect view of the world. However, to add a bit more color to those statements which maybe you can infer how I think about programming? I meant something like:
Rails/Ruby was very popular bit it was a framework. You could do a massive amount with very little work. You could build an entire app without any knowledge of what Rails did for you under the hood. NodeJS was a developing technology of which I could gain massive leverage, both learning why asynchronous processes work(I still have trouble with these)/general programming concepts as well as double down on a front end language. The v8 compiler and ryan dahl seemed to provide a good avenue for which to learn lower level(at least than rails) about programming and it seemed to embody the unix philosophy. This seemed like a good place to be and I could grow within a community that was going to be influential. HTML, CSS and SCSS were pretty easy to learn, so by learning a single database technology and javascript I could be a full-stack developer. Not in the sense of how I would market myself, but that I could go out and build a full application if I wanted to and that was poweful and awesome from a learning experience. Given the proliferation of nosql The database, front-end, orm, and back-end were entirely javascript so I didn't pay a high context switching penalty.
wordpress: I dislike wordpress. I don't think it would make any sense to tell someone interested in programming front or back end software to learn "wordpress". Wordpress is a great convenience for setting up a blog, but I presume they have a CMS as well. I don't know much about it, only doing the most basic PHP stuff, but PHP & Wordpress seem to be synonymous with client facing software that requires a CMS/non-technical user to make updates.
python. I mean, python at least from my understanding is a great language for processing data. It is why tensorflow ships as a python library and numpy is used for a lot of data work. The communities using R and python work with data at scale and thus those communities have developed a lot of tooling to accomplish this, not that this stuff needs to be done in python, but machine learning, textual parsing and classification libraries and some NLP stuff all seem to hit python first. However, oython does have a great community writing secure applications. Django and Flask, sqlalchemy ORM as well as zeroDB exist and there are communities using python for apps, data parsing, and microservice deployments.
However, I define prgramming (like most people) as a schedule of television or radio broadcasts.
Rails/Ruby was very popular bit it was a framework. You could do a massive amount with very little work. You could build an entire app without any knowledge of what Rails did for you under the hood. NodeJS was a developing technology of which I could gain massive leverage, both learning why asynchronous processes work(I still have trouble with these)/general programming concepts as well as double down on a front end language. The v8 compiler and ryan dahl seemed to provide a good avenue for which to learn lower level(at least than rails) about programming and it seemed to embody the unix philosophy. This seemed like a good place to be and I could grow within a community that was going to be influential. HTML, CSS and SCSS were pretty easy to learn, so by learning a single database technology and javascript I could be a full-stack developer. Not in the sense of how I would market myself, but that I could go out and build a full application if I wanted to and that was poweful and awesome from a learning experience. Given the proliferation of nosql The database, front-end, orm, and back-end were entirely javascript so I didn't pay a high context switching penalty.
wordpress: I dislike wordpress. I don't think it would make any sense to tell someone interested in programming front or back end software to learn "wordpress". Wordpress is a great convenience for setting up a blog, but I presume they have a CMS as well. I don't know much about it, only doing the most basic PHP stuff, but PHP & Wordpress seem to be synonymous with client facing software that requires a CMS/non-technical user to make updates.
python. I mean, python at least from my understanding is a great language for processing data. It is why tensorflow ships as a python library and numpy is used for a lot of data work. The communities using R and python work with data at scale and thus those communities have developed a lot of tooling to accomplish this, not that this stuff needs to be done in python, but machine learning, textual parsing and classification libraries and some NLP stuff all seem to hit python first. However, oython does have a great community writing secure applications. Django and Flask, sqlalchemy ORM as well as zeroDB exist and there are communities using python for apps, data parsing, and microservice deployments.
However, I define prgramming (like most people) as a schedule of television or radio broadcasts.
It sounds like you are just trying to justify your decision for Node. I use Node and Rails in production for different products/services. They both serve different purposes well.
"Going away" was said about .NET and PHP and they don't seem to be going anywhere, albeit they are less popular than they use to be.
Too many discussions on HN have this paranoia lurking around of whether or not "I chose the right path". I find it unhealthy, and find that the longer life of a product exposes the weaknesses of any language/framework.
"Going away" was said about .NET and PHP and they don't seem to be going anywhere, albeit they are less popular than they use to be.
Too many discussions on HN have this paranoia lurking around of whether or not "I chose the right path". I find it unhealthy, and find that the longer life of a product exposes the weaknesses of any language/framework.
Language/framework fads are just that, momentary fads.
I believe that, in the long term, things like good architecture, sane dependency management, well-managed life cycle (which includes provisioning and deployment) are far more important than the language/framework you are using.
You may not like PHP, for example, but I would still choose to work on a good quality PHP project than a bad one in the latest flashy language/framework, any day.
I don't know. I just ripped out basically half the rug under my Scala app and put in a new one without the rest even noticing. It's not a very good architecture I don't think, but because of flashy language features like generics that are often dismissed as unimportant or even an impediment "in the real world", I was able to change a core part of the code that basically everything else touches and still be sure that everything works exactly as before once the code compiles again.
I don't want to dismiss the importance of certain language features. I'm just saying that any Turing-complete language with a reasonable ecosystem is good enough in most situations (where good enough != perfect but hey, perfection is the enemy of the good!).
Again, I am not trying to justify my decision, I think if you asked most developers to give advice to a kid learning programming 3 years ago how to get started(with the benefit of 3 years glance into the future) they would probably lean towards node if it was between nodejs v ruby.
However, I totally agree that the longer life of a product exposes the weaknesses of any language/framework. and there are multiple paths. Just that, if you want to get good at writing software you probably need to pick a starter language with a versatile community. People still write cobol, and wherever there is code in production, there will be demand for a language, but .NET and PHP are probably not growing in demand. I actually don't know about .NET tbh.
However, there is such thing as choosing a path as, without extensive time investment, skill and knowledgebase, it would be difficult to be a truly capable python, .NET, javascript and rails dev.
It would be wise to be capable in those languages, but to be a master or attempt mastery of the one most likely to embody your interests/career would likely be a better move than being able to be less than mediocre in numerous languages. I think we are largely in agreement, and I hope I didn;t mischarachterize you.
I think rails is cool, and I now regret not learning it as I do like the scaffolding nature and I am sure I could pick it back up quickly, I just do not have a need to right now. Elixir looks super cool though and if I do learn a new language that is markedly different it is a toss up between Go and Elixir. I am messing around with python right now, but javascript and ruby are pretty similar, and pyton seems fairly similar. A functional language or a compiled language will be a radical departure from what I am used to.
However, I totally agree that the longer life of a product exposes the weaknesses of any language/framework. and there are multiple paths. Just that, if you want to get good at writing software you probably need to pick a starter language with a versatile community. People still write cobol, and wherever there is code in production, there will be demand for a language, but .NET and PHP are probably not growing in demand. I actually don't know about .NET tbh.
However, there is such thing as choosing a path as, without extensive time investment, skill and knowledgebase, it would be difficult to be a truly capable python, .NET, javascript and rails dev.
It would be wise to be capable in those languages, but to be a master or attempt mastery of the one most likely to embody your interests/career would likely be a better move than being able to be less than mediocre in numerous languages. I think we are largely in agreement, and I hope I didn;t mischarachterize you.
I think rails is cool, and I now regret not learning it as I do like the scaffolding nature and I am sure I could pick it back up quickly, I just do not have a need to right now. Elixir looks super cool though and if I do learn a new language that is markedly different it is a toss up between Go and Elixir. I am messing around with python right now, but javascript and ruby are pretty similar, and pyton seems fairly similar. A functional language or a compiled language will be a radical departure from what I am used to.
.NET is alive and well.
Enterprise only cares about Java and .NET as standard backend stacks, regardless of the technology of the day HN posts how everyone is doing Go and node.js.
Enterprise only cares about Java and .NET as standard backend stacks, regardless of the technology of the day HN posts how everyone is doing Go and node.js.
i actually have been interested in Java because apache has open sourced what seems to be the best collection of resources on the internet and they are almost entirely written in java for the java ecosystem. I also think I would learn a massive amount. I also am strongly considering Java and less strongly C. What are your thoughts on Java in terms of:
* How much it would teach me about programming/software design, e.g. just as a general learning excercise?
* What does Java lend itself best to/is a typical set of programs a beginner could build after say 1 month?
* Is google planning on phasing Java out and using Go?
* How much it would teach me about programming/software design, e.g. just as a general learning excercise?
* What does Java lend itself best to/is a typical set of programs a beginner could build after say 1 month?
* Is google planning on phasing Java out and using Go?
1. Java has had huge amounts of open source code for years. (Case in point: course provider sales representative telling my colleague somewhat annoyed that Java people are the worst because "they are used to get everything for free.)
2. Im going to read that as "... 1 month after finishing studies".
I will recommend starting somewhere where you get good colleagues. When I finished school I was sure I could never work with Java: it was hard and unforgiving compared to VB and PHP that I had picked up on my own.
After getting introduced to ides and working build systems however I was starting to get work done within a week and within a year I was confident enough to make a real difference.
Also I picked up a feel for just how annoying it is to be left with maintaining code based on abandoned commercial tools (old Delphi code).
3. No idea, but IMO no way banks are leaving it anytime soon so plenty of jobs and momentum for the next few years:-)
2. Im going to read that as "... 1 month after finishing studies".
I will recommend starting somewhere where you get good colleagues. When I finished school I was sure I could never work with Java: it was hard and unforgiving compared to VB and PHP that I had picked up on my own.
After getting introduced to ides and working build systems however I was starting to get work done within a week and within a year I was confident enough to make a real difference.
Also I picked up a feel for just how annoying it is to be left with maintaining code based on abandoned commercial tools (old Delphi code).
3. No idea, but IMO no way banks are leaving it anytime soon so plenty of jobs and momentum for the next few years:-)
I mean, could I teach myself Java and build something interesting in a month. Sounds like a no?
Depends on you as well as your definition of interesting.
I'd say you should start in a good team anyway because real life experience IMO is crucial and getting on a good team is a way of getting it fast and as painless as possible (I.E. without breaking your bank.)
If you just want to make "something" go with whatever is less friction for you (for me it was php), just be prepared that there will be friction in any language as soon as you step outside of the tutorials.
Also keep in mind that if you get a good job you can do quite a lot on your spare time. I used to code a utility program in php while commuting. It never became a commercial success but a rewritten version became a major hit with the church I belong to, was maintained and in use for years and gave me both experience in sw architecture as well as bragging rights in job interviews for several years. (Oh and it totally helped in getting my head ready for my paid work in the morning as well as unwinding after work.)
But I also think Java has come a far way towards beginner-friendly. If you do just accept that in Java land IDEs are a must. Getting used to IDEs was were Java "clicked" for me. Use either Netbeans (all features free, my preferred choice), IntelliJ (lots of features free) or Eclipse (all features you'll ever want is free but takes some getting used to, I would never picked it as my first IDE if it wasn't the preferred choice on my first team and they where happy to help me up to speed.) And dismiss everyone who tells you that one of them is crap or way better: it is just a matter of preference in most cases. (Notable exception: android development where IntelliJ is the officially supported alternative.)
Also learn to use Maven or gradle.
I'd say you should start in a good team anyway because real life experience IMO is crucial and getting on a good team is a way of getting it fast and as painless as possible (I.E. without breaking your bank.)
If you just want to make "something" go with whatever is less friction for you (for me it was php), just be prepared that there will be friction in any language as soon as you step outside of the tutorials.
Also keep in mind that if you get a good job you can do quite a lot on your spare time. I used to code a utility program in php while commuting. It never became a commercial success but a rewritten version became a major hit with the church I belong to, was maintained and in use for years and gave me both experience in sw architecture as well as bragging rights in job interviews for several years. (Oh and it totally helped in getting my head ready for my paid work in the morning as well as unwinding after work.)
But I also think Java has come a far way towards beginner-friendly. If you do just accept that in Java land IDEs are a must. Getting used to IDEs was were Java "clicked" for me. Use either Netbeans (all features free, my preferred choice), IntelliJ (lots of features free) or Eclipse (all features you'll ever want is free but takes some getting used to, I would never picked it as my first IDE if it wasn't the preferred choice on my first team and they where happy to help me up to speed.) And dismiss everyone who tells you that one of them is crap or way better: it is just a matter of preference in most cases. (Notable exception: android development where IntelliJ is the officially supported alternative.)
Also learn to use Maven or gradle.
Java might have its issues, but it is one of the languages with best tools available.
For example, most languages eco-systems lack tooling like VisualVM, Mission Control, JITWatch on their canonical implementations.
https://visualvm.java.net/
http://www.oracle.com/technetwork/java/javaseproducts/missio...
https://github.com/AdoptOpenJDK/jitwatch
Also note that although many seem to be focused on Java being Oracle JVM or OpenJDK, there is a pleothora of JDKs both open source and commercial to choose from. With many other features.
For example, most commercial JDKs support AOT compilation to native code.
Or targeting micro-controllers with a few hundred KBs.
Also Java gets bashed by being all about a specific OO model, but VB.NET, C#, Eiffel, Smalltalk follow exactly the same model.
> Is google planning on phasing Java out and using Go?
Until they embrace Go in Android, ChromeOS, their Google Developer SDKs and Google IO sessions, I would say no.
For example, most languages eco-systems lack tooling like VisualVM, Mission Control, JITWatch on their canonical implementations.
https://visualvm.java.net/
http://www.oracle.com/technetwork/java/javaseproducts/missio...
https://github.com/AdoptOpenJDK/jitwatch
Also note that although many seem to be focused on Java being Oracle JVM or OpenJDK, there is a pleothora of JDKs both open source and commercial to choose from. With many other features.
For example, most commercial JDKs support AOT compilation to native code.
Or targeting micro-controllers with a few hundred KBs.
Also Java gets bashed by being all about a specific OO model, but VB.NET, C#, Eiffel, Smalltalk follow exactly the same model.
> Is google planning on phasing Java out and using Go?
Until they embrace Go in Android, ChromeOS, their Google Developer SDKs and Google IO sessions, I would say no.
In 2001, I learned Java on my own from Java 2 Complete Reference without an Internet Connection. It took more than a month. But I have been building lots of intersting stuff with it since then. I think learning Java was one of the best decisions I ever took.
Great thing about Java is that it lets you solve wide variety of problems, right from Mobile, to Desktop to Big Data. For Machine Learning, Image Processing, some of the best libraries and SDKs are available in Java.
It's a good skill to know which I recommend to all new programmers. One important thing I like about Java is that it's low on features and it's possible to master almost all aspects of the language in relatively short period. This is not possibles with languages like C++, C# and Swift. I think simplicity is one of the reason Java and Go are popular.
Great thing about Java is that it lets you solve wide variety of problems, right from Mobile, to Desktop to Big Data. For Machine Learning, Image Processing, some of the best libraries and SDKs are available in Java.
It's a good skill to know which I recommend to all new programmers. One important thing I like about Java is that it's low on features and it's possible to master almost all aspects of the language in relatively short period. This is not possibles with languages like C++, C# and Swift. I think simplicity is one of the reason Java and Go are popular.
1. My beginners class in Uni taught Java for the 101/102 sequence, so as far as that goes you can use it to implement most beginners projects just fine. It even compiles to something if you want to deal with that experience.
2. I'd say the set of programs can be pretty sparse in that it doesn't tend to play well with its native computer environments (partially be design), so it's more work to generate stuff with a GUI, somewhat more work to handle CLI programs (but not that much more), and it has an interesting set of web tools that have hopefully been updated in the 8+ years since I played with them.
3. I have no idea what Google is doing, but it doesn't matter as Java will live a very long life in Enterprise land if nothing else.
2. I'd say the set of programs can be pretty sparse in that it doesn't tend to play well with its native computer environments (partially be design), so it's more work to generate stuff with a GUI, somewhat more work to handle CLI programs (but not that much more), and it has an interesting set of web tools that have hopefully been updated in the 8+ years since I played with them.
3. I have no idea what Google is doing, but it doesn't matter as Java will live a very long life in Enterprise land if nothing else.
So when you tell people that 3 years down the road the package ecosystem mess is going to be so bad that a package containing a one-line function broke half of the internet, they would go ahead and pick that technology to learn? Oh buddy.... say it aint so.
[deleted]
> erlang/elixir: Never used this, but seems ideal for highly scalable concurrent architecture and highly scalable process choreography.
Erlang's primary reason for existence is fault tolerance. High concurrency and scalability is just a bonus. Consider hot code reloading, supervision trees, links and monitors, D/ETS and Mnesia, location-agnostic message passing. These have nothing to do with scalability. You use Erlang when you absolutely have to have the system continue to work 24/7/365 in perpetuity even in the presence of software errors.
Erlang's primary reason for existence is fault tolerance. High concurrency and scalability is just a bonus. Consider hot code reloading, supervision trees, links and monitors, D/ETS and Mnesia, location-agnostic message passing. These have nothing to do with scalability. You use Erlang when you absolutely have to have the system continue to work 24/7/365 in perpetuity even in the presence of software errors.
> Rails can now be considered a "problem" for the very same reasons that made it popular in the first place. And this is bound to happen to any technology.
so, we won't be jobless anytime soon.
so, we won't be jobless anytime soon.
Why can't ruby?
http://poignant.guide/book/chapter-7.html
There’s a lot of personification and anthropomorphism of technology in this piece that distracts. Use the best tool for the job.
Agreed, but I'll just point out that works both ways. Devs "identify" with their default tool of choice, and too many coulda-been-GREAT tools try to be the Swiss Army Nuclear Ginsu Chainsaw of Code rather than the sweet hammer they started out as. Sometimes this happens to dominant tools in a category (such as Rails within Ruby); other times, it's happened to entire languages (PHP, VB, and many others; I once had to maintain a terminal emulator written in COBOL.)
As Larry Wall and countless others have noted, great programmers are creatively lazy. Mediocre-to-average devs are lazy in less creative ways, like sticking to one language/toolchain for years and not diversifying. Anything that lives, including your career, either grows or it dies. Anything that grows within an impenetrable walled garden will eventually crush itself to death within those walls. It's sad when I see people do that to their careers, and over nearly 40 years in this craft, I've had ringside seats to multiple such bouts.
As Larry Wall and countless others have noted, great programmers are creatively lazy. Mediocre-to-average devs are lazy in less creative ways, like sticking to one language/toolchain for years and not diversifying. Anything that lives, including your career, either grows or it dies. Anything that grows within an impenetrable walled garden will eventually crush itself to death within those walls. It's sad when I see people do that to their careers, and over nearly 40 years in this craft, I've had ringside seats to multiple such bouts.
[deleted]
I'm sure I'm going to get piled on here, but whatever. I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it. "This framework's the best!" "No, this one is obviously better!" "My design pattern is better than your design pattern!"
I don't know, maybe I'm a 32 year old curmudgeon, but I just don't see this in my area. I work at a lower level; robotics, image processing/analysis, and general systems level stuff. We worry about what technologies we use for a given task as far as it impacts our design goals, i.e., "which technology is best suited for the job" (and there are more options nowadays than there used to be). Our customers couldn't care less about how we got there as long as the final product kicks ass.
Once we arrive at a conclusion we move on and spend the remaining 99% of development solving actual problems. Hard problems. Often times unsolved problems. Our number one priority is reliability and accuracy (ok, that's two priorities). Whether or not we used e.g. C++ or Python to do it is irrelevant. What matters is that we built a system which works as it is supposed to and was engineered correctly.
I don't understand this 'programming for programming's sake' mentality. At the end of the day these are just tools, not an end goal. Help me to understand.
I don't know, maybe I'm a 32 year old curmudgeon, but I just don't see this in my area. I work at a lower level; robotics, image processing/analysis, and general systems level stuff. We worry about what technologies we use for a given task as far as it impacts our design goals, i.e., "which technology is best suited for the job" (and there are more options nowadays than there used to be). Our customers couldn't care less about how we got there as long as the final product kicks ass.
Once we arrive at a conclusion we move on and spend the remaining 99% of development solving actual problems. Hard problems. Often times unsolved problems. Our number one priority is reliability and accuracy (ok, that's two priorities). Whether or not we used e.g. C++ or Python to do it is irrelevant. What matters is that we built a system which works as it is supposed to and was engineered correctly.
I don't understand this 'programming for programming's sake' mentality. At the end of the day these are just tools, not an end goal. Help me to understand.
> Help me to understand.
Human nature, maybe?
People seem to like to form groups based on some random similarity (supporting the same football team, driving the same car model, believing in the same religion, being of the same race, etc..) and start fighting the opposite groups.
My favorite example is the following trivia from the "Planet of the Apes" movie:
"During breaks in filming, actors made up as different ape species tended to hang out together, gorillas with gorillas, orangutans with orangutans, chimps with chimps. It wasn't required, it just naturally happened."
Human nature, maybe?
People seem to like to form groups based on some random similarity (supporting the same football team, driving the same car model, believing in the same religion, being of the same race, etc..) and start fighting the opposite groups.
My favorite example is the following trivia from the "Planet of the Apes" movie:
"During breaks in filming, actors made up as different ape species tended to hang out together, gorillas with gorillas, orangutans with orangutans, chimps with chimps. It wasn't required, it just naturally happened."
Fair enough, I just wish those same people would spend more of their time building the next big thing instead of telling others how they use the current big thing.
Let me explain. You are looking from the outside at a community which has a lot of issues around languages, tooling and frameworks for complex historical and technical reasons. E.g. Things that developed over long periods of time, like desktop apps, had to be rebuilt in the browser in a decade. Ask any desktop application developer how fun they think client side web dev is in comparison. And you are then assuming that the difficulties of this community are because they are immature and not as wise as you. Hope that clarifies things.
>Hope that clarifies things
No, not really, and I don't think I assumed that at all. I think it is objectively true that debating the merits of e.g. Python v Ruby for years on end is an utter waste of time. This is not engineering, it's vanity. I can get behind the occasional spirited debate. Of course there are pros and cons to every tool, and we should know what those are, but at the end of the day that's all they are; tools. They're middle men in the problem solving process, not the end result.
BTW, your current web protocols and frameworks are going to change again, just like your decrepit old desktop technologies did. Be prepared to denounce your current toolset and fervently embrace another in the near future.
No, not really, and I don't think I assumed that at all. I think it is objectively true that debating the merits of e.g. Python v Ruby for years on end is an utter waste of time. This is not engineering, it's vanity. I can get behind the occasional spirited debate. Of course there are pros and cons to every tool, and we should know what those are, but at the end of the day that's all they are; tools. They're middle men in the problem solving process, not the end result.
BTW, your current web protocols and frameworks are going to change again, just like your decrepit old desktop technologies did. Be prepared to denounce your current toolset and fervently embrace another in the near future.
I think it 's because of the number of young/unexperienced developers in the field. Those are the ones spending (wasting) a lot of time debating the relative merits of frameworks, languages, editors. More experienced people don't care as much.
>I think it 's because of the number of young/unexperienced developers in the field.
I honestly think this is it. Webdev has an inordinate amount of "let's rewrite it... again!" But the thing that really cinched the webdev community isn't ready for primetime was the whole left-pad debacle. Auto updating of dependencies is bush league bullshit, and the whole rotten edifice came predictably crashing down because of it.
I honestly think this is it. Webdev has an inordinate amount of "let's rewrite it... again!" But the thing that really cinched the webdev community isn't ready for primetime was the whole left-pad debacle. Auto updating of dependencies is bush league bullshit, and the whole rotten edifice came predictably crashing down because of it.
They are tools, but some tools are more enjoyable for people to work with than others (and we don't agree on which ones), and when you're spending a substantial percentage of your life working with those tools, then working with something you enjoy matters.
For some, the tools they work with doesn't matter or doesn't affect their enjoyment. Great for them. But for me it does. Working in a language or with a framework I don't like is a constant stress factor because I keep hitting things that annoy me.
Personally, I don't touch Python projects if I can avoid it, for example, because I don't enjoy working with Python. It's got nothing to do with objective issues with it, and everything to do with subjective issues that affect my enjoyment. If I work with something I enjoy, I will be more motivated and put in a better effort, and will overall be happier.
> Be prepared to denounce your current toolset and fervently embrace another in the near future.
Awesome. While I like my current stack, I've changed it many times during my career because I found something I liked better. And sometimes I've had to put my preferences aside and pick something for more pragmatic reasons, and that's ok, but I most of the time have the luxury of being able to turn down work if I don't thnk I'll enjoy it.
For some, the tools they work with doesn't matter or doesn't affect their enjoyment. Great for them. But for me it does. Working in a language or with a framework I don't like is a constant stress factor because I keep hitting things that annoy me.
Personally, I don't touch Python projects if I can avoid it, for example, because I don't enjoy working with Python. It's got nothing to do with objective issues with it, and everything to do with subjective issues that affect my enjoyment. If I work with something I enjoy, I will be more motivated and put in a better effort, and will overall be happier.
> Be prepared to denounce your current toolset and fervently embrace another in the near future.
Awesome. While I like my current stack, I've changed it many times during my career because I found something I liked better. And sometimes I've had to put my preferences aside and pick something for more pragmatic reasons, and that's ok, but I most of the time have the luxury of being able to turn down work if I don't thnk I'll enjoy it.
What is the average number of hours you spend on a given project? Honestly I think part of the reliance and importance placed on frameworks is that a lot of web dev (especially contract/freelance work) is still relatively small projects, stuff between 10-100 hours of work.
So you're almost never spending 99% of your time solving unsolved, hard problems. You're building custom solutions to relatively common but special-snowflake problems. And in that context, you need a framework because in effect you're building a 1000 hour project but only spending 40 hours doing some configuration, customization and polish on top of a framework. Could you spend 1000 hours and build something from scratch and forget a framework? Sure, but no one wants to pay for that. So the framework you use is the giant's shoulders you stand on.
Rails didn't beat PHP and Java for webdev because hipsters think it's cool. It's because developers delivered projects better and faster with Rails, because it lets you spend less time re-solving the same solved problems which still comprise a lot of modern web development.
So you're almost never spending 99% of your time solving unsolved, hard problems. You're building custom solutions to relatively common but special-snowflake problems. And in that context, you need a framework because in effect you're building a 1000 hour project but only spending 40 hours doing some configuration, customization and polish on top of a framework. Could you spend 1000 hours and build something from scratch and forget a framework? Sure, but no one wants to pay for that. So the framework you use is the giant's shoulders you stand on.
Rails didn't beat PHP and Java for webdev because hipsters think it's cool. It's because developers delivered projects better and faster with Rails, because it lets you spend less time re-solving the same solved problems which still comprise a lot of modern web development.
> Rails didn't beat PHP and Java for webdev because hipsters think it's cool.
I despise Ruby, PHP, and Java, but there is no objective argument that Ruby has "beaten" PHP or Java. It hasn't even beaten Python. It's tiny compared to the largest back-end languages.
Edit: evidence below:
- Ruby is used by 0 of the top 15 most-visited sites[1] (Twitter doesn't use it anymore). Java is used by 7 of them. PHP is used by 3.
- Job listings on Indeed asking for Ruby skills are far behind Java and PHP[2].
- W3Techs shows that 82.2% of all websites reporting their backend language are using PHP. Ruby is 0.6%.[3]
- Ruby is not even in the ballpark of Java on Github. It has a similar number of repos as PHP.[4]
1. https://en.wikipedia.org/wiki/Programming_languages_used_in_...
2. http://www.codingdojo.com/blog/9-most-in-demand-programming-...
3. https://w3techs.com/technologies/overview/programming_langua...
4. http://githut.info/
I despise Ruby, PHP, and Java, but there is no objective argument that Ruby has "beaten" PHP or Java. It hasn't even beaten Python. It's tiny compared to the largest back-end languages.
Edit: evidence below:
- Ruby is used by 0 of the top 15 most-visited sites[1] (Twitter doesn't use it anymore). Java is used by 7 of them. PHP is used by 3.
- Job listings on Indeed asking for Ruby skills are far behind Java and PHP[2].
- W3Techs shows that 82.2% of all websites reporting their backend language are using PHP. Ruby is 0.6%.[3]
- Ruby is not even in the ballpark of Java on Github. It has a similar number of repos as PHP.[4]
1. https://en.wikipedia.org/wiki/Programming_languages_used_in_...
2. http://www.codingdojo.com/blog/9-most-in-demand-programming-...
3. https://w3techs.com/technologies/overview/programming_langua...
4. http://githut.info/
As a Ruby developer who gets paid to work with PHP daily, the reason 82.2% of all websites report a PHP backend is because 82.2% of all websites can only afford a PHP backend.
PHP developer salaries lag well behind market average for pretty much the same skillset. The tooling around PHP on the web is a wreck because you get what you pay for. Java isn't that much different -- I see tons of Java jobs I don't want in NYC for $60k wanting 5 years experience.
Who is taking all of these jobs we don't want? More is not necessarily better.
PHP developer salaries lag well behind market average for pretty much the same skillset. The tooling around PHP on the web is a wreck because you get what you pay for. Java isn't that much different -- I see tons of Java jobs I don't want in NYC for $60k wanting 5 years experience.
Who is taking all of these jobs we don't want? More is not necessarily better.
Don't forget the huge number of those 82.2% (is that made up on the spot) websites are likely built on wordpress as well.
~80% is what I've been hearing for a while from various reliable sources so I'd wager it's not far from there.
The real reason PHP is everywhere is because PHP is everywhere. It used to be that the only major host that didn't offer it was Google App Engine but that was resolved ~3 years ago. Since it's everywhere - and the vast majority of people don't care about the technology under the hood - they just choose the first thing that works.
Odds are that's a one-click install of WordPress. They do that. They add their content. Then they move on to their actual business.
Other than software developers, people don't care about the code under their website as long as it a) keeps working and b) no, that's it. Even security is an afterthought for most of these people.
The real reason PHP is everywhere is because PHP is everywhere. It used to be that the only major host that didn't offer it was Google App Engine but that was resolved ~3 years ago. Since it's everywhere - and the vast majority of people don't care about the technology under the hood - they just choose the first thing that works.
Odds are that's a one-click install of WordPress. They do that. They add their content. Then they move on to their actual business.
Other than software developers, people don't care about the code under their website as long as it a) keeps working and b) no, that's it. Even security is an afterthought for most of these people.
I pitch that as a benefit. You get my expensive skills and when I've built it you get a cheap replacement of me for maintenence.
Scala is where it's at for higher paying jobs, I agree PHP and Java are generally low paid because of baggage.
I didn't mean to suggest people shouldn't write Ruby or that one language is better than the others. I was just stating (and backing up) a fact about web programming. Whether you think it's unfortunate, fortunate, or neutral is up to you.
> Ruby is used by 0 of the top 15 most-visited sites
The majority of projects are not the next twitter or facebook, but something with a limited scope to be done as fast as possible
The majority of projects are not the next twitter or facebook, but something with a limited scope to be done as fast as possible
I think you are interpreting it the wrong way (and I don't even mean that you wrongly equate Ruby with Rails).
If you look at the existing web frameworks, how many of those are RoR clones? That's what I see when somebody says "Rails won".
If you look at the existing web frameworks, how many of those are RoR clones? That's what I see when somebody says "Rails won".
I completely agree that Rails (and Rails-inspired frameworks, like Laravel and Sails) has won. I was disagreeing specifically with the assertion that Ruby has beaten PHP or Java.
I don't disagree, but your last point is rather misleading as Java on Github also includes pretty much all Android projects.
All of the different data points are imperfect measurements, which is why I attempted to include many angles.
I wouldn't put much weight on GitHub language stats because there's a lot of duplication, and people check in libraries and tooling (usually JS, it seems) that overwhelm whatever language they're actually using.
>What is the average number of hours you spend on a given project?
That's a fair point; my project plans are usually measured in years, not hours. Of course there is ongoing maintenance, but that's not where I spend most of my time.
I didn't mean to imply that tools aren't important, or that we shouldn't care. We absolutely should care, and I do as well. The difference is that I don't feel the need to spend copious amounts of time defending my tools, or debating their merits with other people who will never agree with me.
I evaluate them, use them, and move on. They are an integral part of my process, but not nearly as important as building something that solves real problems.
It's the same old issue of religion v enthusiasm, belief v fanaticism. That line gets crossed too often and it's just a waste. I think some lose sight of what's important.
That's a fair point; my project plans are usually measured in years, not hours. Of course there is ongoing maintenance, but that's not where I spend most of my time.
I didn't mean to imply that tools aren't important, or that we shouldn't care. We absolutely should care, and I do as well. The difference is that I don't feel the need to spend copious amounts of time defending my tools, or debating their merits with other people who will never agree with me.
I evaluate them, use them, and move on. They are an integral part of my process, but not nearly as important as building something that solves real problems.
It's the same old issue of religion v enthusiasm, belief v fanaticism. That line gets crossed too often and it's just a waste. I think some lose sight of what's important.
Part of the reason it matters more to web developers is that often our clients and employers do care what we use and if we love a particular tool it needs widespread adoption to be able to use it on real work. I have potential clients asking constantly if I can build their project with WordPress or Rails or Drupal or Symphony or whatever else they think is the best. It would be much better if they just came and asked if I could build it and let me help them determine what is the best platform for their project and pre-existing skill set.
Now, sometimes, they have a legitimate need to have it integrate with a larger system and using that tool has external advantages. But most of the time it is just a vague notion that if it is in WordPress it will be easy to use, cause you know, anyone can edit a WordPress site. But when you bolt a hundred plugins and custom business logic into WordPress, it makes no difference that it has any easy blog editor. That should have been a separate project to begin with. Half the time they have built 10% of what they need with a dozen plugins, think they are 90% done and that I can just make the rest of it work. This because someone told them there were plugins that could do everything they needed in WordPress and with WordPress they'd get good SEO.
The point is that if we want to use a particular tool, we better evangelize for it, because clients never want something built in a framework they haven't heard of. It's not even irrational for the clients, since 50% of the time their developers disappear before the project is done and they have to find someone else who can pick it up and finish.
Now, sometimes, they have a legitimate need to have it integrate with a larger system and using that tool has external advantages. But most of the time it is just a vague notion that if it is in WordPress it will be easy to use, cause you know, anyone can edit a WordPress site. But when you bolt a hundred plugins and custom business logic into WordPress, it makes no difference that it has any easy blog editor. That should have been a separate project to begin with. Half the time they have built 10% of what they need with a dozen plugins, think they are 90% done and that I can just make the rest of it work. This because someone told them there were plugins that could do everything they needed in WordPress and with WordPress they'd get good SEO.
The point is that if we want to use a particular tool, we better evangelize for it, because clients never want something built in a framework they haven't heard of. It's not even irrational for the clients, since 50% of the time their developers disappear before the project is done and they have to find someone else who can pick it up and finish.
WordPress is a valid question/option for them if they have a large amount of content they have to add using their marketing staff instead of more expensive developer consultants.
It also is if they don't have a years-long working relationship with you, because who is going to maintain all of this when you're gone? At least if they have to dump your work and build a new theme, they don't have to worry about figuring out a whole new data model (most of the time).
WordPress done the right way uses plugins sparingly to get the job done, outside of obvious ones like Advanced Custom Fields Pro and Post 2 Post Links.
WP isn't bad per-se, it's just the majority of people who work on it (and let's be honest, who built it) are/were rank amateurs.
It also is if they don't have a years-long working relationship with you, because who is going to maintain all of this when you're gone? At least if they have to dump your work and build a new theme, they don't have to worry about figuring out a whole new data model (most of the time).
WordPress done the right way uses plugins sparingly to get the job done, outside of obvious ones like Advanced Custom Fields Pro and Post 2 Post Links.
WP isn't bad per-se, it's just the majority of people who work on it (and let's be honest, who built it) are/were rank amateurs.
> WP isn't bad per-se
From a data standpoint, yes, WP is bad. Really bad. The poor quality code base of WP is only one half of the equation. The other half is the downright awful, novice database schema that ships with it. I've never seen a database schema that is so tightly coupled with the parent application that it essentially hijacks your data into always needing itself simply to extract and render data. WP takes the "relational" out of relational database and flushes it down the toilet. To add to the mess, instead of fixing the rot of its database schema and data handling functionality, WP developers, in their infinite wisdom, merge a woefully incomplete, faux-API system into WP's core, thereby further sealing the door of ever having a clean, thoughtfully designed database that one can access outside of WP and PHP.
From a data standpoint, yes, WP is bad. Really bad. The poor quality code base of WP is only one half of the equation. The other half is the downright awful, novice database schema that ships with it. I've never seen a database schema that is so tightly coupled with the parent application that it essentially hijacks your data into always needing itself simply to extract and render data. WP takes the "relational" out of relational database and flushes it down the toilet. To add to the mess, instead of fixing the rot of its database schema and data handling functionality, WP developers, in their infinite wisdom, merge a woefully incomplete, faux-API system into WP's core, thereby further sealing the door of ever having a clean, thoughtfully designed database that one can access outside of WP and PHP.
@mtbcoder I always thought WordPress's schema issues were a function of it trying to be generic enough that it can accommodate everyones "vision". What are examples of it's "novice database schema"?
it's some bad db choices at core that get multiplied to many other plugins as well. and... sessions in the database - why are they in wp_options? Still to this day that makes no sense to me.
> WordPress done the right way uses plugins sparingly to get the job done, outside of obvious ones like Advanced Custom Fields Pro and Post 2 Post Links.
We don't give credit to how good some plugins are, either.
In my current web app I've had to add user-defined custom fields to a few entities. It's been a nightmare (Symfony2's form library isn't designed with this in mind) and the user experience is nowhere near as nice as ACF.
And for web apps, the user experience is as important as what it does. I wouldn't want to build this application on WordPress, but having components like ACF already present, so I don't have to reinvent the wheel, is making me seriously consider it for the next project.
We don't give credit to how good some plugins are, either.
In my current web app I've had to add user-defined custom fields to a few entities. It's been a nightmare (Symfony2's form library isn't designed with this in mind) and the user experience is nowhere near as nice as ACF.
And for web apps, the user experience is as important as what it does. I wouldn't want to build this application on WordPress, but having components like ACF already present, so I don't have to reinvent the wheel, is making me seriously consider it for the next project.
Yeah, it made me smile when a non-technical friend had narrowed down the choice of languages for the project he wanted to build.
"Python, Java or <something else>" Python and Java are relatively opposite ends of the web dev spectrum, and he didn't code so it was likely based on rants from the programmers around him.
In the end his project failed because he couldn't find any Django devs to continue the project for a relatively low wage. He might have found some PHP devs if he had chosen that.
"Python, Java or <something else>" Python and Java are relatively opposite ends of the web dev spectrum, and he didn't code so it was likely based on rants from the programmers around him.
In the end his project failed because he couldn't find any Django devs to continue the project for a relatively low wage. He might have found some PHP devs if he had chosen that.
We're a small Django shop and I do weigh up this when deciding if we're the best option for a prospective client. If we build them a site then there is a maintenance cost that is potentially higher than there would be with a PHP site.
Of course - the counter-argument is "a good PHP dev is no cheaper and just as hard to find" but for maintenance tasks you might only need an average (or even mediocre) dev - and it's a hell of a lot easier to find an average PHP dev than an average (insert less popular choice here) dev.
Of course - the counter-argument is "a good PHP dev is no cheaper and just as hard to find" but for maintenance tasks you might only need an average (or even mediocre) dev - and it's a hell of a lot easier to find an average PHP dev than an average (insert less popular choice here) dev.
That's all true, and I do "backend" stuff so I'm in the same boat as you, but I think you might still not get the point of the more-projects-faster thing:
To be competitive, web devs need to be working with the most popular framework, which has the most modules which are maintained (for stuff like "log in with facebook" or "publish photo to twitter" or "get weather for visitor's geo-ip location").
All this pre-packaged functionality does require some time to get familiar with, it's an ecosystem on top of a language with many DSLs.
So they need to make their team win, or join the winning team early. Or else they don't feel like they can compete.
It's a really big marketplace for web sites/apps out there, many small businesses get new-from-scratch websites every 2 years or less ... new shiny design drives consumer interest, it's not like they could afford for the old one to be maintainable anyway.
To be competitive, web devs need to be working with the most popular framework, which has the most modules which are maintained (for stuff like "log in with facebook" or "publish photo to twitter" or "get weather for visitor's geo-ip location").
All this pre-packaged functionality does require some time to get familiar with, it's an ecosystem on top of a language with many DSLs.
So they need to make their team win, or join the winning team early. Or else they don't feel like they can compete.
It's a really big marketplace for web sites/apps out there, many small businesses get new-from-scratch websites every 2 years or less ... new shiny design drives consumer interest, it's not like they could afford for the old one to be maintainable anyway.
Your project plan is measured in years?
All the orange crops just froze over from the chills running down the backs of all the Agile\Lean practitioners.
All the orange crops just froze over from the chills running down the backs of all the Agile\Lean practitioners.
Turns out that it is very hard to deliver any hardware project in a purely Agile environment - it lacks the capability for careful delivery of long lead time/critical path items, as well as failing to neatly fit into a sprint.
FTFY: "I don't understand why those who spend most of their time __using tools__ focus so much on the tools they use to do it."
It should be more self-evident now.
When there are many tools which meet the minimum requirements for doing a job, then the focus becomes not on which tool can do the job, but which tool you feel does the job the best (or you enjoy using). Carpenters argue about the best saws/drills, artists argue about the best brushes/paints, musicians argue about the best instrument maker.
You're right, customers don't care about what tool was used to build something, but they care that you can do your job well and good tools help you do that.
It should be more self-evident now.
When there are many tools which meet the minimum requirements for doing a job, then the focus becomes not on which tool can do the job, but which tool you feel does the job the best (or you enjoy using). Carpenters argue about the best saws/drills, artists argue about the best brushes/paints, musicians argue about the best instrument maker.
You're right, customers don't care about what tool was used to build something, but they care that you can do your job well and good tools help you do that.
"Carpenters argue about the best saws/drills, artists argue about the best brushes/paints, musicians argue about the best instrument maker."
Is that actually true? I can't think of a single example of such an argument. I have heard recommendations, and heard various trendy tools being promoted (at least for music), but never an argument.
I think it has to do with transferability of skill. In music, carpentry, and painting, skill readily transfers to different tools even if it causes annoyance or a stylistic change in the result.
The stakes are much higher for web development; at least that's the perception. Skills probably transfer better than people think, but it's scary to have 10 years of experience and a high billing rate and then go back to "hello world".
It's much more comfortable to try to promote what you already know so that you don't have to do that. And it also avoids wasting time on a new framework that seems promising but never gets critical mass.
Is that actually true? I can't think of a single example of such an argument. I have heard recommendations, and heard various trendy tools being promoted (at least for music), but never an argument.
I think it has to do with transferability of skill. In music, carpentry, and painting, skill readily transfers to different tools even if it causes annoyance or a stylistic change in the result.
The stakes are much higher for web development; at least that's the perception. Skills probably transfer better than people think, but it's scary to have 10 years of experience and a high billing rate and then go back to "hello world".
It's much more comfortable to try to promote what you already know so that you don't have to do that. And it also avoids wasting time on a new framework that seems promising but never gets critical mass.
I've never had a problem moving to another language, I'll never understand why people pigeonhole themselves into categories like "rails dev" or "java dev".
The fundamentals are transferable, I don't even mention specific technologies or stacks these days if I don't have to.
The fundamentals are transferable, I don't even mention specific technologies or stacks these days if I don't have to.
Well, two things. Lots of people are good on the mechanics of a particular stack and weak on the fundamentals, making the description accurate.
And lots of people hire based on the assumption that expertise in a particular stack is the most important thing (perhaps in part as a result of the preceding point).
And lots of people hire based on the assumption that expertise in a particular stack is the most important thing (perhaps in part as a result of the preceding point).
Definitely, which is how you end up with half of NPM's package repository.
It's not necessarily a problem, but it takes humility.
"When art critics get together they talk about Form and Structure and Meaning. When artists get together they talk about where you can buy cheap turpentine."
-- Pablo Picasso
Haha.
But there is a big difference between discussing tools and arguing about them like your career depends on a particular opinion being right.
But there is a big difference between discussing tools and arguing about them like your career depends on a particular opinion being right.
>You're right, customers don't care about what tool was used to build something, but they care that you can do your job well and good tools help you do that.
True, but I do my homework too. My code needs to be maintainable for the next guy. We can't invest inordinate amounts of time on V2 where it isn't necessary. I don't want unrelated parts of the program breaking because I fix a bug. The next set of features should be easy to implement from an architectural perspective. All of this is important to the customer and my business.
I care about my craft, but there's a line at which I stop investing my time in debating the toolset. If I'm spending ~10 hours / week writing blog and forum posts about why everyone should use X framework instead of Y I'm seriously wasting my time.
True, but I do my homework too. My code needs to be maintainable for the next guy. We can't invest inordinate amounts of time on V2 where it isn't necessary. I don't want unrelated parts of the program breaking because I fix a bug. The next set of features should be easy to implement from an architectural perspective. All of this is important to the customer and my business.
I care about my craft, but there's a line at which I stop investing my time in debating the toolset. If I'm spending ~10 hours / week writing blog and forum posts about why everyone should use X framework instead of Y I'm seriously wasting my time.
> I care about my craft, but there's a line at which I stop investing my time in debating the toolset. If I'm spending ~10 hours / week writing blog and forum posts about why everyone should use X framework instead of Y I'm seriously wasting my time.
Sure, but that line is in a different place depending on how important the tools are. If you're doing a project where the functionality is 40% custom code and 60% tooling, that will naturally give you a very different attitude to a project where the functionality is 1% custom code and 99% tooling.
Sure, but that line is in a different place depending on how important the tools are. If you're doing a project where the functionality is 40% custom code and 60% tooling, that will naturally give you a very different attitude to a project where the functionality is 1% custom code and 99% tooling.
Except, really, none of those analogues are accurate. Professionals in the other fields identified don't argue about told the way programmers, and particularly web devs, do.
The kind of tool-centered identification and tribalism seen in large segments of the development community is not only rare among other professionals, it's seen (usually correctly) as a sign of being an amateur that doesn't know the craft well in other fields.
The kind of tool-centered identification and tribalism seen in large segments of the development community is not only rare among other professionals, it's seen (usually correctly) as a sign of being an amateur that doesn't know the craft well in other fields.
To a point, but then it is just self indulgence. Comparing camera gear is huge in the photography world, but making a great picture is rarely limited by the gear. People spend so much time arguing over gear they never take any pictures.
I see a lot of the same thing when people argue over programming tools. Just go build stuff in whatever tool you feel comfortable in. Do not lose site that building stuff is the goal, not using some tool.
I see a lot of the same thing when people argue over programming tools. Just go build stuff in whatever tool you feel comfortable in. Do not lose site that building stuff is the goal, not using some tool.
As a 36 year old curmudgeon, I agree. I think the overabundance of framework/tool choices is resulting in decision paralysis. The C++ world doesn't (or at least it didn't) have this problem -- there's usually few standard ways to do something and it takes a only a few minutes to pick one. The rest of developer energies are spent on actual implementation.
I think the problem is no one seriously reads Hawryszkiewycz anymore.
Seems everyone's trying to squeeze problems into fitting their solution/framework rather the other way around.
Seems everyone's trying to squeeze problems into fitting their solution/framework rather the other way around.
Web development is a bit like runaway sexual selection, but instead of developing extravagant plumage, webdevs develop extravagant frameworks and strive to rewrite everything in JavaScript.
Blog posts are a way of status signaling but also of fitness signaling. People that have the capability of always learning new things and writing about them should be really good programmers while lower quality individuals can't afford to keep up and drop out of the game. Only the former are able to reliably secure mates and reproduce, thereby perpetuating the cycle.
Blog posts are a way of status signaling but also of fitness signaling. People that have the capability of always learning new things and writing about them should be really good programmers while lower quality individuals can't afford to keep up and drop out of the game. Only the former are able to reliably secure mates and reproduce, thereby perpetuating the cycle.
There are no hard problems in web design, other than that browsers are a really shitty platform for delivering software, and there's never been a concerted effort to start from scratch and solve it properly once. Just loads of proprietary solutions which are security nightmares and poorly supported, and endless frameworks.
Start again. Burn it all down, and do it properly this time.
Start again. Burn it all down, and do it properly this time.
> I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it.
Because writing web apps / CRUD apps is soul-destroying, boring, and always perceived by the client as easy (no matter how much business value they bring) so there's pressure to do them fast, as others have said. Any distraction is welcome, and any framework that makes the task less painful is welcome.
Both of which foster this fairly pointless set of discussions :)
32 year old curmudgeon here, in the middle of a large web app project...
Because writing web apps / CRUD apps is soul-destroying, boring, and always perceived by the client as easy (no matter how much business value they bring) so there's pressure to do them fast, as others have said. Any distraction is welcome, and any framework that makes the task less painful is welcome.
Both of which foster this fairly pointless set of discussions :)
32 year old curmudgeon here, in the middle of a large web app project...
I work in embedded, web & app dev and for web or app dev, by far most customers really don't care what it is written in. They care about the end result only. So we can use whatever is the closest to the endresult already and that's not often something like Rails. More often than not it is actually Wordpress; someone in this thread mentions web projects are more often <100 hours than years (for embedded we think in years, web/apps in 1-3 months) that's why WP is working; our clients do not actually care about maintainability because it's a quick write and will be thrown away / replaced when it served it's purpose.
Web development doesn't have many hard problems. It has one serious though. How not to get tangled in your own mess when customer is breathing down your neck.
Almost every language provides you with sufficient tools for writing algorithms, doing calculations, storing and accessing data, but almost none gives you solutions for avoiding mess.
There are many ideas on how to avoid mess but none of them works and people are left to their own devices to figure out how not to get lost.
That's why webdevelopers are so fascinated with frameworks. They promise solution to their one hard problem. And some even deliver it to a degree.
Almost every language provides you with sufficient tools for writing algorithms, doing calculations, storing and accessing data, but almost none gives you solutions for avoiding mess.
There are many ideas on how to avoid mess but none of them works and people are left to their own devices to figure out how not to get lost.
That's why webdevelopers are so fascinated with frameworks. They promise solution to their one hard problem. And some even deliver it to a degree.
> Web development doesn't have many hard problems. It has one serious though.
Kind of a strange way to put it but I think I agree with the gist. Scaling is the web's hard problem. Building an ever expanding list of features while measuring if users like them and delivering them via cheap computers and tiny pipes is surprisingly difficult. Scaling a rigidly defined web system on it's own generally isn't so hard at this point. One off Twitter clones with a few of T's killer features can be knocked out in a few days with pretty good load scaling properties. But scaling the codebase and architecture from 1 dev, 0 users, and 1 OK feature to XXX users and YYY features users love is really hard to get right. Ideally the 100th feature is as easy as the 10th and you can just add more engineer hours, but more commonly it seems to get exponentially harder to add features as the codebase expands.
Kind of a strange way to put it but I think I agree with the gist. Scaling is the web's hard problem. Building an ever expanding list of features while measuring if users like them and delivering them via cheap computers and tiny pipes is surprisingly difficult. Scaling a rigidly defined web system on it's own generally isn't so hard at this point. One off Twitter clones with a few of T's killer features can be knocked out in a few days with pretty good load scaling properties. But scaling the codebase and architecture from 1 dev, 0 users, and 1 OK feature to XXX users and YYY features users love is really hard to get right. Ideally the 100th feature is as easy as the 10th and you can just add more engineer hours, but more commonly it seems to get exponentially harder to add features as the codebase expands.
Systems always get more complex as you add features. At best you can avoid shooting yourself in the foot, but that's ok because none of your competitors can avoid the same issues.
The web's hard problem is dealing with that complexity at a speed and scale that is a few orders of magnitude bigger than any other programming environment I can think of.
> At best you can avoid shooting yourself in the foot
At best we can keep our systems simple, agile, and cut bad features as quickly as we test new ones (every damn day!).
> At best you can avoid shooting yourself in the foot
At best we can keep our systems simple, agile, and cut bad features as quickly as we test new ones (every damn day!).
MMO's are vastly more complex than websites. The issue with websites is they are inherently simple, and adding one dimension of complexity is still easy. But, when people continue to underestimate what adding features actually takes they snowball into unmaintainable crap.
PS: A single 1ghz CPU with a very fast connection could serve the simplest possible webpage to every single person on the planet in less than 1 day. Scaling is only an issue as you add complexity.
PS: A single 1ghz CPU with a very fast connection could serve the simplest possible webpage to every single person on the planet in less than 1 day. Scaling is only an issue as you add complexity.
[deleted]
Not from me, you aren't. I'm an old soldier in this game (by webdev standards of 6 months for a new framework) and I have tended to switch over to the latest stuff almost every year (projects, job change etc). It's just a common disease and herd mentality in this field to sling the latest cools. Our productivity is generally shit because instead of cranking out working code, we try to fit more tools to the box, probably to combat the repetitiveness and boredom. At the end of the day, it doesn't matter what language or frameworks we use, things still get fucked up because we never spend enough time to know the ins and outs of our tools.
It's certainly a luxury to not have to think about malicious input from the world wide web, and be able to try any tool you want and just try again if it misbehaves -- it won't empty your users' bank accounts.
> I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it.
> We worry about what technologies we use for a given task as far as it impacts our design goals
I don't see the difference.
> I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it.
> We worry about what technologies we use for a given task as far as it impacts our design goals
I don't see the difference.
As someone who spends most of his time on "Hard Problems" but has done a fair share of web apps/CRUD apps I have to admit that web apps are deceptively hard. While going from zero to working prototype web app is trivial in any language, going from working prototype to fully secured, fast, scalable site that is easy to maintain, extend and deploy and easy to use across all devices and browsers is a massive pain in the ass and the difference between the right tool and the wrong tool can easily be an order of magnitude or more in time. Combine this with the fact that the time budget in most web projects is tiny, and the difference in tool choice can really make or break a project.
Basically stuff like Image Processing is trivial from an software design/architecture point of view since it's 90+% math and computer science so the the software 'architecture' tools don't matter. Non-trivial web apps on the other hand are 90+% an architecture problem so there those tools matter a great deal.
Basically stuff like Image Processing is trivial from an software design/architecture point of view since it's 90+% math and computer science so the the software 'architecture' tools don't matter. Non-trivial web apps on the other hand are 90+% an architecture problem so there those tools matter a great deal.
They're not arguing about technology as such, they're arguing about productivity. The specific problems are not hard, just the organisation and maintenance of the parts. So it does probably matter a lot for this kind of work.
My advice: if you have skin in this game and need to make real decisions about what platform/language you use, find an article that reasons soundly about what the questions are and convinces you of its answers. Don't listen to this one. And if this quality of thinking is diagnostic of how Ruby/Rails developers think generally... well I'm glad that's a game my skin is safe from.