Related
In all the ways I've worked with Javascript, I find that nothing ever satisfies my desire for self-documenting code. I want to be able to see the APIs of modules, functions, "struct" fields, and event payloads within my own code.
I'm curious if any IDEs or transpiled languages help people easily keep their internal API visible? For example, with many languages, often an IDE will give an expandable tree view of packages/modules/classes/functions. Javascript makes this difficult as there are so many ways to code all of these entities.
I find when writing an application in Javascript that after it reaches a certain size, I have to keep jumping between source files to remember these things. Consistent naming, clear coding style, and such good habits only go so far. In a language that has no static typing, very loose rules around function arguments, and passing functions as callbacks, JS code can be hard to scan and immediately see the higher-level structure. It's hard to separate interface from implementation, as all JS code is implementation.
In large projects with many programmers, it makes sense to enforce rules about documenting functions in comments and maybe auto-generate docs. But doing independent development, this is like a lot of manual work just to remind oneself of the architecture and internal API, and likely to be out of date most of the time. I'm not going to look up a function to remember what params it takes, see that it has no docstring comments, add them and rebuild the docs so I can go read them.
TypeScript sounds promising but seems too tied to Microsoft tools. CoffeeScript saves typing and can make for cleaner code, but I don't think it solves the problem of exposing a high-level view of the structure of an application.
WebStorm actually exposes some of what I'm looking for, but I wonder what else exists.
I'm looking for any tips, tools, techniques others use to mitigate this issue.
I have some C++ code that I want to expose to client side of a web app. Ideally, I want to write Javascript wrapper objects for my C++ classes so that I can use them clientside.
Has this been done before?. Does anyone have a link to show how this may be achieved?
There is a library to convert C++ code to javascript, it might help:
emscripten
Libjspp C++ template based wrapper for embedding and extending Javascript engine spidermonkey 1 . 8 . 5 and more
SpiderMonkey? is Mozilla Project's Javascript/ECMAScript engine.
Libjspp allows C++ developers to embed SpiderMonkey? simply and easily into their applications. Libjspp allows to run multiple Javascript Engines within same process which suits one engine per thread para dime which is helpful in achieving true parallisim. Also Libjspp no way stops user from running multiple threads within engine.
http://code.google.com/p/libjspp/
I guess that RPC is what you want. You'll need to wrap your functions on the server side using some sort of framework. I've not yet used it, but this one looks promising.
On the client side you use proxy objects to dispatch the function calls. The communication is handled usually either via XML-RPC or JSON-RPC. I used this client side framework and was quite content but I'm sure you'll find many others.
This is an old topi, however, I was in the exact situation right now, and all of the solutions I found on the net complicated or outdated.
Recently, I ran across a library which supports V8 engine (including the new isolation API, which makes 90% of the libraries I found outdated) and provides great exposure and interaction API.
https://github.com/QuartzTechnologies/v8bridge
I hope that my solution will help anybody.
There's a relatively new library for doing this called nbind. Maybe that would suit you? It looks very good to me, and I'm just about to start using it.
I think you want a C++ JSON parser. You should be able to find one here http://www.json.org/. It may not do all you want because it just serializes and deserializes C++ objects without any behavior, but it should be good enough. See https://stackoverflow.com/questions/245973/whats-the-best-c-json-parser for some discussion.
If the C++ code has to be on the client, then there is no simple way to do this for a web app. A solution may involve coding plugins for the browsers you want to support, which may then be accessed from javascript code.
If, for example, you need this for a client application, that is another case. Such a thing has been done and involves linking your application to (or running from outside) with for example chromium library, or any other javascript execution engine. That way you can create bindings to C++ classes and use such objects from javascript and vice-versa. Note that this is also not a trivial solution and may be a big effort to implement (also requires additional resources).
You could for example wrap the C++ classes in PHP or Python, and then implement an API over HTTP to access the required functions.
Or if you insist on exposing the functions as JavaScript you could try using Node.js, and create an C++ add-on to wrap you classes. See the Node.js documentation here: http://nodejs.org/api/addons.html#addons_wrapping_c_objects
But either way, I don't think avoid creating some sort of API (HTTP SOAP, XML RPC) to access the functions on your server.
Though QML is not exactly Javascript, Qt is not plain C++, but what they do together seem just like what you need
Disclaimer: This question will be a bit open-ended. I also expect replies to be partly based off of developer preference.
I've been doing some research lately on Express.js (coupled via Node.js) and I'm struggling to find how I would fit either of these technologies into my current workflow for developing websites. Lately I've been working in either Wordpress or Ruby on Rails, the prior will run on Apache, the latter will run on it's own proprietary server (I assume).
Now perhaps I'm just not understanding something, but I fail to see the advantages to enlisting the support of a Javascript-based framework/server. If there are clear cut advantages to making this part of my workflow, what would they be? I haven't been able to find any ways to fit this into (per say) a Rails application or a Wordpress site. Could someone point me in the direction of some better help of implementing these technologies on top of ones I already use?
One last question, what happens if someone has Javascript disabled in their browser? How would a Javascript-based server react (if at all)?
There are two big differences:
Event loop
Node.js is a bit different from the usual Apache concept, because of the way it handles connections. Instead of having synchronous connections, Node uses an event loop to have non-blocking operations. Note that this is not unique to Javascript and there are C and Python based frameworks that also enable a similar event loop approach, however in Javascript it's probably the most natural feeling since this is how JS has worked since it was introduced.
Supposedly, this should enable you to handle more concurrent clients. However, it hasn't had as much real world exposure as the regular blocking solutions so this approach isn't as mature as most current implementations. The actual performance difference is questionable as it depends on the exact requirements for the application.
Code Sharing
This point is much less controversial than the previous difference, but in essence if you have the same language on both the client and the server, you can reuse a lot of the code, instead of having to rewrite your data structures etc in multiple languages, saving you a lot of development time. However, you have to understand that the concepts of server side JS are different from what you know on the browser, such as you don't have dynamic JS with jQuery or Prototype, but it's result and use-cases are more similar to what PHP is widely used for.
The primary advantage of having Javascript as your server-side language is that you're writing your whole system in a single language.
This has advantages in terms of:
Learning curve and mental context switching for the developer
and also in provides some possibility for sharing code between the two environments.
However, this last point is less helpful than it sounds, for a number of reasons, and this is where the disadvantages come in:
Not much code can actually be shared, because of the differences in what the two environments are actually doing. Maybe a bit of validation code, so you know that you're doing the same checks on both client and server, and maybe a few utility functions, but that's about it.
The libraries you use will be completely different between the two as well: jQuery only works on the client, and Node has libraries that are server-specific.
So as a developer, you still need to mentally context switch between environments, because the two environments are different. They may share a language, but their modes of operation are different, and what they do is different. In fact, sharing the language between the two can actually make it harder to context switch, and this can lead to errors.
Finally, it's worth bearing in mind that while Node is getting lots of attention from the developer community, it is still new and evolving quickly: if you're a business considering a it as a development platform, it's probably not quite yet stable enough to base a major project on.
following this post, I took a look at kanso.
From this I learnt that people are not afraid to load to the database context complicated modules if they need them, and that encouraged me a lot.
So I tried kanso. It gave me some trouble that implied immaturity - however, it demonstrateds a great potential.
(mostly compatibiliy view with npm, with node 0.6.x, and some open edge-cases)
So I looked a little deeper.
I saw it comes with a templates engine of it's own.
But what if I want to reuse templates that are written already by another standard?
(for example - haml, or even better - jade that has also a nice text-to-text JS implementation, and a well growing jQuery plugin - same link - see end of document ).
Does anybody here know how coupled the templates engine with the kanso types mechanism, and how simple should it be to use other template engines instead?
Or, what are the limitations I take upon myself when trying to use my own templates?
As far as I can see in the source, DustJS (the template engine of kanso) is not pluggable (like in expressjs for example). That being said, it probably won't be that hard to plug in a different templating engine, the code doesn't seem very complicated.
You might want to add something to this issue on the GitHub page and request for a pluggable templating mechanism.
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.
Does anyone see server-side JavaScript taking off? There are a couple of implementations out there, but it all seems to be a bit of a stretch (as in, "doing it BECAUSE WE CAN" type of attitude).
I'm curious to know if anyone actually writes JavaScript for the server-side and what their experiences with it have been to date.
Also, which implementation is generally seen as the most stable?
I like to read Googler Steve Yegge's blog, and recently I came across this article of his where he argues that Mozilla Rhino is a good solution for server-side JS. It's a somewhat sloppy transcript, you might prefer to watch the video of the talk. It also offers a little bit of insight on why he thinks server-side JS is a good idea in the first place (or rather, why he thinks that it's a good idea to use a dynamic language to script Java). I thought the points he makes were convincing, so you might want to check it out.
A while earlier, he also posted something about dynamic languages in general (he's a big fan of them), just in case you were wondering why to use JS at all.
Why would you want to process
something in Javascript when you can
process it in PHP or ASP.NET which are
designed specifically for this task?
Perhaps because JavaScript is a more powerful programming language than those two? For example, it has functions as first-class data types and support for closures.
Steve Yegge has blogged about porting Ruby on Rails to server-side JavaScript as an internal project within Google ("Rhino on Rails"). He did it because he likes Rails but using Ruby isn't allowed within Google.
Before it was acquired by Google, JotSpot used server-side JavaScript to let you query their database and display your pages. They used Rhino to do it. CouchDB uses server-side JavaScript to create views of their database.
As you can see from these examples, a great way to use JavaScript on the server is for plugins. One of the reasons it's used is that you can create a very isolated sandbox for people to run their code in. Also, because of the way that JavaScript as a language works, you can provide a user tooling specifically honed to the tasks your users need to complete. If you do this right, users don't need to learn a new language to complete their tasks, a quick glance at your API and examples is enough to get them on their way. Compare this to many of the other languages and you can see why using server-side JavaScript to provide a plugin architecture is so enticing.
A secondary popular solution, one which can be seen through a project like Jaxer, is that a common problem of web applications that do client-side validation is that, since JavaScript is easily bypassed in the browser, validation has to be run once again on the server. A system like Jaxer allows you to write some validation functionality that is reusable between both server and client.
Support for JS on the server has been getting stronger and the number of frameworks is getting bigger even faster.
Just recently the serversideJS group was founded. They have a lot of smart people that have been working on serverside JS for years (some of them more then 10).
The goal for this project is to create
a standard library that will
ultimately allow web developers to
choose among any number of web
frameworks and tools and run that code
on the platform that makes the most
sense for their application.
to the people who say "why would you choose JS over java or any other language?" - you should read this Re-Introduction by Crockford and forget about the DOM - the DOM is superugly, but that's not JS fault and JS is not the DOM.
I've never even heard of this, but it strikes me as using the wrong tool for the job. Since programming languages are just tools designed to help us solve some problem.
Why would you want to process something in Javascript when you can process it in PHP or ASP.NET which are designed specifically for this task?
Sure you can pound a nail in with a screw driver, but a hammer works much better because it was actually designed for it...
So no, I don't see it taking off.
Well, plain ol' ASP supported JavaScript server-side years ago and everyone onad their dog used VBShiate instead. But I have to agree with the others: JS does not seem to be the right tool here - and I love to do client-side JS :)
I personally did a whole site in server side JavaScript using ASP. I found it quite enjoyable because I was able to have some good code reuse. This included:
validation of parameters
object modeling
object transport
Coupled with a higher-level modeling tool and code gen, I had fun with that project.
I have no numbers on perf unfortunately, since it is used only on an intranet. However, I have to assume performance is on par with VBScript backed ASP sites.
It seems like most of you are put off by this idea because of how unpleasant the various client-side implementations of Javascript have been. I would check out existing solutions before passing judgment, though, because remember that no particular SS/JS solution is tied to the JS implementations currently being used in browsers. Javascript is based on ECMAScript, remember, a spec that is currently in a fairly mature state. I suspect that a SS/JS solution that supports more recent ECMA specs would be no more cumbersome than using other scripting languages for the task. Remember, Ruby wasn't written to be a "web language" originally, either.
Does anyone see Server-side Javascript
taking off?
Try looking at http://www.appjet.com a startup doing hosted JavaScript applications to get a feel for what you can do. I especially like the learning process which gently nudges the user to build things with a minimal overhead ~ http://appjet.com/learn-to-program/lessons/intro
Now it might seem a weird idea at the moment to use JavaScript but think back when PC's started coming out. Every nerd I knew of was typing away at their new Trash-80's, Commodore64's, Apple ]['s typing in games or simple apps in BASIC.
Where is todays basic for the younger hacker?
It is just possible that JavaScript could do for Web based server side apps as BASIC did for the PC.
XChat can run Javascript plugins.
I've some accounting software completely written in Javascript.
There's this interesting IO library for V8: http://tinyclouds.org/node/
CouchDB is a document database with 'queries' written in Javascript (TraceMonkey).
Considering this, i believe, server-side Javascript did take off.
Server-side programming has been around for a lot longer than client side, and has lots of good solutions already.
JavaScript has survived and become popular purely because developers have very little choice in the matter - it's the only language that can interact with a DOM. Its only competition on the client side is from things like Flash and Silverlight which have a very different model.
This is also why JavaScript has received so much effort to smart it up and add modern features. If it were possible for the whole browser market to drop JavaScript and replace it with something designed properly for the task, I'm sure they would. As it stands Javascript has strange prototype-based objects, a few neat functional programming features, limited and quirky collections and very few libraries.
For small scripts it's fine, but it's a horrible language for writing large complicated systems. That things like Firefox and Gmail are (partly) written in it is a heroic accomplishment on their part, not a sign that the language is ready for real application development.
Flash Media Server is scripted by using Server Side Action Script, which is really just javascript (ECMAScript). So, I do it a lot. In fact, most of my day was dealing with SSAS.
And I hate it. Though to be fair, a bunch of that is more related to the (not so great) codebase I inherited than the actual language.
I think server-side Javascript is guarenteed to take off. Its only a matter of time.
Mozilla, Google, and Adobe have so much vested interest for Javascript that it would take a miracle to dislodge it from the browser world. The next logical step is to move this into the server-side.
This is a step towards moving away from the hodge podge of Internet technology that usually includes all of these
HTML
CSS
Javascript
Serverside Language J2EE/ASP/Ruby/Python/PHP
SQL
I haven't heard much about the current state of Javascript Server frameworks, except that they are mostly incomplete.
I see server-side js will offer considerable advantages in future applications. Why? Web apps that can go offline, client-side db store, google gears, etc...
Following this trend, more and more logic are moving into the client-side. Use an ORM that works for client-side, and use another on server-side (be it PHP / Ruby / whatever), write your synchronization logic twice in two different languages, write your business logic twice in two different languages?
How about use js on the client AND the server side and write the code once?
Convincing?
Personaly i've been developing and using my own JavaScript framework for about 4 years
now.
The good thing about JS on serverside is that implemented in ASP Classic you don't need
any other plugin or software installed, besides i'm also using my javascript (client)
framework on my server, that allows me to enjoy of the same functionality and proven
performance of my functions at both environments client and serverside.
Not only for data validation, but also lets say HTML or CSS dynamic constructions
can be done client or serverside, at least with my framework.
So far it works fast, i have nothing to complain or regret except its great usability
and scalability that i have been enjoying during this past 4 years, until the point
that i'm changing my ASP Classic code to javascript code.
You can see it in pratice at http://www.laferia.com.do
Node.js has taken off and proven that server-side JavaScript is here to stay =)
I can't see most developers getting over their distaste for client-side JavaScript programming. I'd rather go to Java for server-side stuff before choosing JavaScript.