web framework for Ruby 1.9

[Stefan Lang]

I'm looking for a web framework that:

1) really works with Ruby 1.9

2) pure Ruby code (i.e. doesn't depend on C-extensions, Java libraries...)

3) has an active community

bonus points:

4) doesn't follow the "let's extend core classes whenever possible" craze

5) good postgres support

Does such a framework exist or am I asking for too much?

Actually I would use Rails, the latest RC is advertised as Ruby 1.9
compatible but I've immediately hit a couple of errors and I
don't have the time ATM to fix compatibility errors in such a big
codebase and push the changes upstream. What's more, the pure
Ruby postgres driver doesn't work anymore.

Merb fails with syntax errors with Ruby 1.9.

Thanks,
Stefan

 

[ara.t.howard]

I'm looking for a web framework that:

1) really works with Ruby 1.9

2) pure Ruby code (i.e. doesn't depend on C-extensions, Java
libraries...)

3) has an active community

bonus points:

4) doesn't follow the "let's extend core classes whenever possible"
craze

5) good postgres support

Does such a framework exist or am I asking for too much?

Actually I would use Rails, the latest RC is advertised as Ruby 1.9
compatible but I've immediately hit a couple of errors and I
don't have the time ATM to fix compatibility errors in such a big
codebase and push the changes upstream. What's more, the pure
Ruby postgres driver doesn't work anymore.

Merb fails with syntax errors with Ruby 1.9.

Thanks,
Stefan

it's called ramaze.

a @ http://codeforpeople.com/

 

[Stefan Lang]

it's called ramaze.

Thanks. At least a basic app works fine in Ruby 1.9,
installation is simple, only dependency rack and
colored console output. Neat.

<rant>
But what the hell is with all these extensions to core
classes.

acquire __DIR__/"*.rb"

Thats Kernel#acquire, Kernel#__DIR__, Symbol#/
and String#/. What's wrong with a simple:

Ramaze::Utils.acquire_relative "*.rb"

There is nothing modular about putting arbitrary
utility methods into core classes!
</rant>

Stefan

 

[ara.t.howard]

Thanks. At least a basic app works fine in Ruby 1.9,
installation is simple, only dependency rack and
colored console output. Neat.

<rant>
But what the hell is with all these extensions to core
classes.

acquire __DIR__/"*.rb"

Thats Kernel#acquire, Kernel#__DIR__, Symbol#/
and String#/. What's wrong with a simple:

Ramaze::Utils.acquire_relative "*.rb"

There is nothing modular about putting arbitrary
utility methods into core classes!
</rant>

Stefan

perhaps - but there are far less than in any other ruby framework.
also __DIR__ and the '/' string join i think are planned for a future
ruby release...

a @ http://codeforpeople.com/

 

[Jeremy Kemper]

I'm looking for a web framework that:

1) really works with Ruby 1.9

2) pure Ruby code (i.e. doesn't depend on C-extensions, Java libraries...)

3) has an active community

bonus points:

4) doesn't follow the "let's extend core classes whenever possible" craze

5) good postgres support

Does such a framework exist or am I asking for too much?

Rails satisfies all 5 for me, but you may find Active Support adds too
much for your taste.

Actually I would use Rails, the latest RC is advertised as Ruby 1.9
compatible but I've immediately hit a couple of errors and I
don't have the time ATM to fix compatibility errors in such a big
codebase and push the changes upstream. What's more, the pure
Ruby postgres driver doesn't work anymore.

What'd you run into? The only outstanding compatibility issue I have
is with the test/unit -> minitest change.

Rails has been chasing 1.9 compatibility like a drowning man gulps for
air. Luckily the recent feature freeze means we're close to having dry
land underfoot.

The latest postgres-pr works, btw. The earlier driver was missing the
#transaction_status method.

Merb fails with syntax errors with Ruby 1.9.

Thanks,
Stefan

Best,
jeremy

 

[Stefan Lang]

Rails satisfies all 5 for me, but you may find Active Support adds too
much for your taste.


