81–90 of 168 posts
Earlier quoted context omitted.
So far from what I've seen is that most frontend frameworks go inside one of the directories inside rails. Nice, clean and tight integration. :)
Yes, because having Rails serving the single page application front-end makes total sense.
Earlier quoted context omitted.
Frankly, I'm surprised anyone would still make comments like yours after all these years. Comments like this probably peaked in 2008-2009 ("Rails can't scale" was even earlier) after the zed shaw article and there was a bunch of hype about everyone supposedly moving to Django and how Rails was supposedly dead, yet that didn't happen then, or any of the other times. The reality is that lots of companies have been and…
PHP -> Rails -> Node
http://www.indeed.com/jobtrends?q=php%2C+javascript%2C+ruby%...
http://www.indeed.com/jobtrends?q=php%2C+node.js%2C+ruby%2C+...
After trying Clojure(and Luminus) several times over the past year I don't think it would be my go to for things that Rails is tackling. On a side note writing Clojure gave me a little anxiety so I'm trying to hold back on it for now. After working in this stuff for a while I just use the right tool for the right job. Most of the time Rails is that tool and it allows you to just get stuff done. Sometimes Node is the…
Earlier quoted context omitted.
If you feel Clojure is less expressive than Ruby, you're not good enough at Clojure yet. I'm not saying you have to prefer Clojure's syntax, and Ruby probably has more libraries for a lot of things you want to do. Going from Ruby to Clojure may be a productivity tradeoff for you and your team, but objectively it's not an expressivity tradeoff. Clojure has a bit more expressive power than Ruby.
Could you reference examples of this assertion please?
And here's an attempt to objectively rank programming languages by expressiveness, measured as lines of code changed per commit: http://redmonk.com/dberkholz/2013/03/25/programming-language...
Earlier quoted context omitted.
Interestingly, we had a couple of Clojure experiments. Takeaway was that there were some benefits in terms of performance and maintenance, but they weren't worth the tradeoff in expressivity and increased developer time. There's no reason that Rails should be restricted to 'monorail' or monolithic apps. We've had great success writing what are essentially microservices in Rails. Code is easy to read, easy to maintain…
If you feel Clojure is less expressive than Ruby, you're not good enough at Clojure yet. I'm not saying you have to prefer Clojure's syntax, and Ruby probably has more libraries for a lot of things you want to do. Going from Ruby to Clojure may be a productivity tradeoff for you and your team, but objectively it's not an expressivity tradeoff. Clojure has a bit more expressive power than Ruby.
Earlier quoted context omitted.
If you feel Clojure is less expressive than Ruby, you're not good enough at Clojure yet. I'm not saying you have to prefer Clojure's syntax, and Ruby probably has more libraries for a lot of things you want to do. Going from Ruby to Clojure may be a productivity tradeoff for you and your team, but objectively it's not an expressivity tradeoff. Clojure has a bit more expressive power than Ruby.
Could you reference examples of this assertion please?
LOL at the idea that every Rails programmer will be switching to Clojure or Elixir! While they might be interesting languages (particularly Elixir) I don't see any 10x advantages their web stacks have over Rails for the typical "majestic monolith" use case. Re. EventMachine: As I understood DHH's speech, the idea is that ActionCable abstracts all the messiness around EventMachine, Websockets, Rack and threads. We won…
> the idea that every Rails programmer will be switching to Clojure or Elixir! [...] I don't see any 10x advantages [...] I do. While I cannot speak for Clojure and Elixir, I can speak for Haskell, which I have moved to from Rails. 10x for me is: 1. A 70MB all-in binary to deploy, using 1-3MB of memory when running (has a build in HTTP(S) server), responding in 2-10ms to my requests. Compare that to 700-1500MB of gem…
Ruby is strongly typed.
No, Rails isn't great for web socket kinds of things, but if it were me, I'd just use something else for that, and Rails for the main site. It's still one of the best things out there for quickly iterating, and yet still maintaining some structure and discipline, from what I've seen.
You're doing the "best tool for the job" thing. But if Rails is not a good tool for the job of web socket programming... then ya kinda have to wonder why they're rolling a web socket thing into Rails core, no?
LOL at the idea that every Rails programmer will be switching to Clojure or Elixir! While they might be interesting languages (particularly Elixir) I don't see any 10x advantages their web stacks have over Rails for the typical "majestic monolith" use case. Re. EventMachine: As I understood DHH's speech, the idea is that ActionCable abstracts all the messiness around EventMachine, Websockets, Rack and threads. We won…
This is just an anecdote as: - I agree that most rails programmers will not move to clojure. - For monorail apps, rails is still king. That said, for us, when comparing clojure and ruby REST API services we've built, clojure has had the following benefits: - Less code - Less tests needed - Better concurrency - Less developer hours - Less maintenance - About 33% of the servers for same performance - Easier/faster debu…
Websockets isn't really HTTP and so it doesn't really conform to the request/response model in HTTP that is centered around retrieving document objects. Most web service implementations, including Rails, are built around that paradigm - they get a request for a document, they return it, then they can forget about it (stateless) and move on to serving subsequent document requests, which are likely to be entirely unrel…
You don't need to go as far as websocket to leave the stateless world: Server-Sent Events and all its cousings (Comet, chunked transfer encoding, even long polling ...) all need to keep a connection open for an unknown amount of time and then send data back to the client. Is Rails discouraged for such use cases ?
Neither Chrome nor Firefox has any interest in fixing this.
https://code.google.com/p/chromium/issues/detail?id=275955 https://bugzilla.mozilla.org/show_bug.cgi?id=906896
IE doesn't support Server Sent Events at all.
You could hack around this with wildcard subdomains as some Comet solutions did, but that's so so ugly.
The ecosystem around websockets is much more mature, the browser support is better, and the connection limits are more sane (Firefox will make up to 200 websocket connections, last I looked). I don't consider Server Sent Events a viable option.