Moving on from Rails
broadcastingadam.com
broadcastingadam.com
DHH said at the first RailsConf that he was tired of people asking if Rails would "hit critical mass" or become "ready for the enterprise" because Rails as a tool hit critical mass the moment it was useful to him and the core team that built Basecamp and Shopify. If anyone else found it useful then awesome, but everyone else can pretty much go fuck themselves.
Cocky? Sure. A lot of fun to be part of? Hell yeah.
I've never been on core but I can arrogantly speak for the early Rails community when I say that we excitedly encourage all Rails fans to try out Node, Django, SC and Backbone. Anything which captures your imagination and makes you see coding in a more whimsical, _why?-like way.
I recommend anyone that hasn't seen it check out Foy Savas' amazing talk from FutureRuby in 2009, Polyglots, Unite!
This seems to be a recurring pattern with developers who have "discovered" design and architecture through frameworks and can not seem to separate that from the tools used.
Linus is still writing code in C even for a simple GUI app that wxPython can do for him quickly.
Josh Bloch is still writing code in Java since 97/98?.
Crockford/Resig will probably never write software in a language other than JavaScript.
Your Application Developer will quickly move to the latest trend spreading HackerNews.
So if you want to be famous writing frameworks or tools, make sure you hit frontpage of HN.
The might be popular for "other languages nowadays", but he delivers those as a reason of Rails success BACK IN THE DAY.
And indeed it was. Not many PHP ORMS and scaffolding frameworks existed or where successful back then.
This is not new. There are lots of system out there built on top of private/public RESTful (XML/JSON/whatever)/SOAP APIs. There are both huge and small applications on top of distributed, stateless, components that clients can easily consume and that makes the whole architecture highly scalable (again: stateless). People can do this on HTTP, TCP, UDP or on TheirCoolProtocol.
I find it embarrassing that the community would vote up a story with comments like this. There is simply no need for it, and it shows nothing but a lack of articulation and outright immaturity.
If you don't like PHP, fine, but slamming it with one word insults does nothing but insult the tens of thousands of developers out there that use PHP to solve real world problems for a living.
Firstly, every time I see it getting slammed its nearly ALWAYS PHP in comparison to a framework whether it's rails, django, web2py or whatever. As soon as I see this I can't help but feel the author is just jumping on the "PHP isn't cool bandwagon". PHP isn't a framework, so don't compare it to other frameworks.
Secondly, it is possible to write good code using PHP - and many people do. It powers some of the largest sites in the world and there are more PHP web devs out there than any other working on millions of PHP sites. There are also some excellent frameworks for PHP that are quick to learn, fast and powerful. Codegintier, Yii or Symphony(2) all spring to mind.
Finally, for most web developers who actually need to earn a living writing code to solve problems, PHP is still the most popular choice for good reason. It's easy to earn, easy to deploy, cheap to host and widely used. There are also more PHP jobs (especially in the U.K.) than any other and it isn't changing anytime soon. For the busy developer trying to make a living these type of posts aren't really helpful at best and at worst quite insulting.
Facebook, Wikipedia, Wordpress, all of them don't have a good PHP codebase. In fact, people despise them.
PS: for the downvoters, why the hate? it's the fact though. I'm not saying you cannot write good code in PHP. What I'm trying to say is that "big sites out there" are not a good example of "writing good PHP code".
I don't know about the other sites you name, but if you had mentioned Yahoo you would definitely have had a point.
You've seen Facebook's codebase? I doubt it.
And when you show me a blogging platform more successful than Wordpress, then we will talk.
Who exactly despises FB, Wikipedia or Wordpress? Not the users.
And while I can't talk about Wikipedia and FB (haven't seen the source), neither do Wordpress developers (including the tens of thousands of plugin authors) despise Wordpress's codebase.
Also, it's not about how well you like it, it's about what you can do with it, and especially what you users can do with it.
Yeah, Wordpress could have been written in, say, elegant Haskell. And then it would have gotten nowhere, because very few people could have got it working on their webserver or on a shared server platform. And it would have lacked tons of extensions that PHP gives it, from Imagemagick to LDAP to DB2 client libraries --or it would have to use some less battle tested, less popular and less mature Haskell equivalents.
Judge for yourself (you probably have to interpret what he said there since obviously he doesn't say up-front "it sucks" but the words he chose describe the situation).
Maybe despise is a strong word.
But what's your point? successful project so they must have good codebase or something?
My original post was that "those projects don't necessarily have a good code base" (thus you may want to choose other examples to show a better written PHP code base).
You're off by miles.
I never implied that "because they are successful, they must have a good codebase". I actually made a different point, essentially asking in return:
What's a "good code base"?
Wordpress's, for example, is good at what it does, not in some idealistic theoretical way. Not only it resulted in a successful product (actually two: wordpress + wordpress.com), but it also has been proven stable (heard often of WP crashing mysteriously for any other reason that too much load and no caching which is totally reasonable?) and flexible to build upon (wordpress constantly adds features to its core and tons of developers add third-party add-ons).
I'd argue that "good" code base = flexible, extensible, successful, liked by IT'S developers. WP has had all of those. So, for THEIR PURPOSES and to THEIR DEVS, it is a good codebase.
On the other hand you implied that FB, WP, Wiki's code is bad. I tried to show that WP's at least is far from bad by MANY metrics. What are your metrics? Besides, say, proof by rigorous handwaving?
As for the FB presentation, he never says despise or sucks, as you mention. It's a classic presentation of some trade-offs. You'd have a selection of those even if you coded in Haskell or whatever.
People compare societies to Rome all the time, saying America or the western world is akin to the downfall of Rome, seemingly oblivious to the atrocities committed by various tribes ransacking the Empire. Not that I agree with comparisons to Hitler or Nazis, I think they're arguments of a weak mind, but history was a long time ago.
I've done some really nice stuff with this language. But it's still utter shit in so many ways it's painful. PHP is in many ways a lot better, but has some pretty fundamental flaws that still marks it as really bad. He did however, not say one thing about the developers that use PHP, so why would you slam him for that?
What flaws are these?
"He did however, not say one thing about the developers that use PHP, so why would you slam him for that?"
I've spent well over a decade of my life developing solutions for real world problems with this "shit" language. I founded a business on this "shit" language 4 years ago and we are going from strength to strength. So yeah, I think I have every right to slam him for insulting me.
Have you ever seen this piece? http://tnx.nl/php.html
Some of the issues mentioned have been dealt with in PHP5 but a lot of the problems will probably be there permanently, such as inconsistent function names, arguments and return values mentioned at the top of the piece.
That isn't an insult to people using PHP. Much like I sometimes say that soda sucks without implying that soda drinkers suck, he's saying that PHP sucks without implying that PHP users suck.
That said, the solution isn't to walk on eggshells around every topic that anyone could possibly have identified with. The solution is to be very, very cautious about making anything so much a part of one's persona that a stranger's critique of that thing feels personal.
He didn't insult you or slam you. He was talking about the language. You can make really neat things with a language that's really bad. Just don't take it personally.
I love Rails. It got me back into web app development in 2005 after nearly burning out. But Rails isn't exactly keeping up and people who need to move on are going to do that.
I've been saying for about two years now that
the days of serving entire HTML pages from the
serverside are numbered.
With things like Backbone, I can bring up a Rails
app without views
Rails gives you the possibility of doing progressive enhancements, when you need them. You don't have to build an entire Backbone layer, just for updating a small rectangle on your page, when you can just render a partial in a good old-fashioned way.
But Rails isn't exactly keeping up
Here's a prediction: 6 years from now, there will be more crappy heavy JavaScript based web-application out there and the biggest money making is to maintain and fix these apps.
At least for native graphical interfaces, you
have IDEs to help you out with bindings and all
that crap.
youu don't have to build an entire Backbone layer,
just for updating a small rectangle on your page.
I want to use a framework on the frontend for the same reason I want to use one on the backend... a shared codebase that more people than me understand, that offers some organization and guidelines to follow.
Rails gives you the possibility of doing progressive
enhancements, when you need them.
Thanks to modern screenreaders and a bit of proper coding, we can build apps that are accessible.
It's probably going to be a bit, but I don't want to wait around.
Instead of shaking my head going "it's hard"
I'd rather dig in and see what I can do.
Backbone is just a particular example, mentioning other JS frameworks is irrelevant as long as it gets you further away from the simple request/response model. And this is the crux of the problem - most websites and online apps do not need anything more than this simple model, which has served us well and will continue to do so for a long time. And developers felt in love with it because of its simplicity and effectiveness.
So here's my prediction - in 5 years from now, Wikipedia will still be running on top of the current platform (which is universally recognized to be aged and quite shitty), using the same model of interaction with users, but it will still be the most popular and valuable content website from this planet, powered by the biggest database of human knowledge.
I want to use a framework on the frontend for the
same reason I want to use one on the backend
Which is why I gave you a reply in the first place - you're making general statements because of very specific needs. I know it is fashionable to build a Facebook or Foursquare clone, however the UI is really not your biggest problem. There are other problems that are more important for applications like this, upon which you should pass judgment on choosing Node.js or Rails or something Java (IMHO, for applications like this I'm more inclined to use Java, as it has no technical limitations).
what percentage uses the low-fi version of the site?
And the way I see it - you can add progressive enhancements when you need them, not sooner. Starting with a dumb version of a site and enhancing it gradually also makes business sense.
It is my feeling that you're trying to justify the
usage of Node.js
wikipedia
I'm talking about interactive user experiences. In web apps.
No, there are clear use cases either way. On one hand you have documents, on the other you have multi-platform apps. For the former (which still vastly outnumbers the latter BTW), serving HTML from the server is the obvious choice, for the latter, a REST API is the obvious choice. There is a large gray area in between where you basically have documents with a relatively small amount of UI.
I agree that SOA based on REST service (particularly using JSON) are where the most interesting innovation is happening on the web today, but the venerable document model of the web will never go away because it actually fills a surprisingly large use case in a remarkably simple way (hence the success of the web in the first place).
Combine that with bandwidth caps and you start looking at creative ways to make things work more efficiently. One of those ways is to simply stop sending things down the pipe. Like the repeated layout.
For instance working with Drupal, my usual procedure was to immediately set up a custom extension, so I could start adding custom features there. I also spent a lot of time learning the filenames of special override templates to use to customize some very small portion of the UI. Sometimes something was impossible without forking an extension or even forking the Drupal core.
Eventually I mostly gave up on the CMS approach and started building websites using frameworks like Rails and Django, which can provide all the features of a CMS as components (gems/apps) which you can use as you wish. I found that this approach almost always suited my development needs much better, because I was no longer "fighting" the CMS.
There are plenty of ways to make things more efficient without abandoning HTML altogether.
When you send HTML to people, it should be for reading content. That's its purpose and I don't see that ever going away.
But when you're talking about having them interact with an interface, I don't see much of a reason for developers to continue to treat it like a 1970's terminal screen. We have tools that are getting better all the time.
Building a CRUD CMS is as exciting as watching paint dry to me. Yea people pay for it, but that's usually not the part of the project that's interesting. Doing the same "solved problem" over and over gets old.
And it gets scary, because new stuff is happening.
You can build applications now using things like <canvas> and Javascript and use almost no HTML to deliver your app over HTTP (although once we get to that point HTTP itself starts to seem like antiquated overhead).
I'm more of a Java than Ruby person but from what I understand Rails is mostly a collection of modules put together (ORM , MVC , Scaffolding etc).
Most of the web apps I build I spend about 70% of the time in the model layer anyway. Even if you were to use a completely different paradigm for front end development the majority of the components that a good framework provides would still be very useful.
This is why I prefer to loosely couple things as much as possible, that way you could in theory decide you wanted to do your entire front end in 3d using OpenGL or something.
I think there is also allot of middle ground between having serving content and having a fully interactive application.
There's a strong movement among some of the more verteran Rails devs to write abstractions, ensuring that the ap doesn't depend on the framework as much. So as needs change, things can, and probably should, change with it.
The problem with this kind of web-app is that it's so much harder, so much more difficult, so much effort is required. And you need to be very very discipline and build automation testing from ground up (and I know many developers are just lazy to write automation testing, don't give me the start-up/iterate faster excuse, lazy is lazy).
At least with GWT, there are patterns and good practices to support unit-testing and modularizing your app properly.
In JavaScript? the fight just goes uphill straight away. In 2011, we still don't have automation test framework that is headless (console based) without requiring investment to infrastructure. And this is largely because the mentality of JS developers is to test in real-browser. Which is fine. Except the extra effort required to setup automation-test will cause a lot of people to find more excuse not to write automation test.
I get that developers are optimist people. But time through time, developers get burned so bad. Most people don't even know how to write JavaScript code properly but they're so ambitious. These people bite more than what they can chew.
So... good luck doing that while some of us will stick with Rails/Django/PHP/JEE6. Get ready, you're in for a lot of pain.
It shouldn't be a grand revelation that there is more to web development than what runs on the server.
The author talks about the importance of having a platform to cater to the multitude of devices and other apps out there, and that this means rails isn't the center of the universe anymore.
To me, this does not necessarily mean moving on from rails.
It does mean moving on from writing all code in rails.
There could be a fullfledged backbone.js app powering a responsive ui, and a distributed clojure jobqueue making sure messages are fanned out to their destined networks in the backend. However, there is still room in this picture for Rails as a router of sorts.
Rails still makes it easy to quickly build a solid REST api, and easy to delegate long-running jobs to a separate system, in this type of architecture, Rails would have roughly a third of the responsibility / code that it has in a Rails only architecture, but it's still a vital component.
> PHP was shit then and is still shit now.
Way to go shitting all over so many peoples work.
No reason to be surprised there, right?
yeah, because picking the right font has always been way more of a task than domain modeling.. (yes, i know that ui / ux isn't a breeze, but this depiction is just insane.)
Flippant answer: Whatever works
Pointed answer: I am paid to write RoR apps. When I need to get stuff done at home I use Perl, if it's for the web I recommend Dancer[1], which was inspired by (i.e. nicked from[2]) Sinatra[3].
I've found MVC to be a little bit too much architecture and scaffolding for many tasks.
edit: Not to say I don't want an architecture, but the routes and templating of Dancer are the essentials. Occasionally I will find myself missing the bloody lovely validations in Rails' ActiveRecord, but I am usually grateful for the light weight of the finished product and the fact that the entirety of it fits in my head when building with Dancer.
[2] ;)
OK, no iPhone and the iPad is not very old. Wikipedia should change their contents, especially on the dates when the iPhone and iPad were launched.