Yehuda Katz

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.

You can even write a Sinatra clone in very little code on top of Rails: http://yehudakatz.com/2009/08/26/how-to-build-sinatra-on-rails-3/

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…

As someone who worked on a Merb app fulltime for about 4 years (before merb 1.0 through to well after rails 3 released) it's more accurate to say that Rails got rearchitected with some of the good ideas Merb had on the backend.

When the plan was originally announced, Yehuda blogged (http://yehudakatz.com/2008/12/23/rails-and-merb-merge/):

In particular, we will do Merb releases with deprecation
notices and other transitional mechanisms to assist
developers in tracking down the changes that will come
between Merb 1.x and Rails 3. Expect a number of interim
releases that get incrementally closer to Rails 3, and
expect parts of Merb (most notably the helpers) to be
ported to run on Rails 3 in order to further reduce
friction.

This very specifically did not happen, and a lot of people are stuck on Merb or had a painful migration. Of note, Rails 3.0's first beta was released Feb 4 2010 (just over a year after the announcement), and 3.0.0 final was August 29. Merb had a 1.1 prerelease Feb 20, and the last version (1.1.3) July 10. Since then Merb has been dead.

Again Yehuda:

You will not be left in the cold and we’re going to do
everything to make sure that your applications don’t get
stuck in the past.

Now I'm sure as part of the merb community I can take some small part in blame of this, but nobody, not merb developers, not rails developers, not merb users (to the best of my knowledge) wound up putting any serious stock…

> Ruby's metaprogramming facilities are dead simple compared to Python's

I actually have the opposite experience, Ruby's eigenclasses and the self way to handle them to create class methods feels convoluted and shoehorning whereas __metaclass__ and the way you inherit of Class feels straightforward to me. The same goes for modules extending/including behaviors versus sane multiple inheritance combined with metaclasses and the way you manipulate methods and functions just assigning them as attributes, without any need for three handfuls of helper methods. Ruby's approach of development is so pervasive that I (and not only me) always have to check if I won't be tripping on someone else's wires. When I tell that, the Ruby crowd shouts at me that Ruby monkey-patching is safe! So let's make it safer[1]! It honestly feels like needless complexity, over-engineering, or jumping through more hoops.

I know both approaches quite well but I can't help but think that the Python approach just fits in, like a self-solving Tetris, whereas Ruby feels like I constantly need to solve puzzles. Granted it's fun when you learn the language, drawing a picture of where classes, instances and eigenclasses of each fit, but when you want to be productive you just want it to flow, not solve another damn puzzle of how I can do this smartly so that things don't end up making galaxies collide.

PS: don't get me wrong, I actually love both languages, but while it's love-love with Python, it's actually…

I really like this feature (which actually comes from Smalltalk's doesNotUnderstand:). It is actually supported on firefox[1][2][3] as __noSuchMethod__, but it is non standard, and should not be relied when writing cross platform js.

But then I guess the thread starts getting a bit off track, and I apologize. The point is:

Supporting other languages is good for the framework, and for the community

GWT took the position: Java source only. Cappuccino can take the same position: Objective-j only. It is fine. It is also limiting.

I am always happier when great frameworks support multiple languages, when it opens the doors for more people, instead of shutting down to a smaller community. It helps create greater value to more people, which I'm always for. It does have its costs. In the end, it is a trade-off which the creators and the community have to make.

PS: An example of a framework that does this (written ina more powerful language, supporting a less powerful one) is Akka[4]. It is written in Scala, but its Java interface, while more cumbersome, is so good that I could create a JRuby interface[5] that is even more expressive (thanks to method_missing) than the original one in Scala.

[1] https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/noSuchMethod

[2] http://stackoverflow.com/questions/3811408/node-js-overloading-functions

[3] http://yehudakatz.com/2008/08/18/method_missing-in-javascript/

[4] http://akka.io/

[5]…

> There is no progressive enhancement way around this issue, and an opt-in string doesn’t do the job either. In essence, we break backwards compatibility of scripting of the web. This could be not a big issue, if browsers supported ES6, but we’re not quite there yet.

This post misses the single most important tool for users (to help them try syntaxes), framework developers (to help them be more productive and consistent), and standards developers (to get feedback):

Transpilers.

Because much of ES5 is reflective (and ES6 even more so), it makes a great target for the translation of a new syntax into old syntax. This cycle of reflective-api-to-new-syntax is exactly what Yehuda is talking about in his post http://yehudakatz.com/2013/05/21/extend-the-web-forward/.

The impact of transpilers on ES module syntax, ES classes, and ES promises as been amazing. You can see the same thing happening with decorators/annotations today- real world use in TypeScript is influencing the discussions of TC39.

> The current support table of ECMAScript6 in browsers, parsers and compilers doesn’t look too encouraging. A lot is red and it is unknown in many cases if the makers of the products we rely on to run JavaScript will take the plunge.

I disagree in the strongest terms. ES6/E2015 is a huge amount of changes, and browsers have been driving the discussion and implementing items as they have stabilized.

Ember is the PostgreSQL of JavaScript frameworks.

Similar to the way Postgres has deep roots that trace back to Ingres[1] in the days before SQL was a solidly established standard, Ember traces it roots back to SproutCore[2] in the JS framework pre-historic era of 2010.

And the same way PostgreSQL was seen as a second-tier or only "historically significant" open source database, the PostgreSQL team just kept at it, toiling away year after year, steading churning out awesome code and excellent documentation, getting better and better with each release. Like clockwork.

In the same way PostgreSQL is now, finally, enjoying more popularity and getting the recognition (long overdue in my opinion) for the awesome platform that it is, I expect that in time more developers will come around to appreciating Ember. The Ember leadership is definitely approaching the project and the processes around it like they intend to be not just relevant but pushing the boundaries for a long time to come.

For one example this boundary pushing, you should not miss @tomdale's talk at ReactConf about GlimmerJS (the view layer extracted from EmberJS). It is, in my humble opinion, simultaneously mind-blowing and and inspiring.[3]

[1] https://www.postgresql.org/about/history/
[2] http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcore-2-0-is-now-ember-js/
[3] https://www.youtube.com/watch?v=nXCSloXZ-wc