Web development techniques are crying out for an "emperor's new clothes" moment. Approaches like GWT (+ a toolkit such as GXT) seem to be a far saner approach for many enterprise applications. On the other hand, there are large classes of problems for which Rails / Django / et al have shown good results. Vive la difference!
Today I accept that Rails is yesterday’s software
161–166 of 166 posts
Re: Today I accept that Rails is yesterday’s software
#162Rails seems to become bloated for sure, but I think there is not a no brainer alternative out there. When I first switched from PHP to Rails it was a natural choice whereas i don't feel Rails to Node.js is in its current state.
i wish someone could say the same for bootstrap
Re: Today I accept that Rails is yesterday’s software
#163Earlier quoted context omitted.
> the 1.5 million code line application written in groovy That's quite big for Groovy. There's a lot of exaggerated claims coming out of that ecosystem. Most JVM apps that size are actually written in Java, perhaps with the codebase duplicated a few times, and counting testing copies of the code in the LOC count. If the harness for testing is written in Groovy, you could call it a "1.5 million line Groovy app". If so…
To be fair - only about 2/3 of the code in the app I mentioned is written in groovy. We strictly enforce static compilation with all of our groovy files. The app is used daily by 35,000 users concurrently @peak time.
My last personal experience of programming in Apache Groovy was with version 1.8. Often I tried recompiling some Java code from Groovy's codebase into Groovy, and even after changing it to allow for occasionally different semantics, it wouldn't work. It could be that Groovy 2.4 has improved a lot since v 1.8, but with the history of exaggerated claims associated with Groovy's backers, I'd need more evidence for your claim. For example, if the next version of Groovy ships having translated its own codebase into statically compiled Groovy, I'll happily look at it again for building systems. In the meantime, I'll only trust it for scripting.
Then there's their governance problem -- nowadays, a single person owns the groovy-lang.org website, whereas until early last year it was governed by 5 "despots" at Codehaus. It's never good when leadership becomes less consensual.
Re: Today I accept that Rails is yesterday’s software
#164Earlier quoted context omitted.
The static compilation doesn't quite work properly. Groovy is good for scripting though, similar to the way Bash is used in Linux, so test your Java classes with it, or use it as a DSL in Gradle builds. For building systems on the JVM, use a language designed for that purpose from the ground up, e.g. Java, Scala, or Kotlin.
I also have several big projects with hundreds of thousand lines of Groovy code that works fantastically well. And performance is top notch!
Apache Groovy is a dynamically typed language so performance can't be "top notch". And the static compilation is an addon that only works when used sparsely. If it worked at scale, the Groovy codebase itself would have been translated into statically compiled Groovy, but that's not happening because Groovy's static compilation doesn't scale. Groovy's good for scripting, nothing more, which isn't a bad thing. Just use it to script/test systems built with Java (or Scala or Kotlin or whatever).
Re: Today I accept that Rails is yesterday’s software
#165If Rails, as of now, would've been a very fast framework, the post author would have never published such post, despite all the other "defects" he underpins.
Rails could eventually get very fast, but it can be frustrating that it's not right now!
This is the same kind of problem of Ruby not having a proper x-platform GUI toolkit or binary packager: you have such a expressive and powerful language and still you feel you are limited by the lack of speed and tooling.
That's why, IMO, a Ruby/Rails dev frustration can explode in such a strong way at some point.
Sadly Ruby isn't backed by a big corporation, so you can only wait for the language and frameworks to get more mature.
Personally I've dealt with this frustration by learning C#. It allowed me to overcome all the current limits of Ruby, while avoiding the Java ShitFactory. At the same it feels great to get back to Ruby when you want to explore ideas! It's still an unbeatable tool for prototyping. Being aware that I have knowledge of another language, makes me feel better, less frustrated, and I browse Ruby weekly news with much less "anxiety" for a revolutionary Ruby improvement (but still I browse it because I know it will happen sooner or later!).
I'm quite sure that the OP after having vented with this post, and having found what for him is a solution, then he will peacefully embrace Ruby or Rails again under a different light (but again, I wouldn't be so surprises to see big improvements soon, so maybe it could even be a better light!)
Re: Today I accept that Rails is yesterday’s software
#166I am thinking about completely stopping reading Hacker News. I enjoy the community a lot but every time I am learning something new I read about how its old and shitty and will cause hair loss when you try and invest any time in it. It puts the breaks on actually learning with the distraction of going and trying to find that new ambiguous stack that the author is hinting at.
" learning something new I read about how its old and shitty"
Oh, the irony: https://news.ycombinator.com/item?id=8787117