5 ms·

Every web application requires at least 2 languages (a sever side language and HTML). Virtually all of them also end up also including Javascript and CSS. And J

Every web application requires at least 2 languages (a sever side language and HTML). Virtually all of them also end up also including Javascript and CSS. And Javascript as a server side language is relatively new. That's not a great argument against Rails.

setzer22 9y ago
With clojure you get the frontend logic in clojurescript, backend logic in clojure (or even clojurescript itself) and due to the isomorphism between html and S-expressions, the actual page layout is also described as clojure data in a natural, unambiguous way.
- egeozcan 9y ago
  Is there a good example (read: not todo) of an app designed like that? You mean using node through clojurescript when you mean a cljs backend?
- acjohnson55 9y ago
  There's a similar story with Scala and Scala.js
gkya 9y ago
I'm not really trying to make an argument against it anyways. IMO if you haven't jumped in early in the Rails's lifetime, it's really hard to catch up; this is what I'm saying.
- rubyfan 9y ago
  I was an early Rails adopter, somewhere around 0.x and used it every day through 2.3. Somewhere just before 3.0 I stopped using it daily. I recently came back to 5.0 for a few applications and was pleasantly surprised that I was proficient in a day or so. I wasn’t familiar with ActionCable, Asset Pipeline or CoffeeScript but felt they were all easy enough. All the basics were still there, the MVC application structure, DB migrations, etc. I share the sentiment that JavaScript and many other languages used for web development are great but seriously lack some of the essentials Rails provides.
  - rco8786 9y ago
    So you jumped on early in the Rails timeline and we’re able to keep up. Seems you’re just proving that point.
    - rubyfan 9y ago
      No, I skipped 3 and 4 and didn’t keep up. Jumping back in was easy. The essentials haven’t really changed so jumping in at 0.14.5 or 5.0.1 shouldn’t really matter.
      - rco8786 9y ago
        I realize I'm fighting an uphill battle here considering your username, but what you're saying is that it's just as easy to jump into Rails today whether you're a total n00b or you were an early adopter using it every day over ~6 years from 0.X to 3.0, skipping a couple versions, and then returning. Come on...
        deleted 9y ago
        [deleted]
        rahoulb 9y ago
        3 was pretty much a total rewrite of Rails, so you could argue that if you skipped 3 you are starting over from scratch. Pretty much everything changed apart from the higher-level concepts (even the opinionated stuff was diluted to a point)
        rubyfan 9y ago
        Agree, Rails 3 absorbing merbisms introduced flexibility to the existing conventions making it easy to stray from the opinionated stuff. Rails 3 was still Rails but definitely made it easier to get yourself into trouble. And definitely changes any Rails 2 developer would have to learn. I’ve experimented with most of the alternative frameworks and micro-frameworks. I have a real fondness for Sinatra. I’m happy most modern languages have their own Sinatra but I’m sad that most modern languages lack their own Rails.
- LyndsySimon 9y ago
  I started with Rails at 4.x, and having never written a line of Ruby prior it took me about two weeks to be fluent enough to handle most anything thrown at me in the course of "typical" webapp development. That was about a year ago, and these days my biggest challenge is identifying and filling knowledge gaps. For instance: the mere fact that ActiveJob exists isn't obvious.
- debaserab2 9y ago
  I just learned Ruby (and rails) about a year and a half ago. I found it incredibly easy to pick up. Coming from a PHP/Java background I found that most MVC based frameworks that I already knew are fashioned from Rails in some way. I think if you're new to most server side languages and javascript SPA's are your wheelhouse your experience will be very foreign and dogmatic feeling. I switch between the two worlds often and am still amazed at how productive I am in ruby/rails.
