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

31–40 of 163 posts

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

#31

Post by jeffasinger »

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…

In some cases, doing things client side is massively faster, and in other cases it isn't. It's something that teams need to look at case by case.

For example, over a small data-set, doing typeahead search on about 5000 elements was many times faster, even on some of the slowest hardware than doing it server side.

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

#32

Post by dmak »

carsongross wrote: post #9

In as much as the distinction is useful, wouldn't node be considered backend ? This is what drives me bonkers about the node and JS community: there is so much goddamned noise and "nobody cares!" arrogance in the signal it's difficult to know who to take seriously.

Well, I think the lines begin to blur with these cohesive technology stacks that only use one programming language. I code that is run on the server and not in the browser is considered "backend".

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

#33

Post by ChikkaChiChi »

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 around an office. Few people will comment on how you are grabbing the data, but everyone and their mother will tell you how to make it prettier.

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

#34

Post by EGreg »

rubiquity wrote: post #25
EGreg wrote: post #11

Earlier quoted context omitted.

Yes and no. If Node.js can do things like * cache responses * not send duplicate responses but instead maintain a waiting queue * throttle requests based on # of preforked threads etc. then it would be faster most of the time. And equally importantly you can take a page from Yahoo's book and pre-render stuff on the presumably faster server, for mobile devices and robots.

Why can't you do these things in PHP (or whatever other language you're already using)?

You can, but Node.js is often a better choice than PHP.

Caching: you can have ONE node.js process listening to all requests, and it can keep the cached info in memory, to be looked up much more quickly. In PHP, you'd have to load the entire script environment, connect to an external source like Memcached or APC, etc.

Waitlist: Similar to caching, except Node.js can hold off on responding to the request until the response came back. It's MUCH harder to make something like PHP iterate through the waitlist because a bunch of scripts might get called at once, and the way it works, all of them will have to sleep. With Node.js, only one process has to sleep -- or handles something else while you're waiting.

etc.

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

#35

Post by karanbhangui »

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 formatting dates). This code duplication is obviously solved by running node layer in the middle. But the benefits go well beyond unifying rendering code and separating "backend" developers from "frontend" developers.

My excitement is the ease of building highly interactive apps while staying true to how web pages were meant to be architected. Since your client and server runtime are aware of each other, the framework can handle things like partial rendering, multi-client sync via OT, request caching, incrementally pushing required css/js/html payloads to the clients as necessary (instead of doing one massive push at the beginning). Right now the client and the server talk to each other through a constricted API layer you have to create endpoints for manually.

It's exciting to think how much of this can be automatically handled by the framework. I believe this generation of web architecture will finally bridge the gap between "websites" (often progressively enhanced HTML payload) and "webapps" (massive javascript payload, almost no HTML).

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

#36

Post by Rygu »

rubiquity wrote: post #28
badman_ting wrote: post #15

I love JS, but I have trouble with this idea that people are against using Node because they're afraid of JS or whatever. EGreg has mentioned some situations like millions of users or pushing data to the client, where Node makes sense. But I'm not sure what inherent value running JS on the server has. Also, while it may be true that the backend devs don't care about the flow of pages that the user browses, the user d…

Back-end (god I hate this term) developers should be concerned with modeling the domain of the problem they are solving. That is all.

I disagree, being a good server side software developer means that you understand fully how your models and APIs will be used and what consuming developers really want from it. You enable them to easily drop your solutions into their stack. Be it an external JSON API or an internal class's API.

Every end has a front and back.

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

#37

Post by agibsonccc »

I'm a big fan of using node for an intermediary web stack. It really plays well for handling your web layer with the tools available as well as handling builds with grunt and friends.

I think the real potential comes in when you blend it with a heavy lifting API written in go or on the JVM. Easy web layer that's agnostic to whatever heavy processing language should you decide to do.

Obviously there's a bit of complexity that comes with this, but if you need to scale up it's right there. Even then, node is pretty powerful on its own, where you might not need a crazy backend.

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

#38

Post by proexploit »

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 depends on the employer but I find it quite common. Non-technical hiring managers might see a full-stack developer as a both a backend and frontend developer and it seems very attractive. Top tier employers usually want the best of the best and can afford to have multiple members on a team and thus allow that specialization.

If you specialize in a certain skillset, focusing on that skillset gives you time to be even better. Sure, there's developers that can write both back-end and front-end code but they've given up a level of specialization in order to do that. It's not a reluctance to learn but a different focus of what to learn. It has nothing to do with passion.

Most full-stack developers I've met are really backend developers that can also write some front-end code. They don't spend the time to learn all the intricacies of CSS/HTML or stay up to date with changes in spec / new tools and methodologies. I don't know you at all so I can only guess but if you think about it, do you find yourself better at either the frontend or the backend? It's very rare for someone to be a top 10% backend developer and a top 10% frontend developer. I could call myself a full-stack developer because I'm capable of writing both portions of an application but I know that I don't write one end as efficiently or securely as a specialist.

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

#39

Post by jacques_chester »

ebiester wrote: post #16
jacques_chester wrote: post #7

OK, dumb question time. How are front-end and back-end defined? To me the distinction was about the location of execution. "Front-end" meant "in a browser" and back-end meant "anywhere else with some surface addressable via HTTP". Now it seems that "front-end" means "View and Controller" and "back-end" means "Model", except ... not quite. Sometimes. On the other hand, perhaps I protest too much. It's not as though th…

That's basically it, except in most shops, the controller is this middle ground. It's on the back end, but the back end engineers can't really do the job on their own, so the front end developers end up writing the controllers, calling out to services that are written by the people who are actively implementing the business logic. In most cases, there are really four layers rather than three, and the two groups handl…

That's part of what I was wondering about. In the classic MVC sense, we're turned the Controller into a distributed system with a footprint both on client and server.

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

#40

Post by rubiquity »

Rygu wrote: post #36
rubiquity wrote: post #28

Earlier quoted context omitted.

Back-end (god I hate this term) developers should be concerned with modeling the domain of the problem they are solving. That is all.

I disagree, being a good server side software developer means that you understand fully how your models and APIs will be used and what consuming developers really want from it. You enable them to easily drop your solutions into their stack. Be it an external JSON API or an internal class's API. Every end has a front and back.

Note that I said "concerned" and not anything about the level of skill this developer has. ;)

I think in the size of applications/companies Zakas is talking about it's probably best if the various layers are like black boxes to one another.

Post reply on HN