by thisisblurry on 10/7/13, 3:45 PM with 155 comments
by mjackson on 10/7/13, 6:38 PM
After developing almost exclusively in JavaScript for the better part of the past year (and doing a lot more in the previous 6), I'm convinced that this mentality is going to start fading as more and more developers become more capable and productive with JavaScript.
There's nothing inherently wrong with the language that prevents you from writing sufficiently complex and reliable systems to power something like a shopping cart, or anything else for that matter. The main thing that is missing at this point is experience and maturity in the JavaScript community at large, which is quickly changing as more and more developers start embracing the language.
by karanbhangui on 10/7/13, 5:31 PM
Traditionally you've had to maintain two codebases for things related to rendering (think generating URL slugs, or formatting dates). This code duplication is obviously solved by running node layer in the middle. But the benefits go well beyond unifying rendering code and separating "backend" developers from "frontend" developers.
My excitement is the ease of building highly interactive apps while staying true to how web pages were meant to be architected. Since your client and server runtime are aware of each other, the framework can handle things like partial rendering, multi-client sync via OT, request caching, incrementally pushing required css/js/html payloads to the clients as necessary (instead of doing one massive push at the beginning). Right now the client and the server talk to each other through a constricted API layer you have to create endpoints for manually.
It's exciting to think how much of this can be automatically handled by the framework. I believe this generation of web architecture will finally bridge the gap between "websites" (often progressively enhanced HTML payload) and "webapps" (massive javascript payload, almost no HTML).
by ChikkaChiChi on 10/7/13, 5:21 PM
Engineers that make their lives easier at the expense of the customer will find themselves in a very empty and very optimized echo chamber. Users will be found elsewhere dealing with products that are faster (for them) and teams clamoring for how they can continue to improve the experience with each iteration.
by jacques_chester on 10/7/13, 4:41 PM
To me the distinction was about the location of execution. "Front-end" meant "in a browser" and back-end meant "anywhere else with some surface addressable via HTTP".
Now it seems that "front-end" means "View and Controller" and "back-end" means "Model", except ... not quite. Sometimes.
On the other hand, perhaps I protest too much. It's not as though there's a High Court of Internet Nomenclature for this.
by EGreg on 10/7/13, 4:27 PM
Consider this: you have a site that will have to scale to millions of people. If you have a lot of reads, you can simply replicate your database, but if you have a lot of writes too, then you'll need to shard (partition horizontally) your database.
An aside -- if you find yourself using an ORM and sharding a lot, then most likely you should have used a NoSQL database such as Riak, instead of a relational DB. But let's say you've already gone this route, and used MySQL, which a lot of sites including facebook have done.
In this case, anytime you need your query to hit N shards, PHP will take (s1 + s2 + ... + s_n) time to do it. Node.js will take MAX(s1, s2, ... s_n) which is much faster. There is a big difference for latency. (It's true that the mysqli driver in PHP does support concurrent queries, but the above comparison isn't just for DB but for EVERYTHING. In JS and Go you have the option to do concurrent I/O, in PHP you don't.)
Another difference is in the memory usage. PHP has to create a copy of your environment for every preforked process. It depends on Linux to do copy-on-write, for instance. APC helps a little with shared memory segments, but not much. On a 2GB RAM machine, how many clients can you support with PHP vs Node? Node has just one copy of the code running, and each request costs very little in comparison. Of course, since everything is in the same memory space, you can easily bring down the whole process, so Node.js processes need to be built to survive crashes, unlike PHP scripts which are isolated.
And let's not forget that Node.js stuff can push to the client, whereas for PHP to do that you need wasteful, long-running sleeping processes sitting in memory, and having some nginx event module to simulate evented programming.
In short, Node.js and stuff like that gives you much more flexibility, many more things you can do (such as pushing data in near real time to many different endpoints including the browser), but at the same time you need to code everything in a way that crashes don't matter much.
by 10098 on 10/7/13, 8:28 PM
Interesting how the same people who are "not fans" of PHP somehow like Javascript. As if it's better.
by webjprgm on 10/7/13, 5:19 PM
It seems to me that a designer who picked up some JavaScript would still not be a programmer. Lots of apps require advanced JavaScript to run a UI client-side. I would not expect anyone who was a full programmer to be just a front-end engineer and be completely unwilling to learn PHP or Ruby to also work on the back-end. If I met a person like that I would think the person a horrible programmer and not hire him/her. (Unable or unwilling to learn, lack of passion for software engineering excellence.) A designer with a few extra skills is one thing, but a restricted programmer is something else entirely.
But what do I know? Hence I ask whether this is common.
by carsongross on 10/7/13, 4:55 PM
This is what drives me bonkers about the node and JS community: there is so much goddamned noise and "nobody cares!" arrogance in the signal it's difficult to know who to take seriously.
by hrjet on 10/7/13, 7:09 PM
However, using NodeJS in lieu of Scala for the middle tier, suddenly makes a lot of sense. Thanks to the article for showing this path! To be sure, NodeJS can be replaced with something equivalent, such as N2O or JScala (as others have mentioned). But the concept is more clear when expressed in terms of NodeJS.
by aufreak3 on 10/8/13, 3:14 AM
To my main point, I'm unclear how such a split would actually work in practice. For example, if I have a file upload to do from the client, should that get streamed to the "ui front end at the back end" (whew!) or directly to the "real back end"? Are there any fundamental architectural problems with client side code pulling together an application by accessing a number of independent REST services without going through such a "front end at the back end"?
Thoughts/suggestions?
by badman_ting on 10/7/13, 5:11 PM
Also, while it may be true that the backend devs don't care about the flow of pages that the user browses, the user does care. That means that the services that put together the pages need to work for the user's use case. That means that the system needs to be designed for the pages the user looks at. You can't escape this, this is bigger than your architecture. It's almost like a law of physics.
by JacksonGariety on 10/7/13, 4:06 PM
It is a UI-layer, but is it not still back-end?
by mtam on 10/7/13, 7:52 PM
by exo_duz on 10/8/13, 3:30 AM
I currently program in PHP for all my websites.
Any pointers and comments greatly appreciated. Thanks in advance.
by shapeshed on 10/7/13, 8:19 PM
by agibsonccc on 10/7/13, 5:37 PM
I think the real potential comes in when you blend it with a heavy lifting API written in go or on the JVM. Easy web layer that's agnostic to whatever heavy processing language should you decide to do.
Obviously there's a bit of complexity that comes with this, but if you need to scale up it's right there. Even then, node is pretty powerful on its own, where you might not need a crazy backend.
by dmak on 10/7/13, 5:15 PM
by pweissbrod on 10/7/13, 9:08 PM
by heynairb on 10/7/13, 6:57 PM
by sassyalex on 10/7/13, 11:01 PM
JS weakly typed ? Seriously learn on how to adapt your coding style. I've built more than 20 API/Apps and Node is the best thing I ever had to build networked apps. I have a J2EE/Spring, Python and RoR background, NodeJS/NPM took the best of every stuff created before.
In my case, I need to be fast and JS + NodeJS + his awesome community permits me to build stable, innovative solutions and high performance networked app in a very short amount of time.
We are in a world of inter-connected apps. NodeJS is for that. Adapt yourself.
I need hacker modules to accomplish and solves problems of my current worlds, hacker offers me that.
NodeJS is great and lot of thing I read before was old school shit.
And BTW, yes a lot of logic must be delegated to the client side. This is a trend and it will not be stopped. Rendering page server side, qu'est ce que je peux pas entendre comme connerie parfois.
by ronreiter on 10/8/13, 12:11 AM
by CmonDev on 10/8/13, 9:51 AM
by indubitably on 10/7/13, 10:34 PM
by pjmlp on 10/7/13, 6:01 PM
by thomasreggi on 10/7/13, 7:32 PM