As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Until now I've been developing in PHP. Now I'm about to begin a couple of new projects, and I think node.js would be perfect for them. I read some general (internet-oriented) guides on the language, and I can understand them with no problem, but then it seems to become all extremely messy when it comes to put it all together in a real development situation (trough the usage of the many, many available frameworks).
The best guides that I could find looked really dated when I tried to follow them.
Therefore I came to ask in person if you could provide me with some recent and vaguely complete tutorials/resources on how to develop applications (both server side and client side) entirely in javascript.
I usually tend to work only in long term (and medium to large scale) projects and therefore I would like to keep the libraries to a minimum. But I'm also not a hackery type: I like to be able to focus on the logic of the programs, and usage of frameworks is totally accepted. I just wouldn't like to be overloaded with functions that I'm never going to use (or could easily implement myself).
Thanks a lot for your help!
Node.js is built from the ground up on the idea of having a lightweight core that can be extended with any number of libraries (i.e. node core vs. userland). Thus if you use node, you will - endogenically - end up using a lot of little libraries (or libraries that bundle a lot of libraries).
The brilliance here is that you get to choose yourself what kind of stack suits best the specific situation at hand. Node's package manager (npm) is superior in this fashion -- it let's you manage very heterogenous stacks with ease.
If you come from a more opinionated environment like PHP (or rails), the amount of different frameworks and libraries can be overwhelming at first. Node.js does not enforce you to use any specific stacks or conventions, which gives you more flexibility to do whatever you like. In fact you shouldn't even think of node.js as a framework -- it's a JavaScript runtime environment on top of which you can build web servers (and web frameworks).
if you are looking for popular ways people apply node.js, a good starting point is checking out how popular (and dependent on) are various packages in npm (see https://npmjs.org/). Based on the popularity (and dependence counts) of packages, one could recommend using the following kind of stack:
Use express.js (based on connect.js) as your web application framework
Write server-side markup with jade
Use request, async and underscore as helper libraries
Use mocha for writing tests
Optionally write your application in CoffeeScript
Use MongoDB as your database (and optionally redis for like sessions)
Please note this stack is just based on what kind of library choices are popular among npm users -- it doesn't tell you what kind of stack would best suit your specific situtation.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So it's my first time actually making a website and hosting it online--most of what I've done has been tutorials and class work. Now a friend and I want to make something professional and maybe evolve into a business.
1.) I want to be planning long-run but am kind of afraid of being committed to something I have rudimentary knowledge of. What do you think about starting with these technologies (CouchDB, Node.js)? The long-run goal is that it will be social networky and use search, hence noSQL. Will be using Linux + RoR. Node.js is still a bit elusive to me though I've read a lot about it.
2.) Do most web hosting services support these technologies or do I have to find specialized hosting services or host them myself?
3.) What about Cloudant and Nodejitsu/CloudOne--should I consider using these? Other suggestions much appreciated.
I would most certainly recommend a well established PAAS provider. Like maybe Heroku or AppFog. They will make sure you only have to worry about developing your next cool app rather than being a sysadmin.
Heroku also supports deployment by git which is nice. Another big advantage is If your application actually kicks off and you need to scale, scaling with these PAAS providers is often as simple as playing with a few sliders!
1 . There are a lot of noSQL databases available MongoDB and CouchDB are pretty good. They have good documentation. But make sure they fit your exact need before choosing either. RoR is again a great framework. Notably used by twitter. And of course leave the actual server administration to PAAS providers!
2. Checkout Heroku or AppFog. Both of them support RoR and are well reputable with good documentation and community available.
3. I would recommend using Node.js if you plan to build an app which handles a lot of concurrent connections. Like a chat app for example this is basically where Node.js shines.
And finally, Don't think too much into what the hip technologies are. Choose what you are familiar and comfortable with. And most importantly choose what fits your exact need.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I know node.js can build web apps that run super fast, but I just can't find enough info about how it would perform in a magazine or news style website. I know some CMS's like Joomla or Drupal (or even wordpress) are very good at it, but as the number of users grow, I'm seeing some performance issues. Naturally, the web server count but as I want to host it in the cloud, I guess working with node and just create a simple CMS based on it would suit the needs for a better user experience once many users can log in and do their social stuff parallel to the main side of the site that is just a news and reviews site. Does any node.js coder knows about it?
Agree that this is rather subjective, but that said having some experience with node I don't know that there is any particular advantage to using it in this instance. I think frameworks like Django (Python) and Rails (Ruby) are more or less built to accomodate this type of use-case and assuming you have PHP experience but not a lot of node experience, would likely be easier for you to build and deploy a working CMS with very quickly.
Based on what you've described I don't know that any of the advantages of using node will be particularly relevant, and it's unlikely that using node instead of any other modern framework and web server will have a huge impact on your site's performance.
I think this question is quite subjective, as the performance of any application written using modern and maintained languages will depend mostly on the skills of the developer(s), and if your website reaches a certain scale it will not depend only on the language but also on the architecture of your distributed system.
Some of the usual strengths of node are that it is event driven, single language for front-end, back-end thus developer integration should be easier. It's event-driven model gives it a nice and easy(subjective!) way to write and understand (for new devs) applications that make heavy use of concurrent operations such as data-intensive operation across distributed systems.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am really confused with everybody in JS community using Node.js and NPM with their JS libraries. Why do we have to resort to such extreme measures? What problems is this solving for us?
[Edit]
I think my question wasn't to the point.
Frameworks like Ember.js, Batman.js and more recently Yahoo's Mojito require me to use node.js - why this dependency on Node.js and NPM?
Why are we making things complex? "If you haven't already, you'll need to install node.js..." You read messages like this and you're turned off.
Why? There is already a problem of plenty in JS - far too many active JS libs/frameworks to choose from - going by the record of JS libs most will become inactive soon. There are just too many things to look for that often result in multiple frameworks in an app - dependency management, routers, MVC, templating, etc. On top of this we are using Node.js to use these libs/frameworks... How will this push usage of these libraries to new JS developers? JS was meant to easy!
"If you haven't already, you'll need to install node.js..." You read messages like this and you're turned off. Why?
NodeJS is Google's V8 "running on it's own". It's a JS engine with additional low-level API (Network,I/O,etc.). NodeJS provides "the missing platform" for JS developers, who were just limited to working on a browser.
why this dependency on Node.js and NPM?
Node.js, aside from using it as an app (servers, proxies, bots etc.), it can also be used as a tool build and aid development. Take for example Grunt which is a scriptable automation tool which is similar to Make. Scripting in just plain JS, you need not learn another tool or language to do automation. Another tool is Bower, which is a front-end package management tool. All you need to do is a bower install jquery and it installs jquery with that single command. No need for manual download, copy and paste.
NPM, on the other hand, is Node.js' package manager. It's a program that manages the modules you use on NodeJS. No need to list down your modules manually, and no need to remember them when you develop somewhere else. As long as you have the package list NPM made for you, reinstalling is just a matter of npm install.
Why are we making things complex?
We're not. In fact, we're making them easy for developers. Instead of worrying on your workflow, managing your libraries, or doing stuff manually, you can off-load these tasks to some of the modules that exist on NPM. Then you can just focus on what you are actually doing.
On top of this we are using Node.js to use these libs/frameworks... How will this push usage of these libraries to new JS developers? JS was meant to easy!
Like mentioned above, NodeJS is a versatile platform. It can be used as a server (Connect, Express), an automation tool (Grunt), a package management system (using NPM, Bower etc.), a testing platform (QUnit, Mocha), a proxy, game server, chat bot.
And it's beneficial, especially to the JS developer, since these weren't possible in JS.
There is already a problem of plenty in JS - far too many active JS libs/frameworks to choose from - going by the record of JS libs most will become inactive soon. There are just too many things to look for that often result in multiple frameworks in an app - dependency management, routers, MVC, templating, etc.
Well, it's good to have an abundant set of frameworks. Your work will be cut in half after learning some of them. Implementation diversity is also good, to address different styles of coding and different approaches of implementation. Some libraries rise from differing approaches, while others rise from the incompatibilities and/or incompleteness of others.
The developers are hard at work to make life easier for other developers by normalizing JS quirks (because browser vendors just can't seem to do the right thing of following standards) and most of them are done voluntarily, like free beer - you should be happy for that. Besides, nobody's forcing you to use one anyway.
The CommonJS standard (best implemented, in my opinion, by Node.js and NPM) introduces the concept of modules to Javascript. For years, the Perl and Python communities have demonstrated why modules are awesome:
Unix-style "do one thing and do it well" libraries that are small and heavily tested against bugs, that can be combined easily (with no namespace issues) to solve your particular task.
Central repository of open source modules (CPAN, NPM, etc) that you can easily pull the modules from (NPM takes it one level higher by keeping all of the versions available, so you can specify that your code uses the last known "good" version rather than hope that nothing broke when you redeploy a la CPAN).
Greater peer review of the code (since they are more easily composable, they're used in more varied situations, so this is what helps reduce the bugs, but also what helps improve the modules to be more generalized).
Greater variety of tasks solved. Since the libraries are short, pretty much anyone can write one. That does mean there's a lot more crap to filter through (articles about widely-used libraries help with this), but it also means a library that solves some very specific problem (such as localizing strings and dates ) probably also exists.
And then a Node module called browserify makes the actual build process for your client-side code incredibly simple, and you can use just about any piece of code you find on NPM.
This breaks away from the "kitchen sink" mentality of libraries like jQuery (who have developed their own custom build system so they can start modularizing their code, too) that believe they need to solve every problem their user might have, rather than just produce results that can be used by other libraries.
Very often you needs different builds of your javascript. Usually it is spread out in different files, sometimes its in coffeescript.
You often want a build AMD compatible build, as well as CommonJS one, plus regular minimized and unminimized builds.
There's also the potential for dependency resolution.
I've even seen a library that had a build for jQuery and protoype...
Edit: noticed I was answering the question as worded in the question body, but missed the compilation question in the title.
What criteria do you have for considering this an "extreme measure"? This has been done for years, for the sake of writing clean, easy to read/write code, but precompiled to be optimized for on-the-wire transfer (and perhaps other optimizations as well). Node.js makes a nice solution for this, simply because it's also using JavaScript and therefore familiar to people using it to compile their JavaScript code. Previously this was typically done in something like Python, which, though working, seems less sensical to me than sticking with a common language.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Today is 9/17/2011. As of today, what are the biggest reasons why Node.js is unstable, or not ready to use for everyone as a public facing server by itself.
A few things that I've come up with are:
Apps will shut down if unhandled exceptions occur
Libraries are still young and change a lot
Right now I plan on creating an e-commerce site using Node.js, Mongoose, Express, and forever -- and I need some solid reasons to consider so that I can be prepared for whatever comes along. I'd also like to look into how easy it would be to hack, but I'm not too concerned about that yet because it seems like it's quite improbable if I follow standard practices like sanitizing inputs.
Why is node.js unstable?
There are a few
node.js does not work stably on windows
node.js is simply not as tried and tested as say, nginx.
the core API hasn't frozen yet (although it's unlikely to change).
The reasons you mentioned are falicies.
Apps will shut down if unhandled exceptions occur
Yes of course they do. Unhandled exceptions (remember that exceptions are exceptional) crash and burn the server. This is why in production we have strong guards against this. We use clusters of nodes that restart any instances of your application if one crashes.
Libraries are still young and change a lot
Not really. Most of the libraries out there that are stable are indeed stable. There are plenty of libraries which carefully warn you that they are in development / unstable / not production-ready. The only difference is that in the open source community you get exposed to a lot more libraries that aren't ready. Where as in closed source communities you only see libraries when they are ready.
Honestly though 0.4.x is stable on linux and I would use it. I'd still probably also use node.js as a load balancer in front of other node's rather then use nginx but that might be considered risky.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I want to learn more about sandboxing. Not just about it. I want to learn such that I will be able to write a simple sandbox.
Surprisingly, there isn't any information available anywhere. Even the Wikipedia article is not good.
Can any one please suggest me good material. I know that its very advanced level concept. So, what are the prerequisites for learning & mastering it.
read about API hooking, for example sandboxie hooks Windows kernel to filter all api calls to filesystem and redirects it results to sandbox, you could hook APIs and filter it, pass only valid parameters, return errors for invalid calls
for API hooking you will find plenty materials on the net, try on codeproject.com
Google's Chromium uses sandboxing and has several documents about it:
http://dev.chromium.org/developers/design-documents/sandbox
http://code.google.com/p/chromium/wiki/LinuxSandboxing
You might also look at jails in FreeBSD. These are the FreeBSD equivalent of sandboxes.
The source code for jail is available (though you'll have to understand the rest of the FreeBSD code as well.)
A simple sandbox would simply be an environment in which you let 'something' execute, but restrict what it can do.
Typically, this "something" is an already-existing language, like Java, or JavaScript, or C#, or native code. Java has 'sandboxing' apis for applets and so on, and .NET has various 'trust' levels, JavaScript has the bounds placed on it by the interpreters (browsers).
So it's a little weird to "write" your own sandbox unless you also have a language you want to sandbox.
Do you have such a language? What do you want to learn about, specifically?
This is very dependent on what do you want to sandbox. If it is a full-blown system with multiple interfaces/languages available, you really do not want to re-invent the wheel, but run a virtual machine in VirtualBox, QEmu or some other alternative
In any case, a sandbox IS, at least on some level a virtualization of the system you are 'supposed to be' running...
If you need to sandbox applications for a single (interpreted) language, modifying the interpreter sound like a sensible approach.
The answer will likely be language specific. Unfortunately most languages don't have built-in sandboxing capabilities. But functional languages tend to be powerful enough that one can be built from scratch without extending the language.
In Tcl the basic mechanism is to create slave interpreters:
interp create -safe sandbox
interp eval sandbox $set_up_code
set result [interp eval sandbox $unsafe_code]
I wrote an overview of the ways of sandboxing within Linux the other day, which links to a lot of references for the different techniques. Similar methods are applicable in other operating systems. I hope it is helpful - I couldn't find much comprehensively documented either.