Live data from Hacker News

Node.js and the new web front-end

nczonline.net

81–90 of 163 posts

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

#81
post #77

> I was never a fan of PHP Interesting how the same people who are "not fans" of PHP somehow like Javascript. As if it's better.

Are you claiming to have an objective yardstick for comparing the goodness of languages? (Don't answer that.)

If not, please remember that different languages are just that -- different, not necessarily better or worse. Personal attitudes towards the differences between languages are totally normal. Bearing this in mind will help the conversation proceed in a more civil manner.

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

#82

> 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…

Developing things with the language has never been the problem.

Coming back and maintaining them a year later is a different story.

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

#83
post #79

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…

In what language are you rewriting the backend?

Bet it's Java.

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

#84

> 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…

Yeah I generally agree. With the builtin addition of require() and reasonable scoping rules, Node.js has turned Javascript into a weak-typed, memory-managed C. There is still the 64-bit integer and large decimal problem, but otherwise that is great. I don't see why the entire backend cannot be Node.js.

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

#85

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…

Alternatively, I could suggest that CPU is cheaper than bandwidth, especially on mobile, so not sending a full html document with every request and just sending the required data and updating via JS makes much more sense for mobile. Although this article is mostly about javascript on the server, and so isn't focussing on the fat js sites that you are talking about.

Bandwidth is a deferred cost. CPU is an immediate cost (on a mobile device).

When you run a CPU-sucking stie on your device, you typically know exactly which site or app is the culprit - you can watch your battery drop and feel your CPU heat up.

When you get your bill at the end of the month, it's a lot less clear why, exactly, that happened. And - fairly or not - it's a lot less likely to be blamed on a lightweight site that grabs extra data.

Not that these two things should be mutually exclusive anyway: an app designed for mobile will do most of its processing on the server with short bursts on the client, and ALSO be optimized for data on the server side. (The server, after all, typically knows what kind of client it's serving.)

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

#86
post #56

> 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…

It doesn't have an adequate type system. There are too many silent conversions. The syntax is very clunky. All the object systems feel hacky and they can't be relied on to interoperate with each other. Problems like no standardized threading support or decimal type could be resolved in the future. But the language as it exists currently lets you override everything, and that's the sort of thing that you can't remove…

This is why I hope and work towards making Dart succeed. Dart is very nice as server-side or command-line scripting language - the VM and dart:io provide a very node.js-like environment. It provides much more safety, structure and feedback to help guide developers towards better code than JavaScript.

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

#87

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…

It would be interesting to try a solution where Node.js incorporates itself either on the client side or the server side depending on the device. Or even putting Node on both sides and "load balancing" depending on processing power.

I'm also really interested in seeing how feasible it would be to push all Javascript to the server and basically letting the client act as a dummy terminal that sends and receives Javascript snippets through a WebSockets connection (which is more mobile-friendly than AJAX since some mobile users pay per TCP connection). I would expect that latency would result in an overall slower app, but maybe some client side-heavy apps could benefit from it.

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

#88
post #56

> 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…

It doesn't have an adequate type system. There are too many silent conversions. The syntax is very clunky. All the object systems feel hacky and they can't be relied on to interoperate with each other. Problems like no standardized threading support or decimal type could be resolved in the future. But the language as it exists currently lets you override everything, and that's the sort of thing that you can't remove…

Java and .NET are the only strongly typed languages used heavily as a web backend. Python, PHP, Ruby, and Node.js are all weakly typed.

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

#90
post #77

> I was never a fan of PHP Interesting how the same people who are "not fans" of PHP somehow like Javascript. As if it's better.

While "better" is of course subjective in many, many ways, Javascript on V8 via Node is much faster in most computations: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...

Obviously, performance isn't always a good reason to pick a language. I'm certainly not looking to write stuff in C, despite the performance benefits. Just pointing out that there are some solid reasons to prefer JS to PHP. ClojureScript alone is enough of a reason for me.

Post reply on HN