Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js and the new web front-end

nczonline.net

Post reply on HN
Print view View original

151–160 of 163 posts

Re: Node.js and the new web front-end

#151

Post by bovermyer »

CmonDev wrote: post #139
ilaksh wrote: post #133

Earlier quoted context omitted.

Almost no one realizes this, but the main purpose of TypeScript is to negate one of JavaScript's greatest advantages which is the lack of typing. This is an advantage because it makes code easier to write and read. 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 th…

The "Open Web" is closed to one single language choice that was made for you by someone else. TypeScript is being developed, because Microsoft adapts to where the world is moving and they are just trying to avert the disaster that will happen when enterprises will actually start trying developing whole applications in JS. And Google is developing a higher-order version language as well. Nobody developed a language to…

Dart runs on top of JS? I thought it was a replacement for JS.

Re: Node.js and the new web front-end

#152

Post by dragonwriter »

bovermyer wrote: post #151
CmonDev wrote: post #139

Earlier quoted context omitted.

The "Open Web" is closed to one single language choice that was made for you by someone else. TypeScript is being developed, because Microsoft adapts to where the world is moving and they are just trying to avert the disaster that will happen when enterprises will actually start trying developing whole applications in JS. And Google is developing a higher-order version language as well. Nobody developed a language to…

Dart runs on top of JS? I thought it was a replacement for JS.

The primary mechanism for running Dart on the client is by compilation to JS. There is a DartVM that runs Dart directly, but its not bundled into any browsers except for a special version of Chromium ("Dartium") bundled with the Dart SDK so that the development cycle can proceed without a dart2js run at each iteration, but its not intended for general use that way.

Re: Node.js and the new web front-end

#153

Post by dragonwriter »

CmonDev wrote: post #139
ilaksh wrote: post #133

Earlier quoted context omitted.

Almost no one realizes this, but the main purpose of TypeScript is to negate one of JavaScript's greatest advantages which is the lack of typing. This is an advantage because it makes code easier to write and read. 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 th…

The "Open Web" is closed to one single language choice that was made for you by someone else. TypeScript is being developed, because Microsoft adapts to where the world is moving and they are just trying to avert the disaster that will happen when enterprises will actually start trying developing whole applications in JS. And Google is developing a higher-order version language as well. Nobody developed a language to…

> Nobody developed a language to run on top of Java, C#, C++

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.

Re: Node.js and the new web front-end

#154

Post by aufreak3 »

ilaksh wrote: post #135
aufreak3 wrote: post #126

I code a lot in JS these days and I find this divide suggestion interesting. Though I'm proficient in JS, I don't trust myself enough to write server stuff in JS - for ex: while an accidental global access likely has limited consequences on the browser side, it can result in data cross talk between users on the server side. So I do prefer the help offered by some static typing. Even go feels better, Haskell would roc…

I don't understand what you mean by "ui front end at the back end". I think maybe I can guess but really not sure at all. 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 lik…

Thanks for responding.

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.

Re: Node.js and the new web front-end

#155

Post by nathanhammond »

dmunoz wrote: post #54
ChikkaChiChi wrote: post #29

This new javascript wave in which we eschew the needs of the consumer is going to start costing companies big. Processing power, memory, and power consumption are still a pretty big deal in the mobile sector and offloading all these responsibilities to build the view client-side are a huge mistake. Engineers that make their lives easier at the expense of the customer will find themselves in a very empty and very opti…

Discourse has run into a pretty nasty performance issue on Android lately [0]. It would be too strong of a critique to say they are already having the problem you mentioned, but surely if they shipped this as a finished problem and had this issue it would be a big deal. It doesn't appear to be a fundamental problem with their codebase, as the video comparisons to iOS show that it runs reasonably smoothly there. This…

From that same thread, the issue isn't with Ember, it's with V8. Ember itself is looking for a workaround to the issue.

http://meta.discourse.org/t/why-is-discourse-so-slow-on-andr...

Re: Node.js and the new web front-end

#156

Post by hrjet »

ricardobeat wrote: post #148
hrjet wrote: post #146

Earlier quoted context omitted.

You seemed to have jumped from talking about integers to floating point! 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)

There are no integers in js, all numbers are floats. What you want to do is represent all values as integers choosing an arbitrary precision, then only do integer math. In the example given, using node-bignum and assuming our precision is a thousand of a cent: big(30000).mul(3) => 90000 Of course you'd get the same result in plain javascript with these numbers, but then you'd have to handle everywhere an operation co…

I agree with what you are saying. It's just that you gave a floating point multiplication example, where an integer multiplication with overflow would have been a relevant example.

Here's a relevant example,

    2^26 * 2^26 == 2^52
may not hold in javascript because it only supports 52 significant binary digits. Whereas other languages usually support 64 significant binary digits.

Re: Node.js and the new web front-end

#157

Post by tracker1 »

novaleaf wrote: post #124
tracker1 wrote: post #117

Earlier quoted context omitted.

Okay, aside from some scientific functions, what do you really need from an integer that 52bits isn't enough for?

++ yes. for those not aware, all numbers in javascript are 64bit floats. that said, you could still write your own bigint class if you need precision beyond that.

They're 64bit floats, but you get 52 bits of integer precision... You're as likely to hit issues as you are with a 32bit int.. the big difference is you need to use Math.round() if you want to multiply/divide in order to get to a whole number again.. Even with a 64-bit integer, you can suffer from overflow, it's only a matter of where.. and even with 32bit environments there have been work arounds for larger numbers/precision.. with JS there are bignum libraries for this.

Re: Node.js and the new web front-end

#159

Post by tracker1 »

zcrar70 wrote: post #108
Kiro wrote: post #76

Earlier quoted context omitted.

What's so good about TypeScript's type system and what problem does it solve?

the two best features of Typescript's type system IMHO are: - 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 o…

JS already has this..

if (obj && obj.quack && typeof obj.quack == 'function') obj.quack(); //looks like a duck

Re: Node.js and the new web front-end

#160

Post by tracker1 »

tomphoolery wrote: post #121
marcuswestin wrote: post #60

Earlier quoted context omitted.

Devil advocating: 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 ope…

I very much agree with this. While it's definitely fun to build apps in Node, especially when you need one really simple thing to happen with enormous capacity in terms of requests per second, I prefer to build my backend in Rails and frontend in Ember.js, because I feel JavaScript is best used as a frontend language, and Rails is really great at making RESTful APIs as well as encapsulating business logic far away fr…

And rails is particularly better/easier to implement a backend in than NodeJS + crudify/restify/express, or any number of other tools?

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.

Post reply on HN