If you have to use Javascript for some reason, node is a less frustrating REPL than what browsers provide, so that part is useful for working out and testing the non-browser parts of your implementation.
Using Node.js as more than that is probably a bad idea.
Name:
Anonymous2012-04-17 10:56
node.js is yet but another wonder shitastic creation to inject some sort of benign usefulness into JavaScript. What with CSS, DHTML, and HTML5 (at the time it was still being planned)... JavaScript needed something for it's fanboys. You know the type. They're easy to spot. Every other sentence that comes from them is has either "scale", "compliant", "solution", or "enterprise".
Name:
Anonymous2012-04-17 15:00
If you want to use the same language on the client and the server, either:
- write CGI in C server-side, and use that c2js thing for the client, or
- write Jabba Servlets on the server, and use Google's j2js thing for the client[*], or
- run Inferno on the server, and use the Inferno Plugin for Internet Explorer 5 on the client, or
- Write LISP on the server, and extend Emacs/W3 to support <script type="text/scheme" />.
[*] Java applets CONSIDERED HARMFUL
Name:
Anonymous2012-04-17 15:09
MOAR LIEKCHODE.JSAMIRITE???
Name:
Anonymous2012-04-17 15:09
It was inevitable that it would spring up.
The web is inertia. It's unstoppable, the network effect is to big. In my opinion JavaScript became irreplaceable the moment it shipped (it certainly is now). It's pretty much the only platform that delivers interactivity with a world-wide audience.
So as we'll need/have more and more JavaScript developers, they'll become cheaper and easier to replace, and people will continue to want to build things that can be built by cheap labor.
Node.js is nobel-prize-winning piece of computer programming
Name:
Anonymous2012-07-11 1:41
node.js is for idiots who don't understand what ``blocking'' means and the difference between concurrency and parallelism.
Name:
Anonymous2012-07-11 13:32
The "web" needs to be replaced with the invention of the wheel of information technology.
Some shitty language like JS, text markup like HTML version 1,2,3,4,5,...,9000+ and XHTML X.Y and HTTP is a pathetic mess of computer science, the worst kind, actually omitting any computer science at all.
It was just a hack thought up 30 years ago by some random dudes who didn't know better.
Today any reasonably bright CS student would be able to cook up a better solution for all accounts, in a week tops! Heck it wouldn't be a problem to throw in TCP/IP in the mix as well, it needs a make over. You know, to make it efficient at error handling. Shit your random chinese made cd-rom hardware is better handling errors than your network protocol of choice. Afraid of change? As if things needs to be static or what? Sure is hard to program generic solution these days.
>>21
No! This is not a computer science problem, it is an engineering problem.
Name:
Anonymous2012-07-11 14:02
I really like Javascript as a language, and node.js is quite cool, but other than making servers you can't do much with it (it'd be too slow for anything serious, no matter how much money Google pumps into V8). I almost never do web-dev stuff, I mostly program in C, but it was kind of fun to play with node.js for a while.
Basically, try it out, especially if you're into web dev, but bare in mind that you can't (or, at least, shouldn't) use it for anything else.
If you want it to be, to me it's just another layer of dung that needs to be discarded by a real solution.
Name:
Anonymous2012-07-11 14:40
Javascript is a horrible language and even worse environment. The semi-functional style is a redeeming quality, but concurrency is not supported so it's not very useful.
The standard implementation is shit. You're interpreting from scratch every time you load. Not only that, you're also downloading the entire code from the server. Which leads to unsafe hacks like GETting code and evaling incrementally.
There have been efforts to fix this--Flash, Java applets, and Silverlight, which will still always be the tools of choice for demanding web applications. But there has been a big push as of late to put Javascript and "HTML5" everywhere.
Ideally we need a standard bytecode that browsers implement with consistent behavior. Browsers become VMs. Then we can write as many compilers as we want. With Lisp, C, Python, C++, or [insert language] compilers, we can easily port current codebases to the web.
This, then the handling of HTML*/JS/etc (old content using shitty ideas) would be defined by the presenter, in bytecode including interpreters and renderers. Probably even exists real world generic APIs for low level primitives for graphics, sound and generic hardware interfaces that could be used in such systems, if not the theory to do so would at least be there. Not adhering to the standard which would have to define the primitives, by different implementations of this system, could be rendered an impossibility by design.
Name:
Anonymous2012-07-11 15:14
>>25
This is what Python "programmers" actually believes.
>>25 There have been efforts to fix this--Flash, Java applets, and Silverlight, which will still always be the tools of choice for demanding web applications.
Java is a joke on the web, only worth considering for ENTERPRISE bullshit where users are forced to use your app no matter how awful it is. It has literally no advantages. (If you think downloading and parsing JavaScript is slow, try downloading a JAR, firing up a JVM and running the bytecode verifier.)
Flash's performance advantages are mostly from hardware acceleration (now a moot point as every major web browser has that natively) and a more efficient JIT. And on the JIT front the difference is narrowing as browser vendors spend more time optimizing JS engines and new APIs are added for stuff that's inherently slow in JS: typed arrays, ImageData, etc. Turns out you can get quite decent performance without introducing the kind of pig disgusting Javaisms that Adobe added to ActionScript.
Can't say much about Silverlight except that its mobile support is even worse than Java and Flash so you'd have to be crazy to use it in a frontend web app.
>>29
It's not 2004 anymore. Java applets are quite efficient, and your ad-hominem characterization couldn't be more wrong. Let's see you do this in ``Javascript'':
>>31
Wow, the performance is amazing: You do not have Java applets enabled in your web browser, or your browser is blocking this applet.
Check the warning message from your browser and/or enable Java applets in
your web browser preferences, or install the Java Runtime Environment from www.java.com
Name:
Anonymous2012-07-12 0:56
You do not have Java applets enabled in your web browser, or your browser is blocking this applet.
Check the warning message from your browser and/or enable Java applets in
your web browser preferences, or install the Java Runtime Environment from www.java.com
Name:
Anonymous2012-07-12 1:47
Thinking Java is a viable RIA platform in 2012 will make you look like a wild eyed hobo who has been out of the game for a decade. Only slightly better than pushing for VRML.
It's retarded to think HTML1,2,3,4,5,etc,9000+,XHTML1.X,JavaScript (look no version),XML,JSON, with more actually resembles anything you would touch with a shit stick, let alone put on a pedestal like 99% of you developers actually do.
The entire web environment is pure junk and you should be ashamed for perpetuating the notion that it is perfect or irreplaceable (which is actually what you believe). As I said, any CS student could come up with something that would be infinitely better in a week at most, and what do we have if not >> 25 mentioning the obvious step to take, standardize on a low level to make sure different implementations can not fuck it up. That's the first thought any sensible programmer would come to.
What you fail to realize though is that many major issues has actually not be solved yet, and can not be solved ever by the mess we have to day. Such as true seperation of content and presentation (or harder, the reverse where the presentation *is* the content and the presentation has to be precise), hell, why not let the presenter define how and what content and presentation is so we could throw the entire issue out of the window, or why not consider arbitrary security constraints, surely your bank would like to have higher constraints than your random shitposting site of choice. But all this goes way over your head, none of it is possible to consider where you are at the moment.
Lord you guys are dense, just take >>25 bytecode proposition and you could let JS itself be interpreted arbitrarly by compiler code defined in said bytecode. If you want MyJS 2.0 to fix issues you have with JS, then go a head and implement it, there wouldn't be any standardization issues. Let your implementation be part of your site or what ever. Same with HTML5,6,..., just implement parsers and renderers in bytecode, publish it anytime you want. No standardization just pure competition. Siteprogrammers would use any bytecode libraries they'd fancy to use, if not writing their own. Sadly you have no idea what I'm talking about.
Name:
Anonymous2012-07-12 14:34
Even Douglas Crockford says that it would be better if Javascript were replaced. The entire language consists of hacks upon hacks. The creator had to design the language and interpreter it in two weeks.
Name:
Anonymous2012-07-12 14:37
>>39
Perhaps it'd be useful to force the inclusion of meta-data in the bytecode to make it much easier to decompile.
Name:
Anonymous2012-07-12 15:37
>>41
This is a good idea, it could include local variable names, line numbers, etc. Annotations could be attached to bytecode so library objects (shipped as bytecode) would carry their documentation along with them.
>>46 RANDALL MUNROE IS BETTER, SEXIER AND SMARTER THAN YOU
Name:
Anonymous2012-07-12 18:31
>>47
Yeah, well. That's only cause I'm ugly and dumb.
Name:
Anonymous2012-07-13 15:30
Everything is wrong and I am smart enought to do it better but I don't have time...
fuck you /prog/
Name:
Anonymous2012-07-13 16:20
>>42 it could include local variable names, line numbers, etc. Annotations could be attached to bytecode so library objects (shipped as bytecode) would carry their documentation along with them.