6 ms·

Moving on from Rails

122 points by michaelty 15y ago

mceachen 15y ago
I don't understand why this article is remarkable. It shouldn't be a grand revelation that there is more to web development than what runs on the server.
- dmix 15y ago
  Or a developer getting disinterested in the framework he has been using for a while, for that matter. It's pretty common.
bphogan 15y ago
This is less about moving on from Rails and more about moving on from building static pages from a database. Lots of web folks have been predicting this. 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 and do something pretty awesome. And then it becomes a question as to what Rails offers. 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.
- jshen 15y ago
  I just got finished porting an admin panel from rails views to backbone.js and doing anything in backbone.js is a lot more work. Not only that, you still end up using rails views because you probably want to send pre rendered html to the client to minimize their wait time.
  - bphogan 15y ago
    Just curious, but did you use a JS templating language? Cos we've been sending json back and pushing it to mustache templates which seem to render pretty quick.
    - jshen 15y ago
      I used underscore templates. Rendering large complex pages is slow. Doing it client side on an iPad is not good.
- jiggy2011 15y ago
  I'm not sure that is true for even the majority of cases. Remember that most of the web is not applications but simply pages of content server from a database.
  - bphogan 15y ago
    But that stuff doesn't need Rails. At all. I'm talking about applications where people do something. The CMS problem is largely solved. Generate static pages from database content. 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.
    - jiggy2011 15y ago
      I wouldn't say the CMS problem is 'solved' exactly. Sure, you can install drupal or something but in the majority of cases I still end up building something with a web framework to server out mostly static content (i.e stuff that changes, but not on a second by second basis). Off the shelf CMS is often either underkill or overkill. There are plenty of ways to make things more efficient without abandoning HTML altogether.
      - bphogan 15y ago
        I think you misunderstand. Or perhaps my comment wasn't well stated... Serving staic pages is the solved problem. So is CRUD-based Rails apps. We know how to do that. In that sense, it's solved. We can use Wordpress with Rails, or Radiant, or we can roll our own in half a day. 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.
- bad_user 15y ago
  I've been saying for about two years now that the days of serving entire HTML pages from the serverside are numbered. You'll keep saying that for another two or three years at least. With things like Backbone, I can bring up a Rails app without views Backbone-style development sucked when people did it with Microsoft's MFC, it sucked when people did it with Java's Swing and it sucks right now. At least for native graphical interfaces, you have IDEs to help you out with bindings and all that crap. 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 It's just a tool and not all of us need to build GMail. People treat Rails like it's their girlfriend or something.
  - bphogan 15y ago
    There's so much here I don't even know where to start. At least for native graphical interfaces, you have IDEs to help you out with bindings and all that crap. Yes, and we had slice and dice dreamweaver. But tons of Rails developers hand-coded their views. You're saying that because it's more work, people won't do it? You're probably right. Thankfully for the super lazy, there are Rails plugins for Backbone that generate a scaffold. And there are other JS frameworks out there besides Backbone. And as more folks work on these problems, maybe we'll get an even better solution. Instead of shaking my head going "it's hard" I'd rather dig in and see what I can do. youu don't have to build an entire Backbone layer, just for updating a small rectangle on your page. You said not everyone is building "GMail". Not everyone is buildign CRUD apps anymore either. And for those of us with users that are seeing sites like Facebook and Foursquare and are demanding interactions where the page doesn't refresh, partials become an absolute nightmare. I have many that I work on. It's a mess. 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. As an ccessibility proponent, I completely agree that Rails gives us the ability to do progressive enhancement. But it becomes a business question - what percentage uses the low-fi version of the site? Does every project require it? I'll be glad it's there, and doing a non-JS site is in my blood, but reality is that I don't think that's going to be the case in the future. 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.
- dasil003 15y ago
  > I've been saying for about two years now that the days of serving entire HTML pages from the serverside are numbered. 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).
  - bphogan 15y ago
    Sorry, what I meant about serving HTML from the server was the construction of HTML documents using server-side code. There will always be static pages served with apache or whatnot :)
