131–140 of 166 posts
This reminds me of Derek Sivers switching from Rails back to PHP 5 years ago :-) http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...
I'm a firm believer it has a very bright future, but this is not a zero-sum game.
I do this all the time. Some ideas get mocked up in python, others PHP, some in C#, etc. Then if it sticks, I look at the needs it has and pick the best tool for the job. Sometimes it Rails, others its .NET.
Though it is quite interesting to read about it from someone else's point of view.
"NodeJS’ async everything wont have any affect on a CRUD app. Popular frameworks, provide very good caching and everything that is needed for your app to work fine even synchronously."
There is a lot to this statement that implies how an application is architected. Node.js is async at heart, and one can only build a successful application if you follow the programmatic model as it's designed. It doesn't matter how simple or complex an application may be, if a framework is being bent to work in ways in which it wasn't designed, the application may not work so well.
Reading between the lines, what I'm getting is a picture of a team that has encountered productivity issues with the current stack and is migrating to a more familiar stack to increase productivity. Nothing wrong with that tradeoff, but I always look to what future tradeoffs are being made: "cache everything and gets the work done ASAP" is great until you need finely-grained control of your queries.
I'm sure they thought well about their decision, but if asked to make a wager -- I'd guess that certain problems are being traded from one framework to another.
I really do think that, as time wears on, we will see more of these incidents of people switching from Node to another, more familiar development environment. It seems to me that a lot of people started using Node simply because of the amount of hype that surrounded it, and many of these decisions were not as well researched as they should've been. Reading through this gentleman's blog post, it seems that, originally…
I suspect -- and I may be wrong -- that the advantages of using Node differ between large teams and small teams. For my first startup, I had the budget to hire a single full-time developer. The was a substantial amount of work to do on both the frontend and backend -- with the backend development needing to get underway first, but the frontend work being much more experimental and needing to go through many more iter…
What it this "low task-switching barrier" ? I mean, even though, the language is the same, back end coding and front end coding are really different. For example, your front end development may have lagged because of lack of front end development knowledge, not because of this mythical task switching barrier that everyone is talking about !
Anyone else find it ironic that this post is about moving from Node to Ruby in order to produce the admin interface to a Java hosting service? (This was a blog post written by "Jelastic" devs, who make a Java PaaS product). We seem to be seeing more of this "don't eat your own dogfood" approach to software development lately. The other example that comes to mind is the Play Framework, written in Python and also targe…
I see what you mean by ironic, but it might be a bit less ironic when you consider the history of the name "JavaScript." Its original market positioning was as a lightweight complement to the heavier Java. Now we have other languages serving in that capacity as well: Python, Ruby, Scala, etc. I don't know if there will someday be a language that is as easy to work in as a Python or Ruby for simpler programs but which…
Have you looked in to Cython? It seems like it tries to do what you wrote.
From http://cython.org/
"The Cython language is a superset of the Python language that additionally supports calling C functions and declaring C types on variables and class attributes. This allows the compiler to generate very efficient C code from Cython code. The C code is generated once and then compiles with all major C/C++ compilers in CPython 2.4 and later, including Python 3.x. PyPy support is work in progress and is mostly usable in recent developer versions."
The latest Gevent dev uses libev (same as node.js) I'm curious to know how Cython and the new Gevent will perform vs the alternatives.
I read this post as "your mileage may vary", gravitating toward "it doesn't work like we expected". One particular line caught my eye: "NodeJS’ async everything wont have any affect on a CRUD app. Popular frameworks, provide very good caching and everything that is needed for your app to work fine even synchronously." There is a lot to this statement that implies how an application is architected. Node.js is async at…
There are undoubtedly tradeoffs no matter what you use, but this seems like an eminently practical decision.
I really do think that, as time wears on, we will see more of these incidents of people switching from Node to another, more familiar development environment. It seems to me that a lot of people started using Node simply because of the amount of hype that surrounded it, and many of these decisions were not as well researched as they should've been. Reading through this gentleman's blog post, it seems that, originally…
From my personal experience, Node is a really fun platform to quickly whip up a working web site/app/service over the weekend. But I keep getting this nagging feeling that it's not sustainable for a long term project with a large codebase. Other than socket.io, I really don't see Node as a general purpose web stack.
Earlier quoted context omitted.
Mongodb is a json document store. I use it myself. It works very well with "node" because node of course uses javascript as its language.
It's not JSON, it's BSON. BSON supports more data types, which are needed for a proper database (such as object IDs, longs, doubles, binary data, references, etc.) You still need a driver and a bson serializer if you use node.js.
Does anyone know 1 major consumer-facing site that was able to scale with Rails? I know Twitter kind of had to move away from Rails due to scalability issues. GameBattles.com also had to back away from Rails after their uptime dropped to 80%. I am not trying to tarnish Rails, I am just curious to learn about some success stories involving Rails at very large scale.
Frameworks don't scale. Architecture does. From my experience, you can scale a rails app the same way you can scale a django app the same way you can scale a java webapp, and so on. The general problem with frameworks is they try to make you not think about datastore access. Datastore access tends to be the hardest part to scale. Also, in addition to what others have mentioned, iLike uses (used?) rails - it was a lar…
Each framework has its own (software) architecture. When it's bad, it can ruin the scalability of your apps.
So when someone says "Framework A scales, B does not", he means "Framework A is well architected and won't cause any bottlenecks by itself", and the opposite for B.