What'd you run into? The only outstanding compatibility issue I have
is with the test/unit -> minitest change.

* Creating an app failed with an exception. Installing the test-unit
gem fixed that.

* Booting the application failed because config/boot.rb depends
on a Gem::RubyGemsVersion that is not defined in the RubyGems 1.3.1
that comes with Ruby 1.9.1 (I've got a fairly recent build from the 1_9_1
branch). I fixed that by constantly returning "1.3.1" from rubygems_version.

* Freezing rails failed with missing method in RubyGems. Didn't find
a fix for that.

* Rails didn't use the postgres-pr driver I installed with "gem install".
(And that wasn't a RubyGems issue, it didn't work with postgres-pr
in vendor either). Neither ruby-postgres nor pg built with Ruby 1.9.

Rails has been chasing 1.9 compatibility like a drowning man gulps for
air. Luckily the recent feature freeze means we're close to having dry
land underfoot.

The latest postgres-pr works, btw. The earlier driver was missing the
#transaction_status method.

Great, where can I get that version?

Stefan

 

[Peter Booth]

I'm just curious, why would you use 1.9 if JRuby has rails support?
The support tools, native threads and performance would seem
compelling (I'm still on 1.8.6).

Sent from my iPhone

 

[Stefan Lang]

I'm just curious, why would you use 1.9 if JRuby has rails support? The
support tools, native threads and performance would seem compelling (I'm
still on 1.8.6).

There's Ruby 1.9, the language and then there are
implementations. JRuby lags behind in 1.9 compatibility
(understandably, because 1.9 has been in flux until very
recently).

Ruby 1.9 has some nice features like the encoding support
and the earlier the Ruby community migrates, the better.

Regarding performance, I have a rails app running on
JRuby and it's actually slightly slower than MRI 1.8.

Stefan

 

[Charles Oliver Nutter]

There's Ruby 1.9, the language and then there are
implementations. JRuby lags behind in 1.9 compatibility
(understandably, because 1.9 has been in flux until very
recently).

Ruby 1.9 has some nice features like the encoding support
and the earlier the Ruby community migrates, the better.

We've already started adding 1.9 support and the plan is to have it done
around the time of the 1.9.1 final release at Christmas. The
parser+interpreter are almost done, compiler will follow that. Some core
library changes have been migrated already, and M17N (new String) is
under way.

I agree there are some compelling features in 1.9, and 1.9.1 being the
first real feature-frozen release makes it a good time for us to get
JRuby to support it. You can test out what works in 1.1.5 by passing
--1.9 flag...but a lot more will be in 1.1.6.

Regarding performance, I have a rails app running on
JRuby and it's actually slightly slower than MRI 1.8.

You may want to try 1.1.5...we've gotten reports that it's quite a bit
faster than 1.1.4. At any rate, we're making a big performance push
specifically targeted at Rails, which seems to do something we're a bit
slower at. We'll find it. Any information you can feed us (like specific
parts of the app that are slower, etc) would be of great help

- Charlie

 

[Michael Fellinger]

Thanks. At least a basic app works fine in Ruby 1.9,
installation is simple, only dependency rack and
colored console output. Neat.

<rant>
But what the hell is with all these extensions to core
classes.

acquire __DIR__/"*.rb"

Thats Kernel#acquire, Kernel#__DIR__, Symbol#/
and String#/. What's wrong with a simple:

Ramaze::Utils.acquire_relative "*.rb"

There is nothing modular about putting arbitrary
utility methods into core classes!
</rant>

Thanks for your feedback, I'll address these things.
At least acquire will become Ramaze::acquire, I think the String#/ and
Symbol#/ are quite useless as well, given that File.join never changes
the separator no matter which platform, so we can deprecate them as
well.
But __DIR__, I will keep that one around, it's a proposed feature
since quite some time and chances are high that it will be added to
ruby sometime in the future.

Please note that all methods added to core classes are kept in their
own modules and will never cause any overwrites of existing methods.
See http://github.com/manveru/ramaze/tree/master/lib/ramaze/snippets.rb

^ manveru