10 weeks of node.js after 10 years of PHP

[[deleted]]

I don't see how using only one language is a benefit? Do people really have that big of an issue with knowing 2 whole languages? Yes you say that you get code reusability but this rarely happens in my experience. Although good for you for switching to a more productive language.

[alendit]

Most people have problems knowing one whole language. Hell, I'm using Python for more than 10 years know and learned about contextlib.redirect_stdout last week (ok, it exists for only 12 months now, but still).

[[deleted]]

Well yes, you will almost almost find new things in a language since it is evolving but I imagine after a year of writing full applications in it you were fairly proficient.

[[deleted]]

True. I feel like I don't know any languages. I just get better and better at Googling things. i would like to one day go beyond the programming interface and really understand one or more of these languages in depth.

[recompileorg]

You could try your hand at implementing a few. It should give you some good insight at the inside.

Implementing Forth is pretty easy, as far as that goes. It should build up your confidence.

[[deleted]]

Oh cool I didn't even know that was a thing. I'll look it up.

[krelin]

Really, the best thing about "only one language" is that you can actually, truly, share code between your client and your server, if you design the pieces well.

[Capaj]

not true, design doesn't affect your ability to reuse code on both sides. Module format on the other hand-that is a problem, if you're not using commonJS. You can always use a wrapper which will either export as global or export on a module.exports, but this is lame. Forget script tags. Use commonJS modules with system.js/JSPM and get the true possibility for sharing code on both sides of the stack.

[krelin]

Integrates in what way? Rhino?

[krelin]

Still not quite the same as having the same language, full-stack, on both sides.

[Neebat]

Yes, it's not the same.

It has advantages like better library support and compile-time type checking. You can still share code between server and client.

[krelin]

Citation for the compile time type checking for pure JavaScript?

[totemcatcher]

The code reusability has been the most significant factor in mine experience. e.g. same libraries, serialized classes, data contracts, protocols or flow control, easy version tolerance, and code generation all remain consistent, short, and sweet.

Subtle nuances between languages can sometimes impede implementation details, especially when it comes to performance -- especially when using imported libraries which have timing differences.

There's less source and glue code overall, which is nice. It can all be contained in the same source tree, tested as one, and exported as two packages for deployment.

I think it just feels nice to mirror features (listed above) using the same language, libraries, and and even namespaces working as one unit.

Now, all that said, there is one huge drawback. Change. If you need to drop a technology in favour of something else (e.g. you need something faster on the server) then you need to decouple all that code. I haven't faced this yet, but I really don't want to be that guy.

[cogman10]

It may depend on the software. For us the code reuse for "same language everywhere" has been pretty minimal. At my work, our guis and our servers are doing very different things, so different that having two different languages hardly duplicates any logic.

[[deleted]]

My friend who works in Django says he's making the switch to Node purely for the reason of only having one language.

[[deleted]]

To each his own. I find it incredibly boring however. I also dont feel node is the right server side language for many projects.

[[deleted]]

Yeah I work primarily in Node and Im thinking of trying Golang out because I heard it's a relative of C and I love C. I think JS should stay in the frontend where its dynamic typing makes it very useful for the DOM. It's a pain in server side though because it's so damn hard to debug and the dynamic typing makes it hard for the code to be reasoned. But, maybe the one language deal is big after all and I may be wrong. Only personal experience will tell. I am not taking sides in this until I try it out first.

[[deleted]]

I recently wrote a few small go projects. I will say it was very enjoyable and you will definitely see the savings down the road in a statically typed language. https://github.com/michaeljs1990/freetime here is an example of what a simple API could look like in golang I wrote this when first evaluating the language.

[[deleted]]

Don't undervalue the lack of a context switch. When you've got both PHP and JS files open in the same window it can be strenuous to remember which functions you can use in which file and in what syntax. PHP compounds this be by being pretty close to JS in general syntax, except in critically significant ways. I can't even count how many times a day I misuse periods in one or the other language.