mercer 9y ago
If it still relies on CoffeeScript, it's a great argument against Rails.
- steveklabnik 9y ago
  Rails doesn't rely on CoffeeScript. It includes support for it by default, but you don't have to use it, and you can never start using it by passing a flag to `rails new` or removing the `coffee-rails` gem from your Gemfile.
  - mercer 9y ago
    How do the default affect the ecosystem these days, though? I remember back when I used Rails and CoffeeScript was the standard, it took a bit of work to avoid it altogether. This wasn't difficult, to be fair, but it felt like pointless busywork nonetheless.
    - steveklabnik 9y ago
      I couldn't tell you, as I haven't been really involved in Rails for a while. I never used coffeescript for any serious project, even when this change was made back in 3.1, and I can't remember it ever causing trouble. YMMV.
    - rickyc091 9y ago
      jQuery was removed in the latest version of Rails in favor of rails-ujs, essentially a vanilla js version of jQuery so `remote: true` and things like that would still work. Erb / vanilla js is still the default stack for beginners. But they've started to move away from the asset pipeline and they've built in webpack.
- always_good 9y ago
  I think the kneejerk hate on Rails by Coffeescript proxy is a good example of why developer-hate on forums like HN is a pitiful metric for scoring an ecosystem. It's such a non-issue. In fact, what's impressive is how Sprockets (part of Rails asset compilation) can chain together arbitrary file transformations by looking at the extension. `file.coffee.erb.whatever` will get processed as with the tool configured for `.whatever` files, then it'll eval Erb's <%= ... %> tags, and then finally get processed as Coffeescript before being concat into the bundle. I always thought that it was a really intuitive way to specify transformations. But the thing is that you need Rails experience to appreciate a solution like that, and it's easier to write off Rails entirely because someone says that it depends on Coffeescript. In reality, Rails just shipped with the Coffeescript handler so that Sprockets could understand .coffee extensions if you chose to write .coffee files. Technology-hate only serves to confuse beginners by making them think everything is black and white. And by making them think that they are making a mistake by learning one ecosystem over another when in reality everything has trade-offs and it's better to learn something over wallowing in the paralysis of indecision. Half of these comments aren't even capable of comparing Javascript to Ruby without bringing up Webpack and the complexity of client-side bundling as if Ruby is a client-side language.
leshow 9y ago
Not necessarily even html, you could write your HTML in a DSL of some sort, write functions that generate HTML, etc. Using that you could keep the backend homogeneous. For example, something like https://jaspervdj.be/blaze/tutorial.html https://jaspervdj.be/blaze/tutorial.html

setzer22 9y ago

With clojure you get the frontend logic in clojurescript, backend logic in clojure (or even clojurescript itself) and due to the isomorphism between html and S-expressions, the actual page layout is also described as clojure data in a natural, unambiguous way.

egeozcan 9y ago
Is there a good example (read: not todo) of an app designed like that? You mean using node through clojurescript when you mean a cljs backend?
acjohnson55 9y ago
There's a similar story with Scala and Scala.js

gkya 9y ago

I'm not really trying to make an argument against it anyways. IMO if you haven't jumped in early in the Rails's lifetime, it's really hard to catch up; this is what I'm saying.

rubyfan 9y ago
I was an early Rails adopter, somewhere around 0.x and used it every day through 2.3. Somewhere just before 3.0 I stopped using it daily. I recently came back to 5.0 for a few applications and was pleasantly surprised that I was proficient in a day or so. I wasn’t familiar with ActionCable, Asset Pipeline or CoffeeScript but felt they were all easy enough. All the basics were still there, the MVC application structure, DB migrations, etc. I share the sentiment that JavaScript and many other languages used for web development are great but seriously lack some of the essentials Rails provides.
- rco8786 9y ago
  So you jumped on early in the Rails timeline and we’re able to keep up. Seems you’re just proving that point.
  - rubyfan 9y ago
    No, I skipped 3 and 4 and didn’t keep up. Jumping back in was easy. The essentials haven’t really changed so jumping in at 0.14.5 or 5.0.1 shouldn’t really matter.
    - rco8786 9y ago
      I realize I'm fighting an uphill battle here considering your username, but what you're saying is that it's just as easy to jump into Rails today whether you're a total n00b or you were an early adopter using it every day over ~6 years from 0.X to 3.0, skipping a couple versions, and then returning. Come on...
      - deleted 9y ago
        [deleted]
      - rahoulb 9y ago
        3 was pretty much a total rewrite of Rails, so you could argue that if you skipped 3 you are starting over from scratch. Pretty much everything changed apart from the higher-level concepts (even the opinionated stuff was diluted to a point)
        rubyfan 9y ago
        Agree, Rails 3 absorbing merbisms introduced flexibility to the existing conventions making it easy to stray from the opinionated stuff. Rails 3 was still Rails but definitely made it easier to get yourself into trouble. And definitely changes any Rails 2 developer would have to learn. I’ve experimented with most of the alternative frameworks and micro-frameworks. I have a real fondness for Sinatra. I’m happy most modern languages have their own Sinatra but I’m sad that most modern languages lack their own Rails.