fosk 15y ago
I think the whole point here is: build APIs first, wrap all the client code around them. If I have an API written in Ruby/PHP/node.js/Java/whatever, and a standard format (or protocol) to exchange data, I can then build the clients in Ruby/PHP/node.js/Java/whatever, clearly separating the backend and the frontend which can now be built in completely different ways using different technologies. 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.
choxi 15y ago
great summary of architecture trends. i think there's a room out there for someone to build a framework with the server-side simpleness of Rails and the client-side elegance of Backbone/SproutCore
rickmb 15y ago
The author seems to consistently confuse architecture, languages and frameworks. None of his arguments have anything to do with Rails, Ruby, PHP or whatever else he mentions, except partly Javascript. 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.
- kayoone 15y ago
  thought the same, like he says PHP was shit and still is (which is partly true) but then delivers CRUD Tasks, ORMs etc as the reason for Rails which also are very popular in all other frameworks for other languages nowadays.
  - dextorious 15y ago
    """but then delivers CRUD Tasks, ORMs etc as the reason for Rails which also are very popular in all other frameworks for other languages nowadays.""" 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.
- hello_moto 15y ago
  I think this is true but in my experience, they are what most people call "Application Developers". 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.
peteforde 15y ago
As an early Rails adopter who rarely gets to code directly on projects anymore (I'm a victim of my own success) I find it really curious when developers feel the need to post expository essays about framework switches. Things move fast and it would be bad for tech evolution to stop, so there's nothing to be loyal to unless you've placed awkward bets on the future of any given tool. 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! http://www.infoq.com/presentations/savas-polyglots http://www.infoq.com/presentations/savas-polyglots
- Addict 15y ago
  This should be top comment! I'm still waiting for my crack through... https://github.com/crack https://github.com/crack :D
xd 15y ago
"I was coming from PHP. PHP was shit then and is still shit now." 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.
- emil0r 15y ago
  The worst language I've ever written commercial web sites in is called OOiS-Script. You can't release memory, there is no such thing as an array, functions doesn't exist, there is no scope, when you handle XML you have to strip all namespaces because it uses ':' as the indicator for trasversal, there is no XPath so you have to loop through the levels and with a mere 3000 files processed one after another you can run out of memory on a machine with 4 gig of ram because the memory is not released until the request is done, etc. 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?
  - xd 15y ago
    "but has some pretty fundamental flaws that still marks it as really bad." 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.
    - xiaoma 15y ago
      >What flaws are these? Have you ever seen this piece? http://tnx.nl/php.html 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.
j_col 15y ago
I stopped reading at: > PHP was shit then and is still shit now. Way to go shitting all over so many peoples work.
verroq 15y ago
So what web framework are we supposed to use now?
- fuzzix 15y ago
  "So what web framework are we supposed to use now?" 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. [1] http://perldancer.org/ http://perldancer.org/ [2] ;) [3] http://www.sinatrarb.com/ http://www.sinatrarb.com/
ksetyadi 15y ago
"Think back to when Rails first came out. There was no iPhone. There was no Android. People still owned Nokias and actually bought stock in the damn company. Windows XP was still massively popular and we were fighting to get a decent version of IE (but that will never end). There was no such thing as a mobile web. No one was thinking about tablets. How old is the iPad? Not very old". 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.
hmans 15y ago
tl;dr - web development is changing, the frontend side of things is gaining significance, while the backend is moving to, well, the background. No reason to be surprised there, right?
div 15y ago
It seems like the title is a bit poorly chosen. 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.
cvshepherd 15y ago
"From my experience, generating a good UI (V) takes orders of magnitude more than implementing M and C." 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.)
thomasfl 15y ago
TL;DR When web applications is written mainly in javascript and communicates with the server over json, what language is beeing used on the server becomes less important. As long as it's not php. ;-)
hello_moto 15y ago
I did a single-page app before with GWT. I guess the GWT crowds beat y'all by miles since 2007. 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.