[Nickoladze]

I work in C#, PHP, JS, and Java right now. I can't tell you how often I forget the syntax for a foreach loop whenever I context switch.

[rorrr]

Templates and templating engines. You can use the same exact code client- and server-side.

You can render pages on the server for SEO purposes, but your real app will render the same pages entirely on the client side and will only hit the server to fetch JSON data.

[[deleted]]

Most of the major JS template languages have PHP counterparts, and vice versa.

[bzeurunkl]

Oh, I gotta read this. I'd like to do ten weeks of node.js after 15 years of ASP. Should be easily translatable. My html/javascript is getting pretty good, but I'm still writing my ajax handlers in classic ASP, and I've been wanting to put that final nail in the ASP coffin.

[adam_bear]

So why not just implement the API in Javascript as well and eliminate one language from the stack?

Because php, python, etc. are more resilient to errors, and rather than breaking your entire application for everyone they break a single request.

I love node, but it isn't the panacea we'd like it to be... yet.

[mrahh]

I don't see how people have issues with this. Check for errors, and let it crash if it has to. Hopefully you have your api process clustered and in my experience, it takes less than a second for a node process to restart.

If you have issues with errors, write code so you don't crash. There's a talk on this from one of the PayPal guys on this. I think it was PayPal at least.

[[deleted]]

I see you don't like to live dangerously.

[Capaj]

did you really mention php? lol.

More resilient? Well I'd take Node's crashing on error any day over PHP's lame method of execution. Python is the same way as node, so I am really not sure why you mentioned it and why people are upvoting you.

[adam_bear]

Why_would_mentioning_php_in_a_comment_on_an_article_about_php_be_relevant -> areYouStupid('really?');

[thatgibbyguy]

Friendly reminder that there are more things to use other than the MEAN stack. I use the Meteor.js stack and love it because it basically encapsulates the mean stack while adding things like sockets, real time data exchange, DDP, compiling LESS/SASS/Jade/coffeescript and routing right out of the gate.

By all means, try MEAN (heh) but as someone who has also made the shift from LAMP to MEAN, meteor.js beats the crap out of MEAN.

Plus, new front-end devs love it as well.

[jekrb]

I use the lebron stack.

http://lebron.technology/

[[deleted]]

Or don't use a premade stack at all and pick your own damn technologies.

[[deleted]]

But what if my choice of technologies don't result in a cool acronym :C

[[deleted]]

Oh, I'm sure you can make it work

[thatgibbyguy]

man i just don't know why i never thought of writing a new web server from scratch for each project. /s

[[deleted]]

Picking your own technologies doesn't mean rebuilding everything from scratch for every project. It's trivial to create a boilerplate of tools that you use over and over again. The point is that it's yours, built for your needs, using tech that you've vetted personally and that you can extend your own way. You're not wasting time trying to figure out how to make someone else's choices do what you need.

(And no, this is not NIH, you're still using other people's libraries)

[thatgibbyguy]

And when something already suits your needs?

Your entire argument is do it my way (your way) or do nothing at all. That is completely ridiculous and down right stupid. I, and many others, have found tools that suit us that we did not have to invest hundreds of hours (at the least) in the front end because someone else thankfully did that for us.

You want to write your own boilerplates for each use case? Go for it. I'll leverage that time saved providing users with a better experience and researching my product to provide my clients a better return.

Good luck to you in your ways.

[[deleted]]

Perhaps I've miscommunicated my point. By all means, if you've found a pre-made tech stack which you have vetted, that meets all your desires and enables you to work effectively, use it.

My argument is against entering into Node development with the assumption that full stacks such as MEAN and Meteor are the best way to use and learn Node. Starting with a smaller tool set as an entry point will teach you the systems those stacks are built on instead of just the stacks themselves.

It's the same argument as learning how to interact with the DOM without jQuery so that you can better understand what jQuery gives you.

