Node.js and the new web front-end
nczonline.net
nczonline.net
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.
Yes, a sufficiently smart developer can write good code in Javascript. But there are very few people who I'd trust to write financial code in Javascript, and I think all of them would use a better language rather than expending the effort working around its deficiencies.
The others I don't really mind: I like writing event-loop code over threads, and have never once run into Object.prototype problems in the wild.
First, running the same UI code on the front-end and back-end will enable the best performing apps across platforms. Imagine being able to run a rich client on a powerful PC that just talks to an API and does all the rendering as a single page app, while simultaneously being able to serve up pure HTML/CSS to mobile devices and search engines. Being able to run code on the server or client as needed solves too many problems to ignore.
But on the other hand, javascript flexibility and lack of type system will inevitably cause problems as the codebase grows unless you have a good lead developer to define standards and an iron-fisted approach to code reviews.
Personally I think coding standards are a stretch with a language as wild as javascript, and a higher level language to enforce certain things is the best way to reconcile these two problems. I can even imagine supplementing with something like (for instance) a Haskell library that lets you generate JS code for interfacing with the back-end in a provably correct fashion, and plugging that into the UI code.
- Refactoring e.g. easily globally change a class member's name
- Type safety e.g. it will bark if you pass a string where an int is expected
- General IDE handyness e.g. 'Go to definition'
A really good demo here: http://channel9.msdn.com/Events/Build/2013/3-314
- structural typing for interfaces (which means that classes implicitly implement an interface if the definitions match)
- gradual typing (mainly the ability to convert between 'any' and other types implicitly, which makes it much easier to interact with JS libraries/port JS code to Typescript.)
More generally speaking, Typescript aims to solve the problem of maintaining large codebases by giving you the additional security of static typing. The idea is that many simple errors can often be caught by a compiler, but would be much more time-consuming to find otherwise.
if (obj && obj.quack && typeof obj.quack == 'function') obj.quack(); //looks like a duck
The problem that TypeScript solves is that the web platform is in direct conflict with Microsoft's monopolies in PC gaming and business productivity software (Office). Confusing developers into thinking that JavaScript needs types leads them down the path of statically typed languages, i.e. C# and Microsoft's proprietary and closed .NET Framework and software ecosystem.
https://www.dartlang.org/articles/style-guide/#type-annotati...
Clojure? Scala?
Because instead of developing languages to run on top of them, people just designed languages to run on the same platform. The browser environment is a special case where the only common feature of the platform that is available to target is JS, there's no common VM underlying it, so replacements target JS.
Though its worth noting that while it may be true that no one developed a language to run on top of C++, C++ was originally implemented as a language that was preprocessed into C and then fed to a C compiler, much the way that many JS alternatives are compiled to JS and then fed to a JS interpreter.
-TypeScript definitions for many libraries, such as express are out of date and require modding to use.
-Visual Studio has no built in support for TypeScript with Node for debugging, but it has been mentioned as likely to be added by the TypeScript team eventually.
-There are third party plugins for Node in Visual Studio for debugging, but none support TypeScript yet.
I've found the best solution thus far is Intellij IDEA or WebStorm, as it has support for both Node and TypeScript.
i use typescript professionally, i use vs2013 for writing code, webstorm for debugging / testing
Almost nobody modifies Object.prototype, and we now have plenty of APIs to deal with that - defineProperty, seal, freeze, etc.
0.3 * 3 => 0.8999999999999999
And the example you have given is a problem with all floating point implementations, not just Javascript. You will get that exact same answer in C, Java, etc.
The only way to avoid this is to represent rational numbers directly, without simplification. For example:
(3/10) * 3 => (9/10)In the example given, using node-bignum and assuming our precision is a thousand of a cent:
big(30000).mul(3) => 90000
Here's a relevant example,
2^26 * 2^26 == 2^52
that said, you could still write your own bigint class if you need precision beyond that.
I coded exclusively in javascript from 2006-2011. Most of that time was spent at Meebo, where we authored one of the most sophisticated JS application in existence at the time. It was great stuff!
I've worked extensively with node.js 2011-mid2013, launching multiple backends written partially and exclusively in node. Lots of fun!
On https://github.com/marcuswestin I maintain multiple widely used open source projects, much of it JS.
In the past 4 weeks I've rewritten my current product's entire nodejs backend to a statically typed language. Why? Because static type analysis allows you to develop more accurate code faster and with lower maintenance cost.
I've been a strong advocate for "javascript everywhere" for a long time. However, these days I believe that there is exactly one fantastic use case for javascript: delivering rich application experiences in web browsers.
So you may be right: perhaps this line of arguing is fading. But in that case I'm a real outlier.
(and with all that said, the most important thing to consider is this: what tool will best allow you and your team to build and maintain your intended product?)
This statement may be true for you, but it's not for everyone.
It's a dangerous argument because it assumes that static types are going to somehow magically turn bad code into good code, or (by extension) bad coders into good ones.
Static typing is a not a solution to the problem of any deficiencies in the language, but rather the problem of people shooting themselves in the foot with it. It's admittedly a related problem, but a separate one.
> (and with all that said, the most important thing to consider is this: what tool will best allow you and your team to build and maintain your intended product?)
I'd defend the statement you quoted like this: all languages are type. Dynamic languages simply have exactly one expression type, "any". Specifying multiple types affords you strictly beneficial abilities. Static type checks is probably the most significant. Performance improvements and highly specific and accurate code editing assistance (e.g auto suggest) can also be significant.
But yes, you're absolutely right. Nothing but sincere effort, lots of practice, and critical thinking can make you a better programmer.
At the same time, a great carpenter becomes even so much better with a properly weighted hammer and an accurate lever.
:)
I've not used anything that allows for as easy modularity as node+npm lend themselves to... just because it's JS doesn't mean it's spaghetti that has blurry code sharing between the client and server.. it's not all meteor, even if that does have a lot to offer.
In other words, it's Turing complete. That's great but not exactly an argument for using JS server-side so much as a reason why it is possible. I love JS, but I also know what it was designed for.
Coming back and maintaining them a year later is a different story.
> I believed, and still do believe, that statically typed languages are exactly what you want in the guts of your business logic.
He wasn't making a case against javascript for his shopping cart but rather against dynamic languages.
Now, you could certainly disagree with that as well, but it opens the discussion to a more correct one vs why you believe javascript is a mature language. Something the author actually agrees with.
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).
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.
For example, over a small data-set, doing typeahead search on about 5000 elements was many times faster, even on some of the slowest hardware than doing it server side.
I've been thinking about that as well and was playing this N2O framework: http://synrc.com/framework/web/ they are sort of making this point as well, render on the server and send html to client but do it via a websocket. That is an interesting approach.
[0] http://meta.discourse.org/t/why-is-discourse-so-slow-on-andr...
http://meta.discourse.org/t/why-is-discourse-so-slow-on-andr...
So yeah -- you might have more JS, which will eat some CPU cycles, but you can save yourself from having to request a lot of duplicate data. So, smaller request sizes and if you do it right, fewer requests. The less you can bother the radio, the better.
Although this article is mostly about javascript on the server, and so isn't focussing on the fat js sites that you are talking about.
When you run a CPU-sucking stie on your device, you typically know exactly which site or app is the culprit - you can watch your battery drop and feel your CPU heat up.
When you get your bill at the end of the month, it's a lot less clear why, exactly, that happened. And - fairly or not - it's a lot less likely to be blamed on a lightweight site that grabs extra data.
Not that these two things should be mutually exclusive anyway: an app designed for mobile will do most of its processing on the server with short bursts on the client, and ALSO be optimized for data on the server side. (The server, after all, typically knows what kind of client it's serving.)
I'm also really interested in seeing how feasible it would be to push all Javascript to the server and basically letting the client act as a dummy terminal that sends and receives Javascript snippets through a WebSockets connection (which is more mobile-friendly than AJAX since some mobile users pay per TCP connection). I would expect that latency would result in an overall slower app, but maybe some client side-heavy apps could benefit from it.
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.
I've been primarily a 'browser developer', with most of my time spent in the Chrome dev tools, editing css, html and 'light' javascript. I call myself a front-ender for this reason.
However, over time I find that I prefer the 'real' programming stuff over battling browser quirks and pumping out html/css structures that I learned over time are optimal. I gravitate more and more to what amount to full web apps where I do stuff that requires, to a degree, 'real' programming beyond just a javascript/jQuery widget.
That's where the real division is, I think. As I get into more and more complicated development, I become more aware of my limitations and my lack of formal training.
This reached a point where calling myself a 'front-ender' is starting to feel less and less applicable, because there's a huge divide between many front-enders I know who are not really programmers, and what I am in the process of becoming, and calling myself a front-ender feels like underselling myself.
However, if you talk to JavaScript developers many of them would consider all code that is executed in a browser "frontend" but would exclude any server-side templating, partials, etc.
Then, some of them would still consider ALL JavaScript code a part of Frontend, be it a browser code or Node code. This can bring up some fun conversations. One of my coworkers talk about server-side bits of project A a "Frontend" because they are written in Node, but considers same functionality in project B "Backend" because they are written in Python.
Moving to a service oriented architecture where the two groups communicate by REST seems like it would work just as well in most situations, and this was the point.
That's how I tend to think of the pattern, it's not really MVC anymore it's a new pattern that is evolving out of MVC.
The article seems to be more about UI vs. non-UI code. Rather than have part of the UI code in the business logic, it can be split out. This was already possible, but with Node.js you can have the server-side half of the UI code be in Javascript so all the UI code is Javascript and the business logic code can be in some other language.
We might need a change in terminology.
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.
If Node.js can do things like
* cache responses
* not send duplicate responses but instead maintain a waiting queue
* throttle requests based on # of preforked threads etc.
then it would be faster most of the time.
And equally importantly you can take a page from Yahoo's book and pre-render stuff on the presumably faster server, for mobile devices and robots.
Caching: you can have ONE node.js process listening to all requests, and it can keep the cached info in memory, to be looked up much more quickly. In PHP, you'd have to load the entire script environment, connect to an external source like Memcached or APC, etc.
Waitlist: Similar to caching, except Node.js can hold off on responding to the request until the response came back. It's MUCH harder to make something like PHP iterate through the waitlist because a bunch of scripts might get called at once, and the way it works, all of them will have to sleep. With Node.js, only one process has to sleep -- or handles something else while you're waiting.
etc.
For instance, if you need to run 3 SQL queries in PHP, then the total execution time will be t1 + t2 + t3. On the other hand, if you make those queries in NodeJS instead, it will be MAX(t1, t2, t3).
So, it depends on the complexity of your app and your ability to decouple and separate concerns in the NodeJS server.
It can work, though you lose a bit of transparency.
If node is being used simply as a proxy then—no question—throwing it in to the mix will simply introduce latency (shortest distance blah blah blah). However the suggesting made by both the article and EGreg seems to be, "use the right tool for the job." In the case of the article, Nicholas seems to be suggesting that aspects of your data model might be better suited in the hands of your front-end engineers as they're the ones presenting that data. EGreg is suggesting leveraging the asynchronous nature of node (and evented programming in general) to handle certain tasks more efficiently.
But to answer your question, not necessarily. Even if you introduce additional latency, you might still benefit from putting more of the data model into the hands of your front-end guys (particularly if you're at a massive organization where coordination is the biggest hurdle). Plus, there's nothing stating you can't push the mutations performed at the node layer down farther into your stack and, potentially, remove it entirely. And, there's also the case that node might do the work you've delegated to it more quickly than if it were performed in PHP, negating the loss due to additional latency (but if that additional latency is the concern, I'd recommend relying benchmarking to help you make that decision).
Zakas' post isn't really about the crusade for Node.js. At least it shouldn't be anyway. It's about how he perceives a change in UI architecture. I think it's a bit weird that he specifically uses Node.js as you can accomplish this with any "back-end" server language/framework. I think he does a poor job of communicating the change as well. It really boils down to one thing: Some people are generating templates client-side instead of generating HTML sever-side and sending it down. What he refers to as the "Back-end UI layer" is simply just a server generating HTML.
I can't really argue whether his approach is good or not. The way he explains it seems like an extra useless layer that you're going to have to maintain to me though. So you have a RESTful PHP/whatever app returning JSON or the like. And then you have your front-end developers create a Node.js app that takes the PHP apps response and ends up rendering HTML or just returning that same JSON anyway?
I agree that business logic and rendering that business logic into HTML, JSON, whatever are separate concerns but there's no reason why you can't implement them in the same language and just give the client (browser, mobile, whatever) what it wants.
It makes a lot of sense. With services architecture the backend team shouldn't be concerned with the web client but because of historical reasons this is typically how things work.
I think there is value here. The way I see it: there are sometimes calculations that you want to perform on the server, but that are logically part of the UI layer. Maybe you need to aggregate the results of several service calls for a particular screen. Maybe you need to do an operation that's actually several steps.
You could do this all on the client side, of course, but that would perform badly, and might make e.g. security more complex. You could do it on the backend, but that results in a backend service that's tightly coupled to the UI - bad architecture, and possibly requiring close collaboration between two separated teams. By having a component that runs on the server, but belongs to the UI team (and therefore necessarily needs to be written in a language they understand), you get the best of both worlds.
See, I think the fix not using evented programming with tangled callbacks but spawning a (green) thread. Just because PHP does that model inefficiently, shouldn't be a signal to dive into evented programming but find something that does that model right.
Some example: Python's gevent or eventlet based servers. Java's vert.x server. Go, Erlang, Rust. All support a more sane model I think.
Interesting how the same people who are "not fans" of PHP somehow like Javascript. As if it's better.
If not, please remember that different languages are just that -- different, not necessarily better or worse. Personal attitudes towards the differences between languages are totally normal. Bearing this in mind will help the conversation proceed in a more civil manner.
I don't agree with that. Sure, comparing something from completely different domains (for example, SQL and HTML) doesn't make sense. However, for some languages (e.g. C#/Java, Python/Ruby, etc.) it is entirely possible to compare them and point out which is better in some aspects or worse in others.
What I'm saying is that Javascript and PHP are comparable (now that node.js exists and it's possible to write server-side javascript), however, I don't see much advantage over PHP other than being more trendy.
JavaScript even with the bad parts is still more consistent and friendly to use than the core methods within PHP, inconsistent naming structures, parameter ordering and a lot of other issues at the language level.
I've NEVER liked PHP as a language... and that stems from VERY early on in web development. I've used a number of platforms and languages over the years, and none have irked me nearly as much as PHP has.
composer is PHP's version.
Not "frameworks".
Obviously, performance isn't always a good reason to pick a language. I'm certainly not looking to write stuff in C, despite the performance benefits. Just pointing out that there are some solid reasons to prefer JS to PHP. ClojureScript alone is enough of a reason for me.
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.
That being said, I believe that there are more front-end specialists and designers who cannot do what it takes to build an efficient back-end tool.
Try showing your latest application around an office. Few people will comment on how you are grabbing the data, but everyone and their mother will tell you how to make it prettier.
The skills involved in web development and software engineering are so varied that I'd hesitate to define too few buckets to categorize people. Traditionally I think the reason designers get away with learning a bit of JS is because of the simple request, pageview and DOM semantic of the web makes it easy to hack on things until they work without the danger of really screwing things up too bad for 3 reasons: 1) you don't worry about persistence, 2) you don't worry about scalability, and 3) any problems you created only live as long as the pageview does.
Newer APIs like client-side storage and pushstate are allowing browser js to quickly evolve into the realm of serious software engineering with even a few twists of its own (like no easy production logs.) Of course a web designer can still come and do a tutorial and duct tape some things together, but this is equally true of PHP, rails or node. There is an inherent learning curve in learning how to operate at various levels of abstraction well enough to engineer a system that meets latency, scalability, correctness and maintainability requirements for a non-trivial app.
If you specialize in a certain skillset, focusing on that skillset gives you time to be even better. Sure, there's developers that can write both back-end and front-end code but they've given up a level of specialization in order to do that. It's not a reluctance to learn but a different focus of what to learn. It has nothing to do with passion.
Most full-stack developers I've met are really backend developers that can also write some front-end code. They don't spend the time to learn all the intricacies of CSS/HTML or stay up to date with changes in spec / new tools and methodologies. I don't know you at all so I can only guess but if you think about it, do you find yourself better at either the frontend or the backend? It's very rare for someone to be a top 10% backend developer and a top 10% frontend developer. I could call myself a full-stack developer because I'm capable of writing both portions of an application but I know that I don't write one end as efficiently or securely as a specialist.
I came from so-called full stack development. I, unlike many engineers (though the percentage seems to be trending upward), took an early interest in the client-side stuff. As I learned more, I found I was answer more and more of my peers' questions. So that interest turned into a full time job.
The thing about the front-end is it's very easy to pick up in part because it's extremely flexible. You can write horrible, horrible markup, for example, and the rendering engine will bend over backwards attempting to make sense of your mess. And it generally does a pretty amazing job. But, is that code going to be robust? Given that that code has to run on thousands of permutations of environments (different versions of different engines/parsers, on different OSes, on different hardware), how confident are you that it will render correctly? Lets say it doesn't render correctly somewhere, is it because of something you did or is it a bug in the engine? How do you figure that out? If it's a bug, how do you circumvent it?
Many people I work with like the thought of building for one environment. You write code. If it compiles / parses without throwing, you know that execution path works. You cover the different execution paths with test and, if those pass, you ship it. Case closed.
The front-end isn't nearly as clean. It's definitely getting better but there will never be one universal engine / parser. You could argue this is similar to the situation with Ruby, having multiple interpreters. The difference, however, is you choose the interpreter. Front-end guys don't have that freedom as it's controlled entirely by the client.
But lets say you've written bulletproof code. You've got it rendering everywhere. Does it make sense for that platform? Is that same bit of code appropriate for the device it's running on? What about if the network drops out? What if the user has difficulty seeing, will the screenreader bark nonsense or will your site be intelligible? What about if the user is on a touchscreen? Or using a input peripheral for someone with limited mobility? You can be sued for having a site that isn't accessible (discrimination); would your application pass muster?
And that's just the presentation piece. I could go into JavaScript stuff but this is already long. Let's just sum it up by saying there is a lot of terrible, TERRIBLE JavaScript out there (again, mostly due to how simple and flexible it is). Just like anywhere, it takes work to write good, clean, performant, and maintainable JS.
I would argue that the front-end should be considered another tool in a polyglot programmer's toolbelt. Specialization should consist of knowing the edge-cases and gotchas that your typical polyglot won't necessarily know or have interest in but that shouldn't mean you're incapable of developing elsewhere, or are in any way less apt at being a "back-end engineer."
IMHO aside from javascript, there's a huge tedious side to frontend engineering involving html, css, browser incompatibility and ugly hacks that aren't really programming in a sense (more just endless debugging). It's all very domain specific knowledge that doesn't translate well onto other facets of of traditional programming. Hence a lot of backend devs want to stay away from that so they build a wall of separation between the people who do want to deal with it and the ones who don't: "Frontend" and "Backend" engineers.
That being said, I absolutely aspire to be a full-stack engineer, and I'm having fun working towards that goal. I agree that somebody unwilling (let alone, not enthused!) to learn the full stack would make for a horrible programmer.
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.
And you can take my word for it that you should take this guy seriously, or you can check his credentials to make that determination yourself, but suffice it to say I think most would consider him a source of much signal and not much noise.
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.
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?
I don't see how static typing is really necessary to prevent you from storing user-specific data in a global and sending someone another user's data. Seems like that would be fairly straightforward to detect and avoid and I don't think you would usually be tempted to use a global for something like that. You could use a session variable or database.
If you have never worked on the back end, then you are right to be afraid of doing something wrong. However, you are incorrect if you think that means you are likely to make a serious error that you can't correct and therefore shouldn't try. Back end programming is in fact less complex than front-end programming today. So you should jump in. You will learn the most important things you need within a few months.
When you upload a file this generally happens as an HTTP POST. Usually this is sent to your own back-end server code. And without special headers on the target domain your browser won't even allow you to POST to another third-party server. This I think is the issue you are talking about when you mention accessing independent REST services -- that needs to use JSONP or have CORS enabled on the third party server.
Of course you may not need to learn anything about back-end programming because you can in fact build just about any kind of application these days without using your own server at all, just by integrating a number of third-party APIs and running everything from the browser.
By "ui front end at the back end", I was referring to the OP's suggestion to use nodejs as the entry point which the talks to the "real" back end.
I'm interested in real time collaboration where message connections between connected users are easiest held in a shared data structure to reduce latency. I've on occasion mangled this data structure unintentionally without any feedback from JS before deployment. If I'd had some static checking, these problems would've been easily avoided. Hence my fear.
edit: to be clear, my "fear" only applies to languages like JS and untyped racket at the backend. Not of backend programming per se.
Rgd my example, so ... given that I would needs CORS support, the browser->nodejs->backend division of labour that the OP is suggesting doesn't seem workable for such a file upload case.
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.
Every end has a front and back.
I think in the size of applications/companies Zakas is talking about it's probably best if the various layers are like black boxes to one another.
It is a UI-layer, but is it not still back-end?
There's certainly an increasing number of developers who are focusing more on the front-end plus Node.js, often for connecting backend services and providing a RESTful API.
It's worth considering the source, in this case. Nicholas has spent a lot of time both employed full-time and as a contractor at organizations that operate at a massive scale. This solution works if your application, architecture, or even engineers would benefit from additional abstraction.
I do take issue with one point he brings up, however. He mentions the mid-tier communicating with the back-end over HTTP(S). Unless you have some need to serve your API exclusively over HTTP(S), why not use something with a little less overhead (like a message queue)?
I currently program in PHP for all my websites.
Any pointers and comments greatly appreciated. Thanks in advance.
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.
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.
If you're starting from scratch, you can choose a cleaner setup. But if you're dealing with an existing site, you have to figure out if and how you can migrate all the existing functionality. For any non-trivial case (or one with a realistic budget), you're not going to be able to just do a re-implementation and single cutover.