No post body was provided.
Untitled topic
1–10 of 14 posts
Re: undefined
#2Can I use Caml instead of Node?
Re: undefined
#3Hahaha, if that would better suit your needs
Re: undefined
#4The author makes an interesting conclusion. The communication behavior of web apps lends itself to more event-driven models.
I do believe that marketing websites will still use LAMP because its the right tool for the job.
Re: undefined
#5I 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"
Re: undefined
#6It 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.
Re: undefined
#7Can we have less of this "X is fashionable! Y is so last year" posts... (Yes I did flag it, I'm just calling for others to see reason as well).
Re: undefined
#8Hmm, 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.
Re: undefined
#9Apache 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.
Re: undefined
#10I 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.