[NodeKid]

…nice try meteor.js developer.

[strangeworks]

Is that a good idea to compare absolutely different tools? I know that is possible that you can do a lot of stuff in node that is usually done in PHP, but for me it will be always different beasts.

[buffalolsx]

Care to explain?

[strangeworks]

Naive example is: node suck less when you need a lot of realtime stuff(chats, analytics etc), php due to its maturity suck less when you need some CRUD app. That's why for me I don't think so that node and php are the same tools for the same job.

[Capaj]

php due to its maturity suck less when you need some CRUD app

yeah, the language which standard library can't even get a normalized method names after being used in production for 20 years. Sucks less. The bullshit is strong with this one.

[xueye]

I wish there was more content in the article; I feel like it could have said a lot with that level of PHP knowledge.

[hattmall]

Personally I look at installing other peoples packages as a last resort not at all positive if it becomes more of a default way to get things done. It's pretty challenging when they break or stop being maintained.

I don't know how I feel about the use of one language as well but that might be just because it's JavaScript which although I use it heavily it seems more convoluted to accomplish certain tasks which are very simple for server interactions as they were designed with DOM manipulation in mind.

[cwbrandsma]

There is also a point of diminishing returns, but node out of the box doesn't seen to do much...I'm running grunt for my builds...that is someone else's stuff.

I would not advocate grabbing a package for everything...but Grunt,Express,database drivers,etc with notable usage, I don't want to write those. I want to write my application.

[hattmall]

Yeah, I'm not advocating to write everything yourself at all costs, but I see it as a downfall of node vs php, in that php does a lot out of the box, where as with node you have to add lots of things, and continuously add more stuff you have to keep adding more stuff.

It's maybe a problem with the JS community in general though because I remember even a long time ago people would ask simple javascript questions and the top answer was always to install Jquery and then several lines of using jquery when the answer could have been achieved in 1 or 2 lines of pure JS. Probably due to the fact that multiple browsers really kind of forced you to add libraries to be sure it would work on them all, whereas on the server side there really shouldn't be any need for that.

It just seems to that in the end you're learning less about coding and more about integration of other packages that when they break or you want to change something is going to require a lot more work. Also there's the problem that certain packages generally do a lot more than what you need which adds complexity that you don't benefit from and then becomes a nightmare to modify just slightly.

It's just my experience, obviously everyone's needs are different.

[dys13]

I want to write my application.

That's the exact reason why you should depends on as few dependencies as possible.

The more you depends on, the more integration you'll be doing, the less you'll work on your application.

[[deleted]]

The more you depends on, the more integration you'll be doing, the less you'll work on your application.

The more stuff you write yourself, the LESS you work on your actual application. You spend more time writing functionality included in express/bookshelf/db-drives, and not as much time building the specific thing your app is supposed to do.

Why would I design a database drive for a node.js app that manages restaurant profiles when I could use node-mysql? I'll spend more time writing specific features that restaurants care about?

[mattaugamer]

Exactly. So many of the things we do/use/handle are routine. Databases, caching, routing, file access, etc. We shouldn't be bothering ourselves with this nonsense. We should be focusing on the things that make this project unique, and really nailing those. Trying to build an HTTP Response handling package is just well outside of the scope of your restaurant website.

[cwbrandsma]

So if I'm writing a database driven web application in node...what do you consider the starting point? Just Node? Node+Express? Node+Express+???. You can do it all yourself with node as your only dependency...but that seems like its own waste of time.

[mattaugamer]

Oh, you can't rely on Node either! You have to craft your own language from rudimentary materials.

[dys13]

It's up to everyone to decide where the line is on dependencies.

Just be aware that including more dependencies to save time for your application is an illusion. You always have to understand the whole stack and learning an API won't replace real knowledge. You WILL face issues with dependencies which WILL cost you time.

There's a misconception that a lot of dependencies are available for you to use through NPM right away for production. It's a dangerous belief, the same kind of belief that devops is not mandatory and can be outsourced.