122 points by michaelty 15y ago

I don't understand why this article is remarkable. It shouldn't be a grand revelation that there is more to web development than what runs on the server.

dmix 15y ago
Or a developer getting disinterested in the framework he has been using for a while, for that matter. It's pretty common.

bphogan 15y ago

This is less about moving on from Rails and more about moving on from building static pages from a database. Lots of web folks have been predicting this. 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 and do something pretty awesome. And then it becomes a question as to what Rails offers. 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.

jshen 15y ago
I just got finished porting an admin panel from rails views to backbone.js and doing anything in backbone.js is a lot more work. Not only that, you still end up using rails views because you probably want to send pre rendered html to the client to minimize their wait time.
- bphogan 15y ago
  Just curious, but did you use a JS templating language? Cos we've been sending json back and pushing it to mustache templates which seem to render pretty quick.
  - jshen 15y ago
    I used underscore templates. Rendering large complex pages is slow. Doing it client side on an iPad is not good.
jiggy2011 15y ago
I'm not sure that is true for even the majority of cases. Remember that most of the web is not applications but simply pages of content server from a database.
- bphogan 15y ago
  But that stuff doesn't need Rails. At all. I'm talking about applications where people do something. The CMS problem is largely solved. Generate static pages from database content. 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.
  - jiggy2011 15y ago
    I wouldn't say the CMS problem is 'solved' exactly. Sure, you can install drupal or something but in the majority of cases I still end up building something with a web framework to server out mostly static content (i.e stuff that changes, but not on a second by second basis). Off the shelf CMS is often either underkill or overkill. There are plenty of ways to make things more efficient without abandoning HTML altogether.
    - bphogan 15y ago
      I think you misunderstand. Or perhaps my comment wasn't well stated... Serving staic pages is the solved problem. So is CRUD-based Rails apps. We know how to do that. In that sense, it's solved. We can use Wordpress with Rails, or Radiant, or we can roll our own in half a day. 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.
bad_user 15y ago
I've been saying for about two years now that the days of serving entire HTML pages from the serverside are numbered. You'll keep saying that for another two or three years at least. With things like Backbone, I can bring up a Rails app without views Backbone-style development sucked when people did it with Microsoft's MFC, it sucked when people did it with Java's Swing and it sucks right now. At least for native graphical interfaces, you have IDEs to help you out with bindings and all that crap. 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 It's just a tool and not all of us need to build GMail. People treat Rails like it's their girlfriend or something.
- bphogan 15y ago
  There's so much here I don't even know where to start. At least for native graphical interfaces, you have IDEs to help you out with bindings and all that crap. Yes, and we had slice and dice dreamweaver. But tons of Rails developers hand-coded their views. You're saying that because it's more work, people won't do it? You're probably right. Thankfully for the super lazy, there are Rails plugins for Backbone that generate a scaffold. And there are other JS frameworks out there besides Backbone. And as more folks work on these problems, maybe we'll get an even better solution. Instead of shaking my head going "it's hard" I'd rather dig in and see what I can do. youu don't have to build an entire Backbone layer, just for updating a small rectangle on your page. You said not everyone is building "GMail". Not everyone is buildign CRUD apps anymore either. And for those of us with users that are seeing sites like Facebook and Foursquare and are demanding interactions where the page doesn't refresh, partials become an absolute nightmare. I have many that I work on. It's a mess. 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. As an ccessibility proponent, I completely agree that Rails gives us the ability to do progressive enhancement. But it becomes a business question - what percentage uses the low-fi version of the site? Does every project require it? I'll be glad it's there, and doing a non-JS site is in my blood, but reality is that I don't think that's going to be the case in the future. 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.
dasil003 15y ago
> I've been saying for about two years now that the days of serving entire HTML pages from the serverside are numbered. 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).
- bphogan 15y ago
  Sorry, what I meant about serving HTML from the server was the construction of HTML documents using server-side code. There will always be static pages served with apache or whatnot :)

