I empathize with the comments from the folks who are already heavily invested in Rails. It’s so easy to “just throw the whole stack at a problem” or “kill a fly with a shotgun.” This is always the way, and it’s why new ideas rarely displace the old ones directly. Instead, they have to appeal to a younger, nascent “market” that are not attached to the old product.
Padrino’s best bet is to appeal to a younger, fresher group of programmers who haven’t spent years learning Rails, just as Rails appealed to a younger, fresh generation of programmers who hadn’t spent years learning Struts. Those folks will find applications for it where Rails actually gets in their way. As they reinvent parts os Rails, they’ll invent new things that fit their model domain better than Rails does.
I’d bet that if Padrino becomes successful, it will do so with ORMs and other gems that aren’t popular on Rails because they haven’t been invented yet.
If you are resistant to adopting a new framework and having to reinvent a bunch of stuff, congratulations. You may be an early adopter or hacker in other areas of your profession, but as far as web development goes, you’re a conservative.
This is a weirdly emotional appeal that ignores the fact that Rails is not Struts, is nothing like Struts, isn't standing still, was more or less rewritten not very long ago by assimilating its best competitor, and that the next ORM or gem that isn't popular today on Rails is very likely to be bootstrapped and implemented in the context of Rails --- unless its key distinguishing value is "a not-Rails replacement for something Rails already does", which many people on this thread are pointing out is a seductive trap.
Rails is good. For an alternative to be compelling, it probably needs to be more than just "different"; it needs to be better. What I see people saying here is, yes, "stripped down" is different, but in practice that difference turns out not to be better. The parts of Rails you really can't get around using tend to be parts you're going to need in a Sinatra or Padrino app, and rewriting them just for the sake of it isn't a win.
Aw, come on, nothing I said was critical. It’s a very good thing to be conservative in places. If you’re sitting down to write a new program, how many things ought to be innovative? Where should you be breaking new ground? You can’t pick up a new programming language, roll your own new framework, learn a new programming paradigm, use it to start a new company and go into a new market, all at the same time.
You pick and choose your battles, you pick and choose where you’re going to trade a little risk for reward. For the things Rails does well, there’s very little attraction in replacing it with something that is not-Rails if you already use Rails. Ergo, something not-Rails has to either do somethingRails doesn’t do well or appeal to people who don’t already know Rails.
Rails isn’t standing still but neither is Java web development. My ex-colleagues are constantly boasting of the great new things going on in my old ‘hood. But even so, the great new things are centered around the old things it already did well. Same with Rails, it does a particular thing well and “not standing still” doesn’t mean it will magically turn into node.js one day.
If we were talking about startups, nothing I am saying would arouse the slightest controversy, it’s the old “crossing the chasm,” “disruptive innovation,” or “innovator’s dilemma” mechanics, only for a free tool instead of a business or service.
You didn't say "Java web development", you said "Struts".
You didn't say "break new ground", you said "younger developers".
You didn't say "pick and choose", "risk and reward", you said "resistent to adoption" and "conservative".
And you said it on a thread mostly populated with people who used Sinatra --- we weren't "resistent" to Sinatra (I was seduced by it). We adopted it. It turned out to be poorer than Rails for our use cases. Given two options, one of which was better than the other, we used the better option; that's engineering.
> We adopted it. It turned out to be poorer than Rails for our use cases.
Yep I had this exact revelation with a project I was working on. About half way through implementing my own general-purpose validation function and REST/CRUD routes for my models I admitted to myself that I was wasting time. These things are solved problems. I have a much greater appreciation of Rails as a result.
I use Sinatra as a quick way to put a web interface on top of Ruby code, Rails for any non-trivial CRUD paradigm web application.
I disagree. The main reason I dislike Rails is that it is too complicated. When working with it every day, I regularly come across issues with it that require that I delve into the source code. More often than not that is a depressing venture.
I would love something more simple, that operated with less magic, and had code that was easier to understand. I'm not sure if Padrino is the answer, but it certainly merits a second look.
When's the last time you had to dive into the Rails source code? The only bits of Rails I'm consistently familiar with at the source level are the code that maps HTTP parameters to the "params" hash and into AR model attributes, and the session cookie stuff --- and those are professional interests, not "I couldn't figure out how to use it" things.
I'm asking seriously, because I spend about 20% of my work time writing Rails code for a bunch of different Rails apps, and --- at least since Rails 3 --- I never have to do this. And I'm a C programmer, so "diving into the code to figure shit out" is a first instinct for me too.
About a week ago I had a problem with after_commit callbacks not being called. It turns out (after diving into the AR source) that they indiscriminately swallow errors from after_commit callbacks. If you're testing a newly-created callback it is difficult to determine whether it's actually been called or merely just raised an error.
I couldn't have figured that out without reading the source- it's not documented. From the developer level that behavior is indistinguishable from magic, and the callback code in AR tries to act like magic as well. It's extremely difficult to follow, let alone understand.
"The after_commit and after_rollback callbacks are guaranteed to be called for all models created, updated, or destroyed within a transaction block. If any exceptions are raised within one of these callbacks, they will be ignored so that they don’t interfere with the other callbacks. As such, if your callback code could raise an exception, you’ll need to rescue it and handle it appropriately within the callback."
"The whole callback chain is wrapped in a transaction. If any before callback method returns exactly false or raises an exception, the execution chain gets halted and a ROLLBACK is issued; after callbacks can only accomplish that by raising an exception."
Huh. Thanks. I looked for a long time and didn't see that. The closest I got was an extremely old lighthouse ticket where Aaron Patterson suggested that they change the behavior to raise errors, but there was no followup.
i didnt want to write new code each time my data-model changed: migrations, model code, new controllers/views. this meant a Resource class, a uniform controller request/response cycle following web-arch/linked-data standards. at this point, would have had to significantly monkeypatch both rails and its attempts at providing a generic Resource class to override its magic (and/or incur the CPU usage for the magic to do what i didnt want). it was a lot simpler to just start with a Rack handler from scratch.
ive been using my web framework for 5+ years for personal and professional projects, and as far as i know there are no other users. Ry Dahl was churning out all sorts of 'concurrent' web-frameworks and servers in Ruby building on EventMachine and so on for years, and im pretty sure i was one of the only people using his code. eventually he scored a hit as node.js when finally rewriting one of the concepts in Javascript
I can second most of this. I haven't needed to dive into the source on Rails 3 at all, except for figuring out why some bit of backwards compatibility wasn't quite working. Considering the project was initially written on version 1.mumble.mumble, I haven't even had to do much of that.
When I started working with Rails, I didn't understand it. I wanted to see how all the magic worked. Then I gave it a second go, and skipped trying to learn how Rails was built, but just assumed the framework worked the way all the code samples said it would work. Success.
Rails definitely makes specific assumptions about how things should work and especially how database operations should work. If you're always looking under the hood, you're probably right -- it's not suited to your style.
Take a look at Ramaze. It's my first choice for doing Ruby Web development and I've found it works really well for projects of any size.
What I especially like is that I can start with a single-page static HTML "app" and evolve it out as needed, and refactoring or moving things about are never an issue.
I don't worry about having to turn stuff off or tripping over someone else's conventions.
(For the latter: I do not like the convention of grouping all models in folder, all views i another, and controllers off some place else. I prefer to treat related MVC components as a "tuple" and keep them together. This is how, for example, it's done with Monkeybars; I find it much more logically coherent, and this is how I organise my Ramaze projects.)
I had to learn Rails & Ruby at the same time. Early on I struggled because it was hard to figure out where Ruby stopped and Rails began. It took me about 6 months to get comfortable with both of them.
> If you are resistant to adopting a new framework and having to reinvent a bunch of stuff, congratulations. You may be an early adopter or hacker in other areas of your profession, but as far as web development goes, you’re a conservative.
Then I must eat rocks and ride dinosaurs, because Rails is already too fast-moving for me.
I don't do Rails full-time right now, and my biggest problem is that Rails changes all the time. Rails' documentation is basically a Googleverse full of blog entries, and you have to compare the (often hidden) timestamps to understand which blog entry is more relevant. I often enjoy a Railscast only to find out that nothing of it is applicable anymore.
Minor updates to Rails, Rubygems, Bundler or even Ruby can break everything without warning. And dare you accidentally admit to #rubyonrails that your customer is still using svn or not on 1.9 yet, and you will be publicly ridiculed. It takes some time every month to even keep your existing Rails apps secure but running.
Excuse the rant here, but from a casual Rails hacker's perspective, I actually miss stability and not change.
Yes, I particularly enjoyed applying security fixes from the so-called stable branch and suddenly having all my validation messages corrupted, or form parameters randomly truncated.[1]
I'm all for new ideas and tools, but you have to bring something to the table other than just being different. And just being "smaller" is not enough.
This is the problem with Padrino- it isn't different enough. We don't need a smaller MVC Ruby framework, as there isn't much space between what Sinatra is great for and what Rails is great for.
There is also an assumption that scaling Sinatra up is a good idea. I'd propose that it's likely not.
It actually turns out that being smaller can be worse if it means you're just building a half-assed implementation of something Rails 3 already does well.
There is a lot of space to cover between a bare-bones HTTP DSL (which Sinatra is) and an opinionated full-stack like Rails. For example, Padrino allows you to freely choose between a lot of Ruby ORMs _and provides support_ to use them. Try that with Rails.
As another example, Padrino allows you to do Rails-Engine-like things in a very natural way (by hosting multiple applications in one Stack etc.). It is not a Rails rehash on a different base.
The Rails 3 rewrite / MERB integration was supposed to accomplish this by allowing pluggable ORM's and different libraries. Is Padrino trying to be the new MERB? I think extending Rails to be more modular is the way to go, not more frameworks.
Can you host arbitrary Rails applications in other rails applications like you can host arbitrary Padrino applications within another Padrino application? (it should even be possible to host padrino apps in any other rack app, though I've never done that so far, it might need a little hackery)
Rails is a Rack application, so yes a Rails app could play host to more than one sub app. In fact this is such a good pattern, that Rails core added Rails Engines which do just but better.
I'm utterly content with Rails 3. Having used versions 1 & 2, I can definitely say 3 is quite an upgrade and decoupling which is competitive on most of the points in this slide. It's almost like this slide was based on a Rails 2 comparison.
I find rails popularity picking up, but I don't think we're anywhere near comparing it to struts yet (I used to be a j2ee dev and used struts quite a bit... painful).
When I want to play around with the next big thing I mess around in Node.js.
I've known about Padrino for a while now (and built some small apps with Sinatra), and I'm sure it fits some peoples needs and is a great project... but I have yet to become interested enough to bother. It's just not that appealing right now, and I don't think it's because I've become too comfortable or conservative etc. Of course if I start to hear a lot about it I'll spend a little more time playing with it.
>Padrino’s best bet is to appeal to a younger, fresher group of programmers who haven’t spent years learning Rails
Anecdotal contradiction incoming. I started with Rails years and years ago (can't even remember when). I moved to Merb when Merb was the new hotness because I preferred it's modular approach. After Merb was "merged" (i.e. a few of its philosophies were put into Rails and Merb died due to lack of development), I caught on to Padrino and was impressed by it for the same reasons I was impressed by Merb. I program in Rails for a living but use Padrino for my personal projects.
I actually think a potential knock against Padrino is that it's not quite as easy to get into as Rails. When I got into Rails, it was all "create a blog in five minutes" which is what attracted me to it. There was a point where I didn't even understand the distinction between Ruby/Rails -- it was just one big scripting language to my PHP-addled mind. I think Padrino (or even just plain Sinatra) has a slightly steeper learning curve; but it's hard for me to comment on that necessarily because I am no longer a beginner and my perspective is a lot different.
I learned and fell in love with Rails because I was stuck working with Struts and I saw how much easier and better life could be. So, at least for me, the decision to use a different framework didn't follow what you describe. I'm pretty sure if I came across something that allowed me to solve my problem in an easier and better way than Rails would, I'd use that instead.
For example, if I were building a mobile API that I was fairly sure wouldn't require a web interface later on, I'd consider using something simpler and more performant than Rails. It's not a matter of being an early adopter vs. a conservative developer, it's a question of practicality. As it always should be.
I love the idea. No unnecessary crud, simple, clean. What's not to love?
It's the practice that I'm having problems with. Medium-large projects have tendency to actually use big part of the bag of tricks Rails provides.
But smaller ones, where Padrino should shine... it doesn't. When running one or two server processes, I don't care that it consumes 30MB more RAM than it should, or renders take two milliseconds longer than they could. If I did, I would use something else instead of ruby. However, when I actually try to use that one neat feature, only to remember that it's Rails-specific, or find out that this gem I'm not familiar with has documentation only as far as Rails-integration is concerned, that's a real and measurable dip in my productivity.
These small projects are usually weekend hacks where I would rather not spend time writing boilerplate I know can be replaced by one line by that other framework, or digging through sources of a library before I can start using it. It gets very tempting to just throw in the whole Rails stack and focus on the interesting bits.
These problems could be alleviated by more widespread use of other Ruby web frameworks (and I do wish they gain more traction!). But right now, my laziness keeps me from 'being part of the solution'.
As someone that has been writing production Rails and Sinatra apps for years, I have to recommend against using Padrino. Rails scales up and down pretty well, and I don't really see a need for Sinatra in anything but very small or single-purpose apps.
If you already know Rails, there is very little reason to build a substantial app in anything "smaller". The reality is that for any moderately-sized app, you will end up using many of the parts of Rails that you think are unnecessary in the beginning. Especially as your app grows.
I tried using Padrino for an app a year ago, and while the framework has probably matured since then, I moved back to Rails fairly quickly due do a lack of polish/documentation/community/benefit other than being different.
There is a common tendency to find a part of a framework that doesn't work exactly the way you want, and in turn throw the entire framework out and seek out or write something new. I still prefer the way Merb and Sinatra handle responses, where the controller action return value is the response sent to the client. But the benefits that Rails provides so outweigh many of these kind of preferences that it's usually best to just embrace the way the framework works and move on to actually building an app that does something.
It's also short sighted to discount how valuable the wealth of existing documentation and extentions exist for an established framework such as Rails.
The presentation makes it sounds as though by using Rails you have to use SASS and Coffeescript. This is not true, you can easily use plain JavaScript and CSS if you want.
The majority of developers will be more productive in Rails.
This reminds me of Flask for Python (nb. although more is built in to Padrino, most of the functionality for Flask is provided by plugins). I've recently started using Flask for new projects in favor of Django. I feel that most of the libraries I use are framework agnostic, stuff like ORM (SqlAlchemy), PDF generation, redis/mongodb adapters etc, so being able to pick what fits and leave the cruft out is great.
But besides that, I feel that in recent times development is moving much more to the client - and client code like Javascript/CoffeeScript, Java for Android and Objective C, is getting much bigger at the expense of server side code. This is recently evidenced by the new 37signals Basecamp Next app which is 50/50 CoffeeScript/Ruby.
So the server side programming is on track to becoming "just" a API endpoint for all these different technologies and I think micro frameworks like Flask and Padrino are very well suited for that.
Could you go more in detail with your experience with Flask? I am new to web development and I am developing a landing page in Flask. I tried to use Django or Rails in the past but I just hated not being able to understand what I was doing. Flask is really, really, straightforward, I rolled out my own authorization plugin as a decorator and it feels good to be so close to the application. But I keep thinking if I should move to RoR in case my landing page succeeds and I will have to build the real application. Mostly, I am concerned about hosting and scaling...
I'm working on Fiasco, which intends to be similar to Flask but for Ruby. It is still a work in progress, but you can see it here: http://tizoc.github.com/fiasco
Ok seriously, why the flamebait title? This deck is about padrino, yet it's no where in the title. We should be enticing discussion not argument in our titles. Also, now I'm not going to be able to find this post in a search. I'm going to have to search through all the negative posts about rails to find it instead of just searching for padrino.
If HN had downvotes on submissions, this is one of the rare cases I would find it useful as 'flag' doesn't seem to really qualify.
Padrino is the perfect framework for Djangonauts who want to learn a ruby web framework whilst also learning the language, which was my case 1 year ago. Especially those who don't like the "rails way".
It has most everything we love about Django: admin site, mountable apps (which I consider actually better than Django's), speed (it is as fast as Django in my benchmarks) plus a sane and flexible routing sytem, generators, localization, full support for various subframeworks and a much, much better configuration system (no global settings file!).
Would like to hear from people who have taken a user-facing Padrino/Sinatra app all the way through production and into maintenance.
I have a few tiny services and extremely specific apps running on Sinatra, but any time I've needed to expose any kind of richness to the user I've ended up reimplementing in Rails as I kept reaching for things in ActiveSupport / ActionView etc.
At some point I notice myself essentially recreating Rails' structure in my 'lightweight' app and think 'why don't I just use Rails?'.
This is exactly what happens to me, and is also the sense I've gotten the couple times I've had the opportunity to review other people's Padrino apps.
It's not that there's anything wrong with Sinatra and Padrino. The problem is twofold: the idea behind those two frameworks is seductive, but Rails 3 is really good. It's just not a stupid framework.
We have been transitioning from the "big Rails app" model to "many small [whatever] apps". Usually, "whatever" is Sinatra.
A new project, instead of being one monolithic Rails app, is a small frontend communicating with 20-odd small micro-services, each service with its own data backend tailored to its use case.
What I like about the Sinatra model is that creating an app feels less like a "Sinatra app" than a "Ruby app" which happens to use a bunch of libraries that together make up a web stack. With Rails it feels like you live inside a big, elusive container that is in control at all times. In other words, you are in control; you mount your Rack classes and build your stack from scratch.
Doing it this way doesn't mean we don't reap the benefits of the Rails universe. We use ActiveRecord, ActiveSupport, HAML, SASS, Sprockets, Compass, Unicorn, etc. -- pretty much the same range of technologies we would use with Rails. But we are less constrained about what we choose (or reject), and we don't have to be compatible with whatever convention Rails imposes at the moment.
I do all my production app in sinatra/padrino. I like the fact that I can do pretty much every app from a simple api to a full webapp with the same stack without changing the framework.
I never miss ActionView, but sometimes include parts or all of ActiveSupport, so I don't miss that either. I love the simplicity of the sinatra stack and I've never been much of a rails fan (too tightly integrated for my taste, the 1.x and to a lesser extend the 2.x version were too magic sometimes etc.) Most middleware is rack-based anyways.
For me the winner is that a padrino app is a full, mountable rack application so I can mount any padrino application anywhere inside any other application. I can actually implement complete components as a padrino app and mount and reuse them anywhere I wish. (The padrino admin works that way)
Can you be more specific? I'm curious. What are the bits of ActionView that get in your way? I ask because to me, as far as views go, both Rails and Sinatra are just hosting systems for Haml. If anything, it's Sinatra that got in my way (it doesn't have explicit partial support, so there were minor things I had to tweak). I can't think of many "features" of ActionView I used.
I generally agree that Sinatra was an easier sell in the Rails 1.x and 2.x era, before Rails ate Merb.
Sorry, I didn't want to imply that ActionView gets in my way - I just don't miss it. Padrino uses the excellent Tilt templating library and it loads pretty much all template engines I could wish for and it does add explicit partial support to sinatra. That's about all I could want from ActionView. I don't like or use form-builders for instance, I prefer not to use the js/ajax-helpers etc.
I guess it boils down to a matter of preference: I prefer my stack to be built from the ground up on a solid foundation by adding pieces I want and need in my app - and that's what I can do with padrino. If I'm writing a pure API it's sinatra plus the padrino router, tilt, maybe an orm and that's about it. If I need something more comprehensive I can add components on top of that that add the required functionality (render-helpers such as partials etc.)
Yeah, I haven't used the form helpers in ages, I just write normal jQ Javascript code and pretend Rails doesn't have "ajax" support, and I hardcode my links instead of using link_to. You're right, there's a bunch of stuff ActionView does that I've had to opt out of using.
My problem with sinatra is that I rarely work on a small well defined project. Usually these projects grow beyond their original scope and sinatra is not equipped to deal with that. I don't see the problem with creating a nearly empty rails app.
Padrino is really nice web framework for Ruby. I have used it for experimental projects.
My work was using latest Padrino framework at work, but extremely unhappy with the its performance (slow response). We had ported the app to Rails 3.1 for better performance. (We will upgrade it to 3.2 soon)
In fact, I think Padrino is pretty ideal for personal and small apps. Not really ideal for medium to large apps.
I am not against the Padrino web framework. I still like it. :-)
So your benchmark only have tested against the small "Hello World" app. Maybe that's why I suggested that Padrino framework is pretty ideal for small/personal/API projects for fastest responses.
Have you tried benchmarking your one of biggest padrino apps?
Yep, speed is 4-6x faster, but most important for me is memory usage is much much less.
On every Rails project I need to use monit/god to stop/start when for xx cycles memory is > 100mb or so. Without that a rails project can sucks 1-2gb of ram.
Isn't quite normal to my standards, in fact generally Padrino doesn't need more than 70mb. But here a lot of work must to be do.
Sorry if I have to ask, what part is not 100% true? You mean that padrino app can be still faster with large app?
You said there are more than "Hello World" benchmarks? I looked at the link that you provided and then looked at this source code of the Padrino app and its still "Hello World":
Not a very very complex use case but a bit more than a `hello world` app.
I love Rails, Im using i.e. ActiveRecord in 90% of my projects. Beside that I ported 162 apps over Padrino not because I've free time to spend but because I need decent performances (without kongfu with mem/redis caching) with less memory usage.
Try to browse rails (minus ActiveRecord) source code and padrino source code to understand what I mean.
I ported my current app from Rails to Padrino and found the performance, in dev and production mode, generally faster than Rails. I made the switch when Rails performance in development mode became unbearable on my machine, although I believe Rails has gotten faster in development mode after subsequent releases. I am quite happy with Sinatra/Padrino and have no reason for switch back anymore.
What even constitutes as a "small" or "large" application?
My current Padrino project is around 2000 LOC, excluding tests. As it has grown more complex, I've broken off larger parts of its functionality into smaller apps within the same project. These apps share some resources -- particularly models -- but in terms of controllers and helpers, they are very much distinct in their roles in the overarching project.
Padrino has changed my mindset on how I approach large projects. Instead of trying to create something massive in itself, I logically separate key parts of the overarching app into smaller apps mounted within the same project.
I question the entire concept of a "large app". When classes are too large, methods are too long, it's generally considered to be sub-optimal code, or poor design, and there's a point where one is expected to break these things down into smaller pieces. Why does this concept not apply to our web apps?
Thanks but no thanks. Having just become a productive Rails programmer and grasped a lot of complexities, use cases and diversity of the framework, I'd rather use the shotgun that Rails is to kill any fly that stands in my way.
I can see where you are coming from, but ruling something out because another thing is doing it's job (in your opinion) is parochial. Unless you try new things out, you can never improve your existing workflow. You don't know what you don't know unless you explore.
Even though I agree with you in trying new things out, I think that never settling with an established tool is pointless. We are trying to get things done here.
My point is, I like trying new things, but I prefer to stick with tested and supported tools when working in a job, and leaving these new things to personal projects or hobbies.
Rails has not only a huge community, but a huge support of third party libraries that while they may not be the best performance-wise, they allow you to accomplish the project's goals.
This. I've already expressed similar sentiments, but another point to consider is the ever-changing Rails gem environment. Thoughtbot are now releasing new updates every 2 weeks and their gems like paperclip are invaluable. If you invest your time into a Padrino gem ecosystem in addition to keeping up with things like Devise/Paperclip et al, when will you have time to sleep?
Yehuda Katz made a good point in this episode of ruby rogues http://bit.ly/w7PJ0o about how he uses rails even for small projects.
I use rails for everything, there is so much going on for you behind in the scenes in the way of security and configuration that it doesn't make sense to go back and roll your own on a minimal framework.
As someone that's just crossed a year or Ruby/Rails learning, having scaled the majority of the now massively steep learning curve, I'll stick with the complexity that is Rails.
"sunk costs are retrospective (past) costs that have already been incurred and cannot be recovered", says Wikipedia. However, investment in Rails can be "recovered", because it's a useful, marketable skill. Switching to something else will incur costs as well, so the benefits would need to be both high and certain to really make it a 'sunk cost fallacy', no?
It is. You're conflating several different notions. A sunk cost fallacy is the idea that because you've invested a certain amount of resources (time, in this case) in a particular approach, it would be foolish to switch because all the resources you've already expended would be "wasted."
My understanding is that sunk cost fallacies are where people consider the past when they should be only looking at the future. However, the future in his case means that he has Rails knowledge X, and has Padrino knowledge 0, so looking at the future from right now, Rails still makes sense unless Padrino is so much better that it outweighs the switching costs.
> A sunk cost fallacy is the idea that because you've invested a certain amount of resources (time, in this case) in a particular approach, it would be foolish to switch because all the resources you've already expended would be "wasted."
No, you're using the wrong word here. It isn't a sunk cost when you've invested resources (i.e. can recover value from those resources in the future), it's when you've spent (i.e. cannot recover value from the resources) resources.
The knowledge gained from learning Rails is obviously recoverable, and can be directly applied to future work. Throwing that away is not a sunk cost issue.
I stand corrected then. In my defense, however, I was talking about the time invested being a sunk cost, as the time is not recoverable -- and that's what the person I was responding to mentioned. The time.
Not sure why the author of the slides presents rails as a confusing mess. If you don't like the asset pipeline then don't use it. If you don't like the scaffolds then don't generate it. If you don't like active record, then don't use it.
I love the fact that these new frameworks are popping up, but why try to pull down rails in the process? If this addressed legitimate issues rails has, then I would not have a problem, but what's presented seems superficial.
I would love to know how Padrino lives with mongodb. Will the admin generator work with mongomapper or mongoid?
The asset pipeline you can easy do without. I've forgotten Rails even did Scaffolds. But even though AR is "pluggable", you're working against the grain in Rails if you don't use it.
I mostly disagree - nowadays it isn't AR that is essential ime. AM on the other hand is utterly essential and I end up implementing parts of it on almost every nonAR-model to get the nice interaction with AS.
I definitely love Sinatra, and I'm impressed by the admin interface, but it looks like there's no support for DataMapper as an ORM.
I also wonder if this is just turning Sinatra into Rails. I think for the now I prefer to just build a Sinatra app and add gems and plugins as I need them.
Same here. I really like Sinatra's gem ecosystem, and with unobtrusive Javascript I don't have much framework-dependent code on the views, nor helpers like his link_to confirm example, in the presentation...
I admit that sometimes I miss generators, but Sinatra's boilerplate code is so minimal that I just don't care much anymore.
Padrino supports the following ORMs out of the box: mongoid, activerecord, datamapper, couchrest, mongomatic, ohm, ripple, sequel. Take a look here: http://www.padrinorb.com/guides/generators
Padrino is just a Sinatra app with a very basic skeleton and some added functionality. Almost all the pieces are modular and doesn't have many requirements from the start.
The thing I like the most about it is the part where they demonstrate selectively including certain elements into Sinatra. I like Sinatra exactly because it doesn't come with the kitchen-sink - like you I prefer to just add gems and plugins as I need them (and I rarely find I do), but if I do I might look at Padrino.
(As for the admin interface, their site claims it has DataMapper support)
I remember using Datamapper with Sinatra to develop a pretty basic system for some weird user registration needs of a company offering medical assistance in the way of air ambulances in 2010. I don't really know if it's still supported since I've been doing .Net stuff since then... but I can definitely tell you it WAS supported two years ago, and I seriously doubt that they don't now.
I'm sure Padrino has a niche in the Ruby community that it will appeal to, but I wish it brought more to the table than just being smaller than Rails and more full featured than Sinatra. If, say, it was engineered to be completely asynchronous, like node, that would be killer.
Its nice and I can see myself using it in very specific instances, but it doesn't feel like the Rails killer that the post title claims it is, but that's just me
The only thing I see wrong with this is lack of coffeescript. I love coffeescript like bill clinton loved getting dome in the oval office, and if anything is without it, i will either cry, build support in myself, or both (at the same time?)
Anyway the point of this comment is please give us coffee! It looks like padrino has everything else covered and I really like the idea.
I believe the problem everybody trying to solve is that Rails is poorly suited to build RESTful APIs. If you love Rails and still want that, mount something like Grape (http://github.com/intridea/grape) inside your Rails app.
Padrino’s best bet is to appeal to a younger, fresher group of programmers who haven’t spent years learning Rails, just as Rails appealed to a younger, fresh generation of programmers who hadn’t spent years learning Struts. Those folks will find applications for it where Rails actually gets in their way. As they reinvent parts os Rails, they’ll invent new things that fit their model domain better than Rails does.
I’d bet that if Padrino becomes successful, it will do so with ORMs and other gems that aren’t popular on Rails because they haven’t been invented yet.
If you are resistant to adopting a new framework and having to reinvent a bunch of stuff, congratulations. You may be an early adopter or hacker in other areas of your profession, but as far as web development goes, you’re a conservative.