Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What’s Up With All These Changes in Rails?

yehudakatz.com

Post reply on HN
Print view View original

91–100 of 115 posts

Re: What’s Up With All These Changes in Rails?

#91

Post by rimantas »

sunchild wrote: post #56
msbarnett wrote: post #26

Earlier quoted context omitted.

To me, the pain-point with HAML has always been that it's much harder to teach our front end designers to use it instead of HTML, whereas Sass presented much less of a barrier for them vs Javascript. HAML feels great for me as a dev vs the verbosity of hand-hacking HTML, but for the guys who spend 90% of their time in photoshop and 10% chopping their PSDs into static HTML to hand to me, I'm not convinced it's worth t…

I'd really have to question the skills of any person who can't adapt from HTML to HAML. If you can do erb, you ought to be able to do HAML within, at most, an hour of pushing stuff through HTML2HAML. Speaking of which, HTML2HAML works nearly every time.

I can. I don't want to. There is zero benefits in doing that for me. SCSS on the other hand offers me that CSS does not.

Re: What’s Up With All These Changes in Rails?

#92

Post by rimantas »

sunchild wrote: post #56
msbarnett wrote: post #26

Earlier quoted context omitted.

To me, the pain-point with HAML has always been that it's much harder to teach our front end designers to use it instead of HTML, whereas Sass presented much less of a barrier for them vs Javascript. HAML feels great for me as a dev vs the verbosity of hand-hacking HTML, but for the guys who spend 90% of their time in photoshop and 10% chopping their PSDs into static HTML to hand to me, I'm not convinced it's worth t…

I'd really have to question the skills of any person who can't adapt from HTML to HAML. If you can do erb, you ought to be able to do HAML within, at most, an hour of pushing stuff through HTML2HAML. Speaking of which, HTML2HAML works nearly every time.

I can. I don't want to. There is zero benefits in doing that for me. SCSS on the other hand offers me that CSS does not.

Re: What’s Up With All These Changes in Rails?

#93

Post by tjogin »

mmaunder wrote: post #58

Rails seems to be focused on it's own navel. It's written by developers to solve problems developers perceive they have. The platform rewards new layers of abstraction within the community - and those layers really exist to enforce a discipline which may not be needed and becomes restrictive if you don't want to do things the Rails way. From my perspective as a serial startup founder, I won't touch the platform becau…

You seem to be very unfamiliar with Rails and the Rails community.

Re: What’s Up With All These Changes in Rails?

#94

Post by dhh »

mnutt wrote: post #71
trustfundbaby wrote: post #18

I appreciate the post and am a huge fan of Yehuda, he used my comments as teeing off points for your remarks but I feel that what I was trying to say has been lost in his response, probably because I was unclear. Lets start with this ... "The Rails core team does seem to treat the project as if it’s a personal playground" This was said more in frustration with the coffeescript/sass decision than any real belief that…

Do assets in public/ break in 3.1? Sure, it's encouraged, but I'm pretty sure if you tell your web server to point to public/ it will serve your static assets from there. As far as I know you can upgrade your existing rails app from 3.0 to 3.1 and start using asset pipelining on your own schedule.

This is indeed correct.

Re: What’s Up With All These Changes in Rails?

#95

Post by tenderlove »

psadauskas wrote: post #21
euroclydon wrote: post #15

Earlier quoted context omitted.

Wow! This is the first I've heard that RoR's ORM is slow. That's it's slow because Ruby is slow, is even more of a shocker. I'd love to hear some practical limitations that applications using Ruby and NHibernate face when querying data. Is this slowness a reason that so many no-sql engines seemed to have sprung at the same time as RoR?

It is embarrassingly slow. I did some tests a couple years ago, on ActiveRecord 3.0.pre, and its 20x slower to initialize empty objects (no database access) than DataMapper, or just making empty Ruby objects & hashes. https://gist.github.com/260280 Edit: Ran it with AR 3.0.7 and 3.1.0.rc4. Granted, this is with a 2-years newer CPU, but 3.0.7 is a huge step up. 3.1 seems to have regressed again, I'll ping tenderlove a…