LyndsySimon 9y ago
I started with Rails at 4.x, and having never written a line of Ruby prior it took me about two weeks to be fluent enough to handle most anything thrown at me in the course of "typical" webapp development. That was about a year ago, and these days my biggest challenge is identifying and filling knowledge gaps. For instance: the mere fact that ActiveJob exists isn't obvious.
debaserab2 9y ago
I just learned Ruby (and rails) about a year and a half ago. I found it incredibly easy to pick up. Coming from a PHP/Java background I found that most MVC based frameworks that I already knew are fashioned from Rails in some way. I think if you're new to most server side languages and javascript SPA's are your wheelhouse your experience will be very foreign and dogmatic feeling. I switch between the two worlds often and am still amazed at how productive I am in ruby/rails.

mercer 9y ago

If it still relies on CoffeeScript, it's a great argument against Rails.

steveklabnik 9y ago
Rails doesn't rely on CoffeeScript. It includes support for it by default, but you don't have to use it, and you can never start using it by passing a flag to `rails new` or removing the `coffee-rails` gem from your Gemfile.
- mercer 9y ago
  How do the default affect the ecosystem these days, though? I remember back when I used Rails and CoffeeScript was the standard, it took a bit of work to avoid it altogether. This wasn't difficult, to be fair, but it felt like pointless busywork nonetheless.
  - steveklabnik 9y ago
    I couldn't tell you, as I haven't been really involved in Rails for a while. I never used coffeescript for any serious project, even when this change was made back in 3.1, and I can't remember it ever causing trouble. YMMV.
  - rickyc091 9y ago
    jQuery was removed in the latest version of Rails in favor of rails-ujs, essentially a vanilla js version of jQuery so `remote: true` and things like that would still work. Erb / vanilla js is still the default stack for beginners. But they've started to move away from the asset pipeline and they've built in webpack.
always_good 9y ago
I think the kneejerk hate on Rails by Coffeescript proxy is a good example of why developer-hate on forums like HN is a pitiful metric for scoring an ecosystem. It's such a non-issue. In fact, what's impressive is how Sprockets (part of Rails asset compilation) can chain together arbitrary file transformations by looking at the extension. `file.coffee.erb.whatever` will get processed as with the tool configured for `.whatever` files, then it'll eval Erb's <%= ... %> tags, and then finally get processed as Coffeescript before being concat into the bundle. I always thought that it was a really intuitive way to specify transformations. But the thing is that you need Rails experience to appreciate a solution like that, and it's easier to write off Rails entirely because someone says that it depends on Coffeescript. In reality, Rails just shipped with the Coffeescript handler so that Sprockets could understand .coffee extensions if you chose to write .coffee files. Technology-hate only serves to confuse beginners by making them think everything is black and white. And by making them think that they are making a mistake by learning one ecosystem over another when in reality everything has trade-offs and it's better to learn something over wallowing in the paralysis of indecision. Half of these comments aren't even capable of comparing Javascript to Ruby without bringing up Webpack and the complexity of client-side bundling as if Ruby is a client-side language.

leshow 9y ago

Not necessarily even html, you could write your HTML in a DSL of some sort, write functions that generate HTML, etc. Using that you could keep the backend homogeneous. For example, something like https://jaspervdj.be/blaze/tutorial.html https://jaspervdj.be/blaze/tutorial.html