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

61–70 of 163 posts

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

#61

Post by embwbam »

lmm wrote: post #56
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…

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.

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

#62

Post by badman_ting »

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…

> There's nothing inherently wrong with the language that prevents you from writing sufficiently complex and reliable systems to power something like a shopping cart, or anything else for that matter.

In other words, it's Turing complete. That's great but not exactly an argument for using JS server-side so much as a reason why it is possible. I love JS, but I also know what it was designed for.

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

#64

Post by svachalek »

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…

I can understand some trepidation around actual checkout but seriously, how much linguistic fortitude do you need to implement a shopping cart?

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

#65

Post by dasil003 »

ChikkaChiChi wrote: post #33
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…

At the expense of being flamed, I'd say that every back-end engineer can do front-end work even if the end result is terrible from a user experience perspective. You may even find cases in which a person can be equally adept at both. That being said, I believe that there are more front-end specialists and designers who cannot do what it takes to build an efficient back-end tool. Try showing your latest application ar…

There are also back-end specialists who cannot do what it takes to build an efficient back-end tool :)

The skills involved in web development and software engineering are so varied that I'd hesitate to define too few buckets to categorize people. Traditionally I think the reason designers get away with learning a bit of JS is because of the simple request, pageview and DOM semantic of the web makes it easy to hack on things until they work without the danger of really screwing things up too bad for 3 reasons: 1) you don't worry about persistence, 2) you don't worry about scalability, and 3) any problems you created only live as long as the pageview does.

Newer APIs like client-side storage and pushstate are allowing browser js to quickly evolve into the realm of serious software engineering with even a few twists of its own (like no easy production logs.) Of course a web designer can still come and do a tutorial and duct tape some things together, but this is equally true of PHP, rails or node. There is an inherent learning curve in learning how to operate at various levels of abstraction well enough to engineer a system that meets latency, scalability, correctness and maintainability requirements for a non-trivial app.

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

#66

Post by svachalek »

ChikkaChiChi wrote: post #55
camus wrote: post #51

Earlier quoted context omitted.

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.

The potential with Node is that you could have the best of both worlds, using the same code to render on client and server depending on which would provide the best experience given the current hardware and connection capacity. (Edit: it looks like Rendr and Derbyjs are starting to realize this potential)

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

#67

Post by mtam »

I am struggling to see how this approach would be beneficial outside of large organizations with massive web apps. For most apps, the benefits do not seem to outweigh the drawbacks of having (1) another dependency, (2) another piece of software (node) to install, update, and maintain, (3) another set of code base, (4) an increase in latency, and (5) all the added complexity to troubleshooting, debug, document, etc...

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

#68

Post by svachalek »

heynairb wrote: post #53

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?

Most large applications tend to be a constellation of servers anyway, with the advantages of individual scaling, updating, reliability etc. The disadvantages are roughly the same. So, it's optimizing the advantage of having more servers against the disadvantage of having more servers.

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

#69

Post by [deleted] »

karanbhangui wrote: post #35

I've been thinking about this a lot lately (and in fact probably driving a lot of my friends nuts with my views on this), but I think if you take a look at what Airbnb has done with Rendr and what ex-Google Wave engineers have done with Derby, it becomes immensely clear what the potential here is. Traditionally you've had to maintain two codebases for things related to rendering (think generating URL slugs, or format…

[deleted]

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

#70

Post by kevincennis »

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…

Moving more responsibility to the client can let you be a lot smarter and more selective about the data you request from the server, though.

So yeah -- you might have more JS, which will eat some CPU cycles, but you can save yourself from having to request a lot of duplicate data. So, smaller request sizes and if you do it right, fewer requests. The less you can bother the radio, the better.

Post reply on HN