Ya, that is not acceptable. File a ticket for me (if you haven't already), and I'll fix this.

As a side note, we need to start keeping benchmarks like this and graph over time. We (rails core) should know about regressions like this before the general public.

Re: What’s Up With All These Changes in Rails?

#96

Post by roel_v »

bad_user wrote: post #9
ry0ohki wrote: post #3

It seems like a tough line, and I sympathize with both sides. Either you can go the Microsoft route and be backwards compatible til the end of time (which is great for devs, but causes baggage) or you can embrace change while the community is still young(ish). It seems like at a minimum, everything in a major version should be backwards compatible (ie a 3.0 project will work in 3.1 without changes) though.

Either you can go the Microsoft route and be backwards compatible til the end of time You probably never went with Microsoft to say that. Yes, they are shipping the DLLs till the end of time, but you can also find the source code to Rails 2.3 till the end of time (it's right there, in your face), just as you can find the source code of Linux 0.01 (the initial release). On the other hand, what's the latest recommended…

There is much, much MFC code written 15 years ago that still compiles without any changes today, with the latest versions of MFC. There is much to be said about Microsoft, but their development tools are top notch and robust, and for the long haul. There are MFC books that came out in 1998 and are still useful today because they contain the nitty gritty on what people ran into back then. Rather than changing everything, requiring much code to be updated, the issues are documented and people work around it. Is this nice? No, it's not, and I hated it when I was less experienced. Now, I love it - the time I spend learning them has paid off a hundred times over.

On the other hand, I've used web frameworks (mostly Symfony but also a few others) that look awesome in the beginning, but that require major changes when an update needs to be made a year later, because the latest and greatest has changed and the old is no longer supported. And they all support 'plugins', but you're fucked when you use them - sometimes they're upgraded, sometimes not, but when you use a couple you're always stuck; you need to upgrade the framework to use the latest version of one plugin, but another one only works with the old version, so now you need to replace all uses of that plugin with another, and change all the code...

Anyway that was a tangential rant, but Microsoft is really good at keeping a stable dev env, as long as you don't always use the first version of their new shinies (Windows Forms, ...)

Re: What’s Up With All These Changes in Rails?

#97

Post by speleding »

jarin wrote: post #85
sams99 wrote: post #74

Earlier quoted context omitted.

The rails 2 -> rails 3 upgrade path is one of the most complex upgrade paths I have seen for a web framework

I'm not so sure about that, for me it was mostly just moving gems from environment.rb to a Gemfile and updating gems/plugins. After that, I fixed deprecation warnings and moved everything to AREL/scopes at a fairly leisurely pace.

Did you forget about the always-on XSS escaping? Fixing just that took me more than a week on a large project. (I still think there should have been an option to switch it off for old projects.)

Re: What’s Up With All These Changes in Rails?

#98

Post by jarin »

speleding wrote: post #97
jarin wrote: post #85

Earlier quoted context omitted.

I'm not so sure about that, for me it was mostly just moving gems from environment.rb to a Gemfile and updating gems/plugins. After that, I fixed deprecation warnings and moved everything to AREL/scopes at a fairly leisurely pace.

Did you forget about the always-on XSS escaping? Fixing just that took me more than a week on a large project. (I still think there should have been an option to switch it off for old projects.)

Oh yeah, I don't remember it being THAT bad with haml. I think it was mostly just adding .html_safe in some helpers, but I could be misremembering.

Re: What’s Up With All These Changes in Rails?

#99

Post by sunchild »

rimantas wrote: post #91
sunchild wrote: post #56

Earlier quoted context omitted.

I'd really have to question the skills of any person who can't adapt from HTML to HAML. If you can do erb, you ought to be able to do HAML within, at most, an hour of pushing stuff through HTML2HAML. Speaking of which, HTML2HAML works nearly every time.

I can. I don't want to. There is zero benefits in doing that for me. SCSS on the other hand offers me that CSS does not.

You aren't required to use Haml. The point is that if your front-end designers can't adapt to it, they're not trying very hard.

Re: What’s Up With All These Changes in Rails?

#100

Post by wedesoft »

ssmoot wrote: post #49
gaius wrote: post #38

Earlier quoted context omitted.

Of course the ORM is slow! Is there anyone in 2011 who doesn't know this? Why not bite the bullet and learn SQL? Your DBA will thank you.

A 10% performance penalty to get down and dirty with your Domain Model and go all HSQL isn't exactly a big price to pay. Take a peek at Paul's benchmark. Iterate and instantiated 100K empty objects in 10s. That's crazy. You're talking about something that would probably take 1ms in c#. You're talking about a performance deficit four orders of magnitude large. Regardless, I think you've entirely missed the point. The…

The Ruby program takes more time because it is not optimised and it also checks for numeric overflow. The following Ruby program

    puts (1 .. 21).inject :*
will output "51090942171709440000". And

    puts (1 .. 21).inject(:*).class
will output "Bignum" because Ruby switches to big numbers when its integer representation is exceeded.
Post reply on HN