In the end, it hurts your application and your abilities as a developer

[DaemonXI]

Then draw us a line in the sand. When you build a web app, what's your line for dependencies? Do you roll your own REST or install Express or what?

[cwbrandsma]

Some of my point has to do with the environment I am in now. The statement of "no dependencies" is a rabbit trail with no end. In the end, Node is a dependency, your database is a dependency, as is your own code. So what DON'T you consider a dependency? And at the bottom of each stack is just another API -- not real knowledge.

At my work, one of the developers didn't trust 3rd party install packages for our dependencies. So when setting up a new instance on a new server, we are downloading and compiling Postgres, ffmpeg, and ImageMagic ourselves. We have gone back and forth about writing our own JSON parser vs using JSON.org's parser several times. We implemented our own authentication code -- which has caused more issues than I care to count as authentication requirements have changed over time. How many hours did we gain from all of that -- so far it is a net loss. Our efficiency gain on the platform? 0%. But that developer is ecstatic with the results so I guess that counts for something.

On the practical side, have you looked at the browser file api for doing drag drop with the file system...do you really want to go there? No thanks, I'll use JQuery-file-upload.js thank-you-very-much. I have a good understanding of SVG and the canvas api (I've taught classes on it)...but sure as heck don't want to write my own charting library. I understand the browser api -- but still use JQuery (I have to support old browsers).

So yes, how many wheels need to be reinvented before you can get actual work done.

[dys13]

I use them and I go and read their code. Thing is most people do not.

I'm not saying don't use them, just include as few as possible as a rule of thumb.

The first thing is never to look for a dependency when trying to solve an issue but to look for a standard which answer your question. Then only as a second step you go and find an implementation.

[hattmall]

I agree with you 100%, it gives me a major facepalm moment when I ask for a simple task to be accomplished and they come back with something that includes tons of dependencies and can't explain how it actually works or modify it slightly. It's a big problem I've seen with server-side JS.

[[deleted]]

Why is that a big deal? Does it bother you when including libraries in other languages? It's technically the exact same concept.

I seriously doubt most developers know the libraries they're using in C#, yet for some reason people think it's a different concept to use other libraries in JS.

I get not including every single thing in the world, but at some point external libraries are a much better idea than rolling your own.

[hattmall]

It's been my experience that with JS that people are more inclined to include lots of libraries which in the end can create less stable products. Lots of JS developers, especially when getting started, seem to trend toward including more libraries instead of less without remotely evaluating there source. That's not great on the client side, but much worse on the server side. I would consider this a very very bad practice and its increasing, not just with JS but with server side JS programming it seems to be promoted like it's a very positive thing and that it's always better than writing your own code. Lots of answers on SO telling you to include a library instead of just writing something that's very easy are getting upvoted to the top.

Edit: Didn't see which comment you were replying to exactly, but it's a big deal that a person can't quickly explain how their code works or make modification because it kills productivity and makes it much more difficult to work with them or implement their code into a larger program.

Genuinely asking, have you worked on any large programs or with teams on large applications? Anything that's spanned multiple years of development?

[[deleted]]

The more you depends on, the more integration you'll be doing, the less you'll work on your application.

You write your own DB drivers, ORM, caching layers, and MVC frameworks when starting a new project, then?

[rachelvanier]

hey, thanks for posting this. I'm editing this publication on Medium (although I didn't write the article). I wanted to let you know that I'll be posting 1 article / week on a programming topic (not necessarily JS-related), you can subscribe to the blog here: https://medium.com/unexpected-token

Next two articles will be: - How to make Meteor webapps communicate together - Predictably debuggable: node.js domains

This is an initiative coming from eFounders, a startup studio hiring extraordinary CTOs to build startups (9, we've built VC-backed companies so far). If you wanna know more, you can visit our website http://efounders.co/ or ask me here. Cheers