Live data from Hacker News

Moving on from Rails

broadcastingadam.com

31–40 of 54 posts

Re: Moving on from Rails

#31
post #30

Earlier quoted context omitted.

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 gra…

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 gene…

    Instead of shaking my head going "it's hard" 
    I'd rather dig in and see what I can do.
If you're a doer, then good for you. However this development model you're talking about is inherently difficult and better tooling support doesn't help it. You are free to try and fix it however.

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
I'm having problems parsing your opinion, because you are mixing things. It is my feeling that you're trying to justify the usage of Node.js, coming up with reasons other than the language itself, especially since Node.js is quite immature in many regards.

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?
Progressive enhancements are much more useful than catering to users that haven't upgraded their browsers. It also helps with crawlers for instance, because the truth is only Google can crawl your website if it is JS-enabled and even they are having screwups. And maybe you think that Google should be the only game in town, however such a decision would be like optimizing your website for IExplorer only back in the day.

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.

Re: Moving on from Rails

#32
post #28

Earlier quoted context omitted.

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.

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.

In my own experience, using an existing CMS has rarely fulfilled project requirements very well. It's never about just "static pages". You want things like menus and sidebars with specific structure, multi-language support, commenting, search, etc. Then you fight with the existing features and plugins of the CMS and try to bend them to your will.

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.

Re: Moving on from Rails

#33
post #30

Earlier quoted context omitted.

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 gene…

Instead of shaking my head going "it's hard" I'd rather dig in and see what I can do. If you're a doer, then good for you. However this development model you're talking about is inherently difficult and better tooling support doesn't help it. You are free to try and fix it however. Backbone is just a particular example, mentioning other JS frameworks is irrelevant as long as it gets you further away from the simple r…

    It is my feeling that you're trying to justify the 
    usage of Node.js
I said nothing about Node.js. I said I want a framework on the client-side for the same reasons I want one on the server-side. A framework. Like Rails. For the client-side. So I can have organized code that people other than me understand.

    wikipedia
Wikipedia is a content site. I'm not talking about content sites. I'm talking about web apps. There's a huge difference. When I need a blog or a CMS, I guarantee you I'm not reinventing that in Rails. I'm using one that is proven and already solves that problem. And that's a whole other area of discussion. There will always be static pages. Those are the majority. But nobody should be serving those directly from a database. Those should be coming from disk or a cache or something.

I'm talking about interactive user experiences. In web apps.

Re: Moving on from Rails

#34
post #28

Earlier quoted context omitted.

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.

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 altoget…

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.

Re: Moving on from Rails

#35
post #5
post #4

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…

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.

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.

Re: Moving on from Rails

#36
post #34

Earlier quoted context omitted.

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 altoget…

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 talki…

I think we are in agreement more or less. Building CRUD apps isn't exciting or particularly difficult for the most part, although I have built some pretty huge complex CMS systems for specialist industries that were highly bespoke and integrated with legacy back-end.

You can build applications now using things like 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.

Re: Moving on from Rails

#37
post #21
post #12

"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 r…

Also, "Bezos pulled a Hitler". I'm all for writing that, say, politicians who you don't happen to like are just like the Nazis , but this is taking trivializing of that regime just a bit too far.

This happens as time passes and events slip in societies memories. There are increasingly fewer and fewer people who were around to witness the atrocities of the Nazi rule, and even the people who knew of it second-hand are slowly disappearing. There's two groups of people who use the word Nazi and Hitler to insult someone; the first group is full of idiots who should know better and the second group is full of people who were completely unaffected by the history in any way, meaningful or not.

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.

Re: Moving on from Rails

#38
post #34

Earlier quoted context omitted.

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 talki…

I think we are in agreement more or less. Building CRUD apps isn't exciting or particularly difficult for the most part, although I have built some pretty huge complex CMS systems for specialist industries that were highly bespoke and integrated with legacy back-end. You can build applications now using things like and Javascript and use almost no HTML to deliver your app over HTTP (although once we get to that point…

Yeah. That's kinda what this guy was saying in his artle that we're commenting on. He wasn't really "moving on from Rails"... he was leaving the view layer behind. And then evaluating what else he really doens't need.

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.

Re: Moving on from Rails

#39
post #25
post #15

Earlier quoted context omitted.

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…

"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…

Integers becoming 32-bit or 64-bit depending on CPU architecture, bad character-set support, comparison and identity is wacky. If anything of that has changed since last time I looked, all the better :).

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.

Re: Moving on from Rails

#40
post #12

"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 r…

In defence of PHP: 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 s…

I'm not sure you should put "write good code using PHP" in the same paragraph with "some of the largest site in the world". Because they're the exact opposite.

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".

Post reply on HN