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

51–60 of 163 posts

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

#51

Post by camus »

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…

NodeJS is async by default and RAD. Does it really scale at the corporate level ? depends on what is your product. If you are better off with the JVM or .net , there is no reason to use it. But in my opinion , it definetly has its place in startups.

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

#52

Post by heynairb »

webjprgm wrote: post #26

Do people really pigeon-hole themselves into being just back-end engineers? Or just front-end? I can imagine a designer-type person picking up HTML, CSS, and eventually JavaScript and calling him/herself a front-end engineer in a limited way. But as a programmer I work on all of it, both server-side and client-side portions. (So I'm a full-stack engineer I guess.) It seems to me that a designer who picked up some Jav…

From the other end of the spectrum there are a lot of backend engineers who don't want to touch the frontend.

IMHO aside from javascript, there's a huge tedious side to frontend engineering involving html, css, browser incompatibility and ugly hacks that aren't really programming in a sense (more just endless debugging). It's all very domain specific knowledge that doesn't translate well onto other facets of of traditional programming. Hence a lot of backend devs want to stay away from that so they build a wall of separation between the people who do want to deal with it and the ones who don't: "Frontend" and "Backend" engineers.

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

#53

Post by heynairb »

Isn't this architecture redundant? Why have two application servers in between the database and the browser? Wouldn't it be better to serve the page once and have the browser communicate directly with the api? Is this setup common? Is it really the future?

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

#54

Post by dmunoz »

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 shows that JavaScript performance on mobile has a ways to go yet.

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

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

#55

Post by ChikkaChiChi »

camus wrote: post #51
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…

NodeJS is async by default and RAD. Does it really scale at the corporate level ? depends on what is your product. If you are better off with the JVM or .net , there is no reason to use it. But in my opinion , it definetly has its place in startups.

The concern I express isn't with Node; it's with the front end tools like Angular that shift the cost of building UI scaffolding to the client side javascript engine.

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

#56

Post by lmm »

mjackson wrote: post #50

> 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 in later versions because existing code will be using it. So it's always going to be possible to e.g. modify Object.prototype and then expect the method you added to be accessible on anything. And then that library breaks because you defined an object that already has a method with that name.

Yes, a sufficiently smart developer can write good code in Javascript. But there are very few people who I'd trust to write financial code in Javascript, and I think all of them would use a better language rather than expending the effort working around its deficiencies.

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

#57

Post by hrjet »

I was working in a largish project recently with a three-tiered architecture as described in the article. However, both of the server-side tiers were in Scala, and it was hard to see the advantage in that case.

However, using NodeJS in lieu of Scala for the middle tier, suddenly makes a lot of sense. Thanks to the article for showing this path! To be sure, NodeJS can be replaced with something equivalent, such as N2O or JScala (as others have mentioned). But the concept is more clear when expressed in terms of NodeJS.

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

#58

Post by lmm »

rubiquity wrote: post #24
EGreg wrote: post #4

This is interesting. Basically what I like Node.js for is the evented programming that JS encourages. That and the fact that web developers are already familiar with JS. Consider this: you have a site that will have to scale to millions of people. If you have a lot of reads, you can simply replicate your database, but if you have a lot of writes too, then you'll need to shard (partition horizontally) your database. A…

I'm not really sure what your post is trying to get at. There is nothing unique about the benefits of evented programming in Node.js other than that you're using JavaScript. PHP, Ruby, Python, etc. all have evented libraries. Granted, those libraries don't have as much support for non-blocking drivers (EventMachine is pretty damn close though in my opinion in terms of polished libraries, not quantity of libraries). Z…

>I can't really argue whether his approach is good or not. The way he explains it seems like an extra useless layer that you're going to have to maintain to me though. So you have a RESTful PHP/whatever app returning JSON or the like. And then you have your front-end developers create a Node.js app that takes the PHP apps response and ends up rendering HTML or just returning that same JSON anyway?

I think there is value here. The way I see it: there are sometimes calculations that you want to perform on the server, but that are logically part of the UI layer. Maybe you need to aggregate the results of several service calls for a particular screen. Maybe you need to do an operation that's actually several steps.

You could do this all on the client side, of course, but that would perform badly, and might make e.g. security more complex. You could do it on the backend, but that results in a backend service that's tightly coupled to the UI - bad architecture, and possibly requiring close collaboration between two separated teams. By having a component that runs on the server, but belongs to the UI team (and therefore necessarily needs to be written in a language they understand), you get the best of both worlds.

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

#59

Post by kvcrawford »

webjprgm wrote: post #26

Do people really pigeon-hole themselves into being just back-end engineers? Or just front-end? I can imagine a designer-type person picking up HTML, CSS, and eventually JavaScript and calling him/herself a front-end engineer in a limited way. But as a programmer I work on all of it, both server-side and client-side portions. (So I'm a full-stack engineer I guess.) It seems to me that a designer who picked up some Jav…

It's just a matter of specialization, is all. Not exclusivity. My interest in web development originally stemmed from design, and I am much stronger working on the front-end, as my passion is in UX.

That being said, I absolutely aspire to be a full-stack engineer, and I'm having fun working towards that goal. I agree that somebody unwilling (let alone, not enthused!) to learn the full stack would make for a horrible programmer.

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

#60

Post by marcuswestin »

mjackson wrote: post #50

> 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 open source projects, much of it JS.

In the past 4 weeks I've rewritten my current product's entire nodejs backend to a statically typed language. Why? Because static type analysis allows you to develop more accurate code faster and with lower maintenance cost.

I've been a strong advocate for "javascript everywhere" for a long time. However, these days I believe that there is exactly one fantastic use case for javascript: delivering rich application experiences in web browsers.

So you may be right: perhaps this line of arguing is fading. But in that case I'm a real outlier.

(and with all that said, the most important thing to consider is this: what tool will best allow you and your team to build and maintain your intended product?)

Post reply on HN