Hacker News Reader

Comment by medeas_crypt | Hacker News Reader

I feel it's probably been said before, but why are people investing time in a Javascript server side framework? It just seems ridiculous.

Edit: I can understand shipping logic from the server to client, for validation perhaps. But... meh.

View on HN

From personal experience developing at all levels of the stack, I think my job breaks down into something like

  * 40% UI (visualising states, handling user input, feedback, etc), 
  * 55% moving data around (read an XML file, translate it, push it into db over there)
  * 5% algorithmic work (given input of x million records, figure y out)

The UI stuff I already did in Javascript, however it turns out that one single threaded process can shuffle a lot of data around (resource efficiently), if I adopt an async programming style. I know NodeJS is not the only language that does async stuff nicely, but it's rather convenient to have the same language everywhere (though I recognise Javascript is not the most elegant).

If your success relies on search engine listings, it is still better to render the contents on the server to that the crawlers can index it (some still penalise JS only sites). You can then "hydrate" the SPA on the client for a better user experience.

Because they believe that a single language should be enough for developing web applications.

What became of "the best tool for the job"? I doubt the benefits of having a single language outweigh the effort put in just to replicate solid server-side environments existing today.

I know what you mean, but at some point in history you could say that for every programming language that wasn't the first one to dominate that specific domain.

Absolutely and I'm not against innovation at all. The exercise of making JavaScript a valid server-side alternative often seems pointless, though. What's the benefit of JavaScript on the server side other than "one language"?

Perl, Java, Spring, Ruby on Rails each offered significant benefits over what existed before. What does JavaScript on the server side do better than other solutions? There's the event loop and non-blocking behaviour but is that enough for most applications to justify using JavaScript on the server side?

For me it is not just about being comfortable in writing the same language for aerver and client. It has also a technical aspect to it:

I can directly run my application code, which is a single page application in js, also on the server. I have complex datamodels in my js application. It would be very much work if I need to use some of these datamodel functions on the server if I wouldn't use js there.

I think you may be underestimating the "language barrier" for more junior devs. What I see around me is that it takes a few years of programming before you start "seeing through" the syntax and realise it's all the same.

With Javascript everywhere, I experience we have less resistance for people to work all over the stack.

Also there's something to be said for JSON. There is a big win in having it all the way from the DB, untranslated up to the UI.

> I think you may be underestimating the "language barrier" for more junior devs.

I know people like that. Once junior devs, too back in the heyday of Enterprise Java in the late 90s they couldn't be bothered to learn this ugly upstart language known as JavaScript because "serious developers don't use a toy language like that". In part, who can blame them? CS professors at that time floated ideas like object-orientation and code generation being the be-all and end-all.

These developers sometimes went at great lengths to avoid writing the tiniest bit of JavaScript at all (when it 'finally' became obvious that this newfangled web thing wasn't a passing fad ...) and invented convoluted frameworks that generated JavaScript from Java code. These frameworks inevitably couldn't keep up with the pace of change in the web development community at large, which is why nowadays they often are a huge technical debt to the projects they're used in.

The developers themselves, now not so junior anymore, often have a hard time finding a job today because learning something besides Enterprise Java was too much of a hassle.

So, while the idea of "easing in" junior developers by having a consistent language in all layers might have some merit, in the long run it might very well be doing them a disservice and also leave behind a huge pile of technical debt in the end.

Yes. Despite writing both straight assembler (68k processors) and C back in the 90s, I also fell into the Enterprise Java-trap for a long while. GWT was my go-to front end framework, and it worked I suppose.

It's a bit hard to compare these days, since browser quirks were much more pronounced back then. I remember tackling differences in IE4/5 vs Netscape 6/7 and all those hacks and workarounds seem absurd now. When GWT entered, it at least unified these platforms and worked around many differences for me.

And don't get me started on server side enterprise stuff. I still run screaming when someone proposes "IoC containers" or "workflow engines" in NodeJS. Never again!

Wonder whether "Virtual DOM" and "Transpilers" is what I run screaming from in 10 years?

(i already decided against transpilers, ES6 syntax isn't worth the overhead imho)

They still offer benefits. And some also offer an event loop and non-blicking behaviour. However there is a huge number of libraries around Node which enable you to solve problems both in the browser and on the server. For example Highcharts rendering graphs in the browser and rendering them as a png or pdf on the server, enabling the user to save them.

Too bad it doesn't have a standard library, too bad js is an ugly language compared to Ruby or even Perl. Too bad npm duplicates dependencies and pulls tons of packages.

Probably a fair enough perspective. I guess I just hate it. With a passion.

The consequence is that you can share code between client and server which is a large benefit.

But Javascript fans often also say the server should only be a REST API, consumed by the client side, and not bound to it. What that means is :

1) It makes no difference at all if is the server is implemented using a different language than the client.

2) You shouldn't share any logic/code between the server and the client, even if they are using the same language.

