Honest question. What technology are people enjoying on the server-side with sites built in React or Angular? I've seen some of these done with Rails, and some done with Node, neither of which I personally enjoy a whole lot. (Note, I'm not making an argument that either are BAD - just that I don't really like working with them). I'm curious to hear what other people are having success with in production.
Today I accept that Rails is yesterday’s software
21–30 of 166 posts
Re: Today I accept that Rails is yesterday’s software
#22The question is where do you go from here if you're a Rails shop?
The last place I worked had 80% of their products running Rails 2 and 20% of them running on Rails 3. No product was ever both completed AND caught traction since.
Do you stick with Rails 5 for the next project? Do you meander over to Python or Node?
Re: Today I accept that Rails is yesterday’s software
#23Being "yesterday's software" is a necessary step. It's the final part of the Gartner hype cycle: maturity. https://speakerdeck.com/tehviking/surviving-the-framework-hy...
Thank you, that was a wonderful slide deck.
Brandon is a really awesome guy. His talks are always funny and informative.
Re: Today I accept that Rails is yesterday’s software
#241. The first software wave was system level software. Developers wanted something but made their lives easier, but also wanted control and speed. C and then Java were the stars
2. In the second wave, we got languages like Ruby and Python which are flexible and easy for developers to work with. Sometimes it's more important to be able to iterate quickly than execute quickly. Server software, app backends, etc were all implemented in whatever language was easiest using HTTP as an interchange with other languages
3. In the third wave, developer experience enhancements that scripting languages pioneered trickled down to systems programming with new languages like Swift and Go. These give you most of the benefits of the second wave languages without their significant overhead. Since they are better suited to building small light services, old bulky Ruby / Rails app are starting to look antiquated pretty quickly.
I also used to go to Rails first for web projects... I use Go now because it's more lightweight. I used to do native apps in Objective-C... I now use Swift because it's easier to write.
Re: Today I accept that Rails is yesterday’s software
#25Just use Java people. You can bootstrap a Spring project in 10 minutes and it will have every feature (ORM, security, caching, MVC) available with just a maven dependency or you can roll your own and it will work fine. Strong typing, good performance, sensible stack traces (if you don't overdo annotations) and all the testing and monitoring tools you could ever dream of.
Re: Today I accept that Rails is yesterday’s software
#26The article seems to be lamenting three things: 1) Batteries-included web frameworks (like Rails and Django) 2) Interpreted languages without strict typing (like Ruby and Python) 3) Programmers relying on large numbers of dependencies (e.g. ruby gems), and the resulting difficulty in reasoning about the software The last paragraph then goes on to suggest that different languages are required. This seems wrong. If you…
>> 3) Programmers relying on large numbers of dependencies (e.g. ruby gems)
So many gems are either not written well, or not maintained well. How many times have you seen the case where you update gem to fix a bug, and then cause two more?
It's not Rails or Ruby's fault, it's the community.
Re: Today I accept that Rails is yesterday’s software
#27The article seems to be lamenting three things: 1) Batteries-included web frameworks (like Rails and Django) 2) Interpreted languages without strict typing (like Ruby and Python) 3) Programmers relying on large numbers of dependencies (e.g. ruby gems), and the resulting difficulty in reasoning about the software The last paragraph then goes on to suggest that different languages are required. This seems wrong. If you…
All 3 of those lamentations could also apply to Clojure, but I don't think anyone who used Clojure would lament it.
Re: Today I accept that Rails is yesterday’s software
#28Earlier quoted context omitted.
> The problem comes when you rely on adding packages that just talk directly to your framework (like Django middleware). Once you do that a few times, you really don't know what's going on between a web request hitting your server, and your own code running I think this is where the lack of strict typing can make things harder to figure out. Especially if you're trying to understand middleware functions with opaque s…
But is that really a problem of non-strict typing, or rather a problem of metaprogramming? I could imagine even a very strongly typed system in Haskell or Scala would probably be hard for an IDE to support if it uses a lot of complex abstractions to create internal DSLs (like Rails and I guess Django as well do).
IDEs can typically query a strongly-typed language for useful information without actually running the code. As long as the DSL uses static types, the IDE can just ask the compiler / type-checker to tell it what's going on and what portions of the source contribute to that meaning.
This is where the fuzziness of the phrase "strongly typed" becomes a bit of a problem, but the fundamental idea is that there are two levels of meaning in the program, one static, and one dynamic, and the static level produces useful info. There are lots of levels this can take. The most common is in an IDE for a language like C or Python; it compiles or style-checks the file, warning you about issues, but it doesn't have any sense of what the program means. Another very common one is where you have non-code configuration files for GUI layout. You usually don't need a Turing-complete language to describe your GUI, so putting it in some other format like XML means the IDE can render the GUI and let you make changes to it without having to actually run your code. Strong typing for DSLs is just another example of the same sort of thing. If you're able to e.g. describe your models to the ORM entirely statically, it can figure out what a ton of your code means without running any of it.
I think this is basically what you mean by metaprogramming, except with the constraint that one of the two languages is pure and Turing-incomplete and doesn't rely on external input. Then the IDE can safely run that language.
Re: Today I accept that Rails is yesterday’s software
#29[deleted]
Re: Today I accept that Rails is yesterday’s software
#30The article seems to be lamenting three things: 1) Batteries-included web frameworks (like Rails and Django) 2) Interpreted languages without strict typing (like Ruby and Python) 3) Programmers relying on large numbers of dependencies (e.g. ruby gems), and the resulting difficulty in reasoning about the software The last paragraph then goes on to suggest that different languages are required. This seems wrong. If you…
>> 3) Programmers relying on large numbers of dependencies (e.g. ruby gems) So many gems are either not written well, or not maintained well. How many times have you seen the case where you update gem to fix a bug, and then cause two more? It's not Rails or Ruby's fault, it's the community.
Ruby's got a lot of software that's been produced over the years, and one of the risks here is that people burn out on projects and move on. A slow accumulation of dangerous deadwood occurs over time and unless people work to clear the brush it can be catastrophic when problems strike.
Consider: ImageMagick and OpenSSL.
Newer platforms haven't had this problem because they've already broken all their old software (Rust) or because they're still changing rapidly enough that new software is still emerging (Swift).
It's not the community's fault. It's that it gets harder and harder to keep things clean the longer your language has been around.