fosk 15y ago

I think the whole point here is: build APIs first, wrap all the client code around them. If I have an API written in Ruby/PHP/node.js/Java/whatever, and a standard format (or protocol) to exchange data, I can then build the clients in Ruby/PHP/node.js/Java/whatever, clearly separating the backend and the frontend which can now be built in completely different ways using different technologies. 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.

choxi 15y ago

great summary of architecture trends. i think there's a room out there for someone to build a framework with the server-side simpleness of Rails and the client-side elegance of Backbone/SproutCore

rickmb 15y ago

The author seems to consistently confuse architecture, languages and frameworks. None of his arguments have anything to do with Rails, Ruby, PHP or whatever else he mentions, except partly Javascript. 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.

kayoone 15y ago
thought the same, like he says PHP was shit and still is (which is partly true) but then delivers CRUD Tasks, ORMs etc as the reason for Rails which also are very popular in all other frameworks for other languages nowadays.
- dextorious 15y ago
  """but then delivers CRUD Tasks, ORMs etc as the reason for Rails which also are very popular in all other frameworks for other languages nowadays.""" 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.
hello_moto 15y ago
I think this is true but in my experience, they are what most people call "Application Developers". 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.

peteforde 15y ago

As an early Rails adopter who rarely gets to code directly on projects anymore (I'm a victim of my own success) I find it really curious when developers feel the need to post expository essays about framework switches. Things move fast and it would be bad for tech evolution to stop, so there's nothing to be loyal to unless you've placed awkward bets on the future of any given tool. 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! http://www.infoq.com/presentations/savas-polyglots http://www.infoq.com/presentations/savas-polyglots

Addict 15y ago
This should be top comment! I'm still waiting for my crack through... https://github.com/crack https://github.com/crack :D

xd 15y ago

"I was coming from PHP. PHP was shit then and is still shit now." 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.

emil0r 15y ago
The worst language I've ever written commercial web sites in is called OOiS-Script. You can't release memory, there is no such thing as an array, functions doesn't exist, there is no scope, when you handle XML you have to strip all namespaces because it uses ':' as the indicator for trasversal, there is no XPath so you have to loop through the levels and with a mere 3000 files processed one after another you can run out of memory on a machine with 4 gig of ram because the memory is not released until the request is done, etc. 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?
- xd 15y ago
  "but has some pretty fundamental flaws that still marks it as really bad." 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.
  - xiaoma 15y ago
    >What flaws are these? Have you ever seen this piece? http://tnx.nl/php.html 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.

j_col 15y ago

I stopped reading at: > PHP was shit then and is still shit now. Way to go shitting all over so many peoples work.

verroq 15y ago

So what web framework are we supposed to use now?

fuzzix 15y ago
"So what web framework are we supposed to use now?" 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. [1] http://perldancer.org/ http://perldancer.org/ [2] ;) [3] http://www.sinatrarb.com/ http://www.sinatrarb.com/

ksetyadi 15y ago

"Think back to when Rails first came out. There was no iPhone. There was no Android. People still owned Nokias and actually bought stock in the damn company. Windows XP was still massively popular and we were fighting to get a decent version of IE (but that will never end). There was no such thing as a mobile web. No one was thinking about tablets. How old is the iPad? Not very old". 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.

hmans 15y ago

tl;dr - web development is changing, the frontend side of things is gaining significance, while the backend is moving to, well, the background. No reason to be surprised there, right?

div 15y ago

It seems like the title is a bit poorly chosen. 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.

cvshepherd 15y ago

"From my experience, generating a good UI (V) takes orders of magnitude more than implementing M and C." 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.)

thomasfl 15y ago

TL;DR When web applications is written mainly in javascript and communicates with the server over json, what language is beeing used on the server becomes less important. As long as it's not php. ;-)

hello_moto 15y ago

I did a single-page app before with GWT. I guess the GWT crowds beat y'all by miles since 2007. 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.