Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I’m staying with Node

medium.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Why I’m staying with Node

#31

Post by rimantas »

crdoconnor wrote: post #20
_random_ wrote: post #13

"With Node you can literally share your code between the front and back of a system." Having to deal with a poorly-designed legacy weakly-typed scripting language not just on client (where you have no choice) but on server as well? Why be masochistic?

It makes sense if your app flat out requires a lot of javascript on the client side. I find that javascript is most often an overused crutch on the client side, though. It's used more for premature optimization and making your website look shinier than it is anything really very useful. Nonetheless, some webapps really do require a lot of it.

  > It makes sense if your app flat out requires a lot of
  > javascript on the client side.
Well, you can take a different look: spend some time thinking why does your app requires a lot of JavaScript, and is it really necessary. Even if the answer is still "yes" that may be a good exercise.

Re: Why I’m staying with Node

#32

Post by jaxytee »

Artemis2 wrote: post #3

Is there really any practical examples of sharing code between back-end and front-end? I only see really specific use-cases, such as sharing the logic of a game between the client and the server, since most of the time the back-end serves the content and the front-end displays it.

I sometimes write server code in the browser before porting it to the server. I find it quicker to debug with Chrome.

Re: Why I’m staying with Node

#33

Post by Iftheshoefits »

crdoconnor wrote: post #23
nawitus wrote: post #18

Earlier quoted context omitted.

I agree with your point, but Go in particular doesn't seem very different from, say, C/C++. I think the average programmer who knows C/C++ can pick it up rather quickly, even though going from Java to JavaScript takes significantly longer.

Picking up, while easy, isn't terribly useful. You have to know the non-obvious pitfalls and the 'right' way of doing things. You also need to develop a full understanding of the package/library/framework ecosystem, which can take years . This isn't transferable knowledge, either, but it's absolutely vital to understanding a language. Knowing that requests is a great python library, for instance, and knowing when (an…

I think what you're describing is "being an expert" rather than "being proficient."

If a project requires expertise in a specific language then sure, shoot for "an X programmer" (there are very, very few of these in reality). Otherwise "a programmer" (who is good) will almost certainly be able to perform the job, and do it well, all other things (e.g. motivation, interest in actually using the technology in the project, etc.) being equal.

Re: Why I’m staying with Node

#34

Post by currysausage »

eknkc wrote: post #4

So? I don't think TJ wrote his post just for the sake of complaining or comparing Node with Go. He had a decision, and had to tell the community he was leaving because, you know, a lot of people uses his modules. I rely on a couple of his modules and I liked that he took some time to explain why he'll not be working on them anymore. This post is no more interesting than blogging "I'll keep drinking my morning coffee.…

Yeah, but it's hosted on Medium, so it looks beautiful and weighty. (scnr)

Re: Why I’m staying with Node

#35

Post by couchand »

bryanlarsen wrote: post #24

Node is not going anywhere. It may not be cool anymore, but like the old cool kids (Rails, Java, Perl), it has achieved critical mass, and still has some killer features. Node makes SOA (service oriented architecture) a lot easier. SOA is what all the cool kids are moving to, and is one of the reasons why it's so easy for big companies with lots of legacy code to switch to Go. Once your code is appropriately partitio…

Your point on server-side business logic is spot on. I feel somewhat spoiled now after working on isomorphic JavaScript: any time I need to add rules to a legacy application that requires me to write the same code in two languages I get quite frustrated. DRY, what?

And to your list of isomorphic view frameworks I'd add React [0], which allows you to render server-side with almost no additional effort.

[0]: https://facebook.github.com/react

Re: Why I’m staying with Node

#36

Post by rimantas »

bryanlarsen wrote: post #19
Artemis2 wrote: post #3

Is there really any practical examples of sharing code between back-end and front-end? I only see really specific use-cases, such as sharing the logic of a game between the client and the server, since most of the time the back-end serves the content and the front-end displays it.

Shared code can be a huge win in certain scenarios. 1. the server can run the client code to render and serve HTML, so you get all the benefits of server side rendering as well as client side rendering. [1][2] 2. imagine you have an architecture that allows multiple clients to simultaneously modify a single document, like google docs, or like all your standard cookie-cutter enterprise form & report interface to recor…

Regarding the first point… what's the point really? Either you render it on the client, or you render it on the server, then client couldn't care less what did you use to render it as long as it gets HTML it wanted. If you feel the need to render something in both places I feel that you have some seriously overcomplicated architecture.

Regarding the second point: if the client modifies the document through the API calls, who cares what technology is used to implement those API methods?

Re: Why I’m staying with Node

#37

Post by couchand »

goblin89 wrote: post #28

> With Node you can literally share your code between the front and back of a system. I think sharing code is dangerous as it tightens component coupling and makes architecture less flexible and more complex. An average web project nowadays seems to be a back with many fronts: end-user website, admin interface, iOS app, Android app, Windows app… Making all fronts equal in their separation IMO keeps the architecture m…

I think you might miss both the point of sharing code and the way to go about it. Of course you don't have one single, massive Node project.

First, why. To your point about DRY but with design decisions instead of lines of code, that's how software development has always been; that's what the Gang of Four is. Isomorphic JavaScript allows you to literally not repeat yourself. You write code to solve a problem and you never need to worry about that problem again. Building a system that has every problem solved (at least) twice in (at least) two different languages is what makes architecture harder to understand, and more importantly maintain.

Ok, how. You create lots of little modules that each do one thing well. They declare their dependencies on your other modules, so it's actually much harder to introduce coupling between components. You use the modules appropriate to whichever part of the system you're building.

A practical example: you want to validate user input. You have a series of business rules that must be checked before you allow an update. Of course you want to check them on the client, so you can provide valuable feedback as quickly as possible. But you also must check them on the server, to prevent a wily user from circumventing your rules.

How do you architect this system? If you're sharing code, you just write a function to check the rules and call it in both places. If you're not, you end up reimplementing the rule in both places. But of course you'd like to at least share the rule definitions, so you end up writing the rules in JSON or something and then building parallel rule loaders in both places. Or if you're me you just give up and use Node instead.

Re: Why I’m staying with Node

#38

Post by zimbatm »

talloaktrees wrote: post #10
Mithaldu wrote: post #5

> Hiring for Go — I wouldn’t even know where to start. Ridiculously simple: Set out to hire a good programmer (as opposed to "a Go programmer"), and make it clear in the job description that they're expected to spend the first 6 months learning Go on the job. You end up demonstrating to employees that you're willing to give them something useful, gain loyalty; AND end up with someone you can be confident is able to l…

How to train a new employee on Go: Day 1: complete the tour - http://tour.golang.org/ and read "How to Write Go Code" http://golang.org/doc/code.html Day 2-3: read Effective Go - http://golang.org/doc/effective_go.html Take a whole week, if you feel it is necessary.

You can learn the syntax and be proficient with linear code in a couple of days but not for the parallelism part. Getting a feeling of good patterns with goroutines and channels takes a couple of tries before it becomes right.
Post reply on HN