Live data from Hacker News

Node.js and the new web front-end

nczonline.net

121–130 of 163 posts

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

#121

> As much as I love JavaScript, there are just some things I don’t want written in JavaScript – my shopping cart, for example. 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 inherentl…

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 from the JS frontend app. I much prefer writing Ruby rather than JavaScript, but I appreciate JS and know it well enough to do a good job.

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

#122
post #61

Earlier quoted context omitted.

I think Typescript solves a lot of these problems. The type system is amazing, conversions are explicit. Syntax is slightly improved, built-in class system. 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.

I hadn't heard of Typescript, but I think we'll be seeing a lot more efforts along these lines. Despite the pain and inelegance of compiling something to Javascript, I see two inexorable forces that will lead a lot of smart engineers in that direction. 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 power…

Where have you been hiding? There's been a virtual explosion in the number of languages that compile down to JS[1] in just the past 1-2 years, and TypeScript is probably the youngest of them all. CoffeeScript[2] is another big one, I believe it's much more Ruby-like. There's even 7 projects involving Haskell.

1. http://altjs.org/

2. http://coffeescript.org/

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

#123
post #110

Earlier quoted context omitted.

What's the big deal with getting bignum into js? Everything else I can agree with, but not having 64bit int support in a server side language has to hurt. (just look at most node db adapters and bigints are handled as strings)

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

It's not about storing large numbers, but math precision. For example:

    0.3 * 3 => 0.8999999999999999
A few rounding mistakes and you have a huge mess.

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

#124
post #110

Earlier quoted context omitted.

What's the big deal with getting bignum into js? Everything else I can agree with, but not having 64bit int support in a server side language has to hurt. (just look at most node db adapters and bigints are handled as strings)

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.

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

#125
post #61

Earlier quoted context omitted.

I think Typescript solves a lot of these problems. The type system is amazing, conversions are explicit. Syntax is slightly improved, built-in class system. 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.

I've been using TypeScript for experimenting with Node.js and while it's a great solution there's a few difficulties some might face with it: -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 t…

fyi, webstorm 7 has good compiler support for typescript, but the ide intellisence/ syntax highlighting is still not great.

i use typescript professionally, i use vs2013 for writing code, webstorm for debugging / testing

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

#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 rock, typed racket also looks awesome from this perspective.

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?

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

#127
I'm quite new to Node.js but I heard that it's really good. Does it really solve the need of server side scripting? I'm thinking of learning it if I can get good justification to.

I currently program in PHP for all my websites.

Any pointers and comments greatly appreciated. Thanks in advance.

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

#128
post #91

Earlier quoted context omitted.

> "not necessarily better or worse" 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…

Well, probably the biggest difference is npm... A great package manager makes things easier to create and use as independent modules. PHP has frameworks, but these are a bit cumbersome. 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…

> Well, probably the biggest difference is npm

composer is PHP's version.

Not "frameworks".

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

#130
post #115

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…

So what is the other static language? I see go programs on your github account also Objective C.

Go
Post reply on HN