I'd be curious as to exactly what features comprised the first released version of rails. Was it originally in the MVC structure we know today, or was it more a mixture of random parts that were refactored into that later?
Did it use a CGI model, or did it embed webbrick from the start? etc.
I used rails 0.8, which was a couple months after rails 0.5, the first released version. It was the same mvc structure, centered around activerecord, actioncontroller, and erb views. It embedded webrick for development, and production was a heinous cobbled-together choice of fcgi, fastcgi, or pcgi that you were expected to figure out for yourself.
It wasn't terribly different. Old apps are still recognizable as rails. It is just more polished now, and a few head scratchers have died off like RJS and components, and a lot has been refined. The biggest differnces are probably the asset pipeline, bundler, and UJS. Production hosting was an absolute nightmare. I never did understand it. Thankfully, it got better quickly.
From that interview: "The wonderful thing about the Web is that it divorces the notion of the native environment from the implementational technology. Any piece of programming language can spit out HTML and JavaScript, which means that you can build it in whatever the hell you want. It can be a tiny program. _You_ can invent a language and you can start using it and your users will not know the difference. So it really is this great equalizer in the sense of allowing new technologies to spring up and get serious traction because they don't need those network effects."
I was gonna say, it's not like I wanted to read it or anything.
Are you guys running a reverse proxy? It kinda looks like a naked Wordpress install that's borked. Really interested in the article; looking forward to you guys getting back online!
As a unit of measure, when I hit the top 10 on HN I get about 6-8000 hits in the day. I would imagine that a DHH article would be 5-10x of that.
This oscillates back and forth: we're never going to get rid of one side so it's pointless to start claiming the world has changed when a 60-40 split flips.
As an example: all of the apps which still work if anything, anywhere, doesn't load and run a huge pile of JS correctly. c.f. Twitter, Gawker, etc. The client side is fragile to an extent which simply isn't true on the server – this doesn't mean you don't use it but rather that you still have to think about what happens when something breaks.
Digging for controversy? He's pretty opinionated on where he feels JavaScript fits into the stack. Should be completely expected coming from the creator of a server side framework.
19 comments
[ 2.9 ms ] story [ 49.6 ms ] threadDid it use a CGI model, or did it embed webbrick from the start? etc.
http://www.transcribed-interview.com/dhh-rails-david-heineme...
From that interview: "The wonderful thing about the Web is that it divorces the notion of the native environment from the implementational technology. Any piece of programming language can spit out HTML and JavaScript, which means that you can build it in whatever the hell you want. It can be a tiny program. _You_ can invent a language and you can start using it and your users will not know the difference. So it really is this great equalizer in the sense of allowing new technologies to spring up and get serious traction because they don't need those network effects."
I guess they didn't ask him any questions about caching or scalability...
Are you guys running a reverse proxy? It kinda looks like a naked Wordpress install that's borked. Really interested in the article; looking forward to you guys getting back online!
As a unit of measure, when I hit the top 10 on HN I get about 6-8000 hits in the day. I would imagine that a DHH article would be 5-10x of that.
Does that mean that HTML is not there to decorate JavaScript? Or is he dinging Backbone and the other JS MV* frameworks cropping up.
As an example: all of the apps which still work if anything, anywhere, doesn't load and run a huge pile of JS correctly. c.f. Twitter, Gawker, etc. The client side is fragile to an extent which simply isn't true on the server – this doesn't mean you don't use it but rather that you still have to think about what happens when something breaks.
Would it be fair to say this is a subtle jab at JavaScript used on the server side, namely what nodejs is doing?