I think it's pretty hard to generalize the future of the web... it's just way to broad, and there are simply way too many different things on the web that one stack is going to a solution for everything.
If you're a chef, the saying goes - "There's a knife for every job and a job for every knife" ... if you're a golfer the saying goes - "There's a club for every shot and a shot for every club" ... if you're building stuff for the web it can be said - "there's a stack for every app and an app for every stack"
It can be the new LAMP but not yet. In my opinion, LAMP became common due to its deployment. There's virtually nothing to do asides placing the PHP files in the directory that is exposed by Apache. Applications such as WordPress depended on the LAMP stack's ease of deployment and applications like WordPress makes people want to learn PHP.
Hmm, I'm not so sure. "NUM" is not a one size fits all solution not least because many applications require atomicity, consistency, isolation, and durability of a database management system.
Node's API has changed frequently as it has developed, breaking older code, so don't be surprised when a genius piece of code found on Github that exactly solves your problem doesn't work with your new build of Node.
Most web app developers typically don't explicitly deal with any concurrency model. There is a significant difference in aptitude between the typical HN reading coder and the average peon level developers, i.e. the majority of developers worldwide. Asynchronous code is non-trivial, especially with TDD and beyond the level of expertise of the peon level developer.
Huge PHP codebases also exist, and many companies will not have the resources or the inclination to make such a change.
This article is also based on the assumption that most web development in the future will be real time web apps. That's quite a big assumption, ergo although "NUM" is an interesting prospect, I doubt it will become the de facto platform for web app development.
Apache or PHP certainly can't last forever. While I don't know what will take their place, or when, or who will benefit, I do think we will see some trends going forward:
More and more server code for web applications will be written in Javascript, as WebGL enables web-based gaming platforms, as offline applications share code between client and server, as Javascript becomes more popular as a language, and developers realize the benefits of concentrating language knowledge, and the performance gains made by Javascript engines.
More and more server code will be evented, in order to use WebSockets and maintain connections. Programmers will come to terms with the fact that the theoretical efficiencies of threads over events are not likely to be realized anytime soon, non-blocking IO will eventually be accepted on pragmatic terms. Programmers will learn to see problems as streams, and as streaming interfaces converge, it will become easier to pump streams from one place to another.
As it becomes easier to write efficient networked applications using programming interfaces which mirror the underlying activity, the duo of nginx/application server on the same machine will converge towards just application server.
As systems become more distributed, as the efficiencies of disk storage change, and as memory becomes cheaper, programmers will move from thinking about disk storage, to thinking about global state storage. In-memory caching, disk persistence, and sharding will be managed by the same service. Programmers will move from thinking in terms of SQL, or noSQL, to thinking in terms of data structures: strings, lists, sets, sorted sets, trees, and so the database will become a persisted data structure service.
While I think that Node, and Redis have head starts in these departments, the race is not always to the swift, nor the battle to the strong, but time and chance happen to them all.
Interesting ideas. You just reminded me of a post Bruce Eckel wrote on what programming might be like in the mid future; he touches on some similar ideas. I recommend you give that a read to see what you think as I found it quite thought-provoking.
Thanks for the link. This was interesting: "Eventually the idea that we have to 'store something to disk' will go away; the difference between memory and disk will be seen as an arbitrary artifact of the past".
I am in the camp that thinks JavaScript and related technologies are going to, one way or another, take over a large aspect of web development. But things always work out differently than people think it will. I don't think Node.js and MongoDB will be the sole winners. There is room for many conflicting projects and technologies to succeed in the future.
Premature and a little arbitrary. While Node.js certainly is useful, and Unix is a staple, why MongoDB in particular? Why not Cassandra, HBase, or another NoSQL effort? Why is it the "new LAMP", anyway -- why can't it just be a new(er) set of tools that people use?
13 comments
[ 4.1 ms ] story [ 46.8 ms ] threadhttp://blog.mathgladiator.com/2010/09/announcing-nodeocaml.h...
http://news.ycombinator.com/item?id=1681827 (posted 1 hour after your comment)
I do believe that marketing websites will still use LAMP because its the right tool for the job.
If you're a chef, the saying goes - "There's a knife for every job and a job for every knife" ... if you're a golfer the saying goes - "There's a club for every shot and a shot for every club" ... if you're building stuff for the web it can be said - "there's a stack for every app and an app for every stack"
Node's API has changed frequently as it has developed, breaking older code, so don't be surprised when a genius piece of code found on Github that exactly solves your problem doesn't work with your new build of Node.
Most web app developers typically don't explicitly deal with any concurrency model. There is a significant difference in aptitude between the typical HN reading coder and the average peon level developers, i.e. the majority of developers worldwide. Asynchronous code is non-trivial, especially with TDD and beyond the level of expertise of the peon level developer.
Huge PHP codebases also exist, and many companies will not have the resources or the inclination to make such a change.
This article is also based on the assumption that most web development in the future will be real time web apps. That's quite a big assumption, ergo although "NUM" is an interesting prospect, I doubt it will become the de facto platform for web app development.
More and more server code for web applications will be written in Javascript, as WebGL enables web-based gaming platforms, as offline applications share code between client and server, as Javascript becomes more popular as a language, and developers realize the benefits of concentrating language knowledge, and the performance gains made by Javascript engines.
More and more server code will be evented, in order to use WebSockets and maintain connections. Programmers will come to terms with the fact that the theoretical efficiencies of threads over events are not likely to be realized anytime soon, non-blocking IO will eventually be accepted on pragmatic terms. Programmers will learn to see problems as streams, and as streaming interfaces converge, it will become easier to pump streams from one place to another.
As it becomes easier to write efficient networked applications using programming interfaces which mirror the underlying activity, the duo of nginx/application server on the same machine will converge towards just application server.
As systems become more distributed, as the efficiencies of disk storage change, and as memory becomes cheaper, programmers will move from thinking about disk storage, to thinking about global state storage. In-memory caching, disk persistence, and sharding will be managed by the same service. Programmers will move from thinking in terms of SQL, or noSQL, to thinking in terms of data structures: strings, lists, sets, sorted sets, trees, and so the database will become a persisted data structure service.
While I think that Node, and Redis have head starts in these departments, the race is not always to the swift, nor the battle to the strong, but time and chance happen to them all.
http://www.artima.com/weblogs/viewpost.jsp?thread=284730)