Node.js and the new web front-end • Hacker News Board

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

#11

Post by EGreg » Mon, Oct 07, 2013, 5:09 PM UTC

jsnk wrote: post #8

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…

Here's a stupid question. If Nodejs is sitting between the client and PHP backend, isn't latency higher than just using PHP backend?

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.

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

#12

Post by [deleted] » Mon, Oct 07, 2013, 5:09 PM UTC

jsnk wrote: post #8

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…

Here's a stupid question. If Nodejs is sitting between the client and PHP backend, isn't latency higher than just using PHP backend?

[deleted]

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

#13

Post by andrewl-hn » Mon, Oct 07, 2013, 5:09 PM UTC

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…

It largely depends on a culture of the people you talk to. For many Java developers Backend means communicating with the database and application logic. But they would consider templating and other veiw code a "frontend work", even though it has nothing to do with the web browser.

However, if you talk to JavaScript developers many of them would consider all code that is executed in a browser "frontend" but would exclude any server-side templating, partials, etc.

Then, some of them would still consider ALL JavaScript code a part of Frontend, be it a browser code or Node code. This can bring up some fun conversations. One of my coworkers talk about server-side bits of project A a "Frontend" because they are written in Node, but considers same functionality in project B "Backend" because they are written in Python.

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

#14

Post by k3n » Mon, Oct 07, 2013, 5:10 PM UTC

jsnk wrote: post #8

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…

Here's a stupid question. If Nodejs is sitting between the client and PHP backend, isn't latency higher than just using PHP backend?

Though there's no absolute answer here, and it could very well go either way, as he explains it would most likely be irrelevant due to the fact that PHP can only process serially.

For instance, if you need to run 3 SQL queries in PHP, then the total execution time will be t1 + t2 + t3. On the other hand, if you make those queries in NodeJS instead, it will be MAX(t1, t2, t3).

So, it depends on the complexity of your app and your ability to decouple and separate concerns in the NodeJS server.

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

#15

Post by badman_ting » Mon, Oct 07, 2013, 5:11 PM UTC

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 does care. That means that the services that put together the pages need to work for the user's use case. That means that the system needs to be designed for the pages the user looks at. You can't escape this, this is bigger than your architecture. It's almost like a law of physics.

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

#16

Post by ebiester » Mon, Oct 07, 2013, 5:11 PM UTC

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 handle two layers each.

Moving to a service oriented architecture where the two groups communicate by REST seems like it would work just as well in most situations, and this was the point.

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

#17

Post by LandoCalrissian » Mon, Oct 07, 2013, 5:11 PM UTC

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…

I think the lines have quickly blurred, to be effective in the 'front-end' I think you need to be an amalgam of both.

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

#18

Post by webjprgm » Mon, Oct 07, 2013, 5:12 PM UTC

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…

Maybe someone has an official answer, but I always thought of front-end as anything in the browser and back-end as anything on the server. Front-facing is user-facing. Back-facing is hidden plumbing.

The article seems to be more about UI vs. non-UI code. Rather than have part of the UI code in the business logic, it can be split out. This was already possible, but with Node.js you can have the server-side half of the UI code be in Javascript so all the UI code is Javascript and the business logic code can be in some other language.

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

#19

Post by andrewl-hn » Mon, Oct 07, 2013, 5:13 PM UTC

andrewl-hn wrote: post #13

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…

It largely depends on a culture of the people you talk to. For many Java developers Backend means communicating with the database and application logic. But they would consider templating and other veiw code a "frontend work", even though it has nothing to do with the web browser. However, if you talk to JavaScript developers many of them would consider all code that is executed in a browser "frontend" but would excl…

Oh, I also would like to add an anecdote. Several years ago I worked at a bank and we had a system with 2 components. One of them was written in Java, the other - in Cobol. Our management referred to the Java part as "frontend" and to Cobol as "backend".

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

#20

Post by k3n » Mon, Oct 07, 2013, 5:13 PM UTC

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.

I think that is sort of the underlying theme of this article, in that the definition of "backend" has been traditionally had to define, philosophically speaking.

And you can take my word for it that you should take this guy seriously, or you can check his credentials to make that determination yourself, but suffice it to say I think most would consider him a source of much signal and not much noise.