That's fair enough, but seems to ignore the fact that there is still a tremendous need for efficiently serving static files, even in a javascript era. Images, CSS, Javascript, HTML all still need an efficient method of delivery, and I don't believe that Node.js can fill that role as well as is needed.
I don't see the LAMP stack going away. Parts of it may be substituted as new technologies become popular, but the concept is still sound.
And machine instructions aren't going away, because that's what those C server applications compile down to. But the "web stack," like the other layers before it, is becoming a black box which many developers won't need to know about to do their work.
The principal role of the server is to ship an application to the client (Javascript), along with data (JSON), and let the client weave those into a DOM.
These problems are all solvable by other languages/frameworks. I use Python, and we have gevent, which does the same thing as Node, but in a more concise language with a richer standard library.
I agree, in addition javascript is not easy to develop in. Yes, it's fun and fast for little projects. But do I want to stake my future upon a huge javascript codebase? I'd rather not. Navigating through javascript code is beyond cryptic at times.
Javascript is incredibly easy to develop in. Most folks who say that its hard or messy don't understand it and are approaching it the wrong way.
I'm learning Objective-C right now, and it seems to be hard to develop in, at first. Why do I have to put @ in front of strings, or NSLog(@"%@", myVar); to log a string? Why are there so many data types? Wtf is up with all the brackets?
As soon as I actually started at the very basics, this stuff started to make sense. Its a different language with its own ways of solving problems. Its me as the new guy on the team that has to learn the rules before I can start complaining that things don't make sense.
Objective-C is basically C, so you have to deal with a lot of stuff that is usually hidden in scripting languages. I think he was referring to the fact that javascript code tends to become tangled like spaghetti.
That's actually a really good point. In my career I never learned C, but rather started with basic C++ in college then moved into frontend development early on, so I was never fully exposed to low-level languages at a deep level until relatively recently.
I know what you mean about the spaghetti effect, but this is easily mitigated if you know how to structure your code.
"III. 2010-??: The Javascript Age" is true only if you build highly interactive web application. When you just need a web site with forms for CRUD content, many PHP CMS systems are just fine, often without coding except when you need a custom theme. The majority of the sites are such ones so LAMP is not near dead.
What I don't understand in the first place is why we want to create persistent sockets on top of a stateless, request-response protocol like HTTP. Sounds like a travesty to me.
We don't, necessarily. Sometimes a persistent socket is the right tool for the job. Sometimes it's not. The whole point of the article was that Node and its ilk serve both needs very well, whereas older mechanisms do not.
I think that's mixing up technology and content. Just because it has become easier and more efficient to send lots of JSON messages back and forth doesn't mean all documents suddenly become interactive applications.
15 comments
[ 2.9 ms ] story [ 38.9 ms ] threadI don't see the LAMP stack going away. Parts of it may be substituted as new technologies become popular, but the concept is still sound.
The principal role of the server is to ship an application to the client (Javascript), along with data (JSON), and let the client weave those into a DOM.
These problems are all solvable by other languages/frameworks. I use Python, and we have gevent, which does the same thing as Node, but in a more concise language with a richer standard library.
LAMP is not dead. It's evolving.
I'm learning Objective-C right now, and it seems to be hard to develop in, at first. Why do I have to put @ in front of strings, or NSLog(@"%@", myVar); to log a string? Why are there so many data types? Wtf is up with all the brackets?
As soon as I actually started at the very basics, this stuff started to make sense. Its a different language with its own ways of solving problems. Its me as the new guy on the team that has to learn the rules before I can start complaining that things don't make sense.
I know what you mean about the spaghetti effect, but this is easily mitigated if you know how to structure your code.
word?