I realize you are critical of that viewpoint, but point 2 seems really wacky to me.

Current big project at work has a back end that is not in JS, but we still have a way to run the same validation code on both sides, which is run in an embedded JS interpreter on the server.

I'm not sure I would want to write a complete back end in JS or not (even if I'm not in love with Java, lately), but reusing this part makes a lot of sense.

---

We currently serialize (sync block) validation requests on the server through Nashorn, rather than having multiple instances (per thread or a pool). But, it's not like the requests wouldn't be serialized through Node, though. The rest of the request processing happens on independant threads normally. Not overly fond of threads, but I don't think I could get my team to by into Erlang or Elixir :-)

For that matter, my primary partner on this project is a big Scala fan, and we couldn't even get the rest of the group to go for that :-(

> 1) It makes no difference at all if is the server is implemented using a different language than the client.

Makes a difference: Same people can maintain it without too much friction.

> 2) You shouldn't share any logic/code between the server and the client, even if they are using the same language.

Why not? It's nice, for example, to export your validation logic to a separate library and consume it from both sides.

> Makes a difference: Same people can maintain it without too much friction.

For a very small team, I guess it makes sense. I would still prefere to be able to use Java/Kotlin/C# on the server and on the client then. Or even Dart. Not Javascript...

> Why not? It's nice, for example, to export your validation logic to a separate library and consume it from both sides.

Then they are couple together. And then you will tend to design your API in a way this particular application is well deserved. But if one day you have to consum the same service from another application, a native iOS application for instance, then you may start to realized that your API is too bound to your first consumer.

But I guess it's not that important if your backend will only be consumed by this particular application, ever.

> Then they are couple together. And then you will tend to design your API in a way this particular application is well deserved.

We have a server which exposes validation logic as a generated JS library (no server-side JS yet but we plan switching to Typescript) and that is used across many (more than 10) clients. I don't see any coupling. Changes in your models break the API regardless of you sharing anything.

Also, JS is built to handle concurrency. Other languages have event loop libraries, but in JS it comes with the language and every web dev uses it.

"Async all the things" concurrency doesn't matter.

Javascript is not going to be faster than Go or Rust, which are increasingly taking over as web backends. (I'm writing stuff in Rust's Iron framework lately.) Or Java, for that matter.

I can serve more requests from these languages than "concurrent" Javascript.

I don't doubt that you can. But in a lot of situations, as long as the slow stuff like db queries and api calls don't block, it's good enough. And that's easier to accomplish in JS.

What does it mean that it "comes with the language"? In what way is Javascript the language any more asynch than Python, PHP, or Ruby? The browser and Node environment are not JS the language. They are the environments JS predominantly runs in, and they provide async events, which could be done with any language running in similar environments.

Would your objection be appeased if he said "comes with the environment"?

IDK of any Python, Ruby, or PHP runtime that has Node's paradigm of single threaded + concurrent I/O.

Would Python handle async well with the GIL?

This has only been the case for a few years, since the ECMAScript Xs, which is why I think you're being downvoted. To be fair, it's a relatively new feature in Python too.

To me, it's the event-driven problems JS tries to solve that seems to overlap with typical server functionality. That has been true since the beginning.

What, that you clicked a button and JS did something back in 95 when Netscape introduced it? The same could be said for Visual Basic for any language that had callback code attached to a button click. You do realize that Python, Perl, etc could be written to handle GUI code back then as well.

JS has been focused on event handling types of problems while python and perl were used for many other types of problems. You can build a GUI with R, but it wasn't made for it.

>You can build a GUI with R

Why would anybody do that to themselves?

Reply on news.ycombinator.com