Node.js
- Thread starter Cory
- Start date
Powerful is extremely relative.
There are things that are pretty effortless to do in Node that are... less than ideal in PHP - and completely vice versa. For example, long-running processes that wait for things to happen, especially long-running processes that multiplex connections (think websockets, chat servers), these are things PHP was never designed for and simply isn't good at. Python needs help doing it (Twisted used to be the go-to here, no idea if it still is), while Node is pretty much geared to this sort of use case from the off.
That said, Node has other deficiencies (there is a reason Typescript exists as a language, and it's to mitigate things that Node itself won't do by default in terms of sanity in the codebase) and the 'you can share code between the front and backend' is still mostly a myth in practice.
I think the best thing to do is give it a go and see how you find it. Some languages just click with people, especially if it's already similar to something you know (Node.js is, after all, JavaScript - though you probably won't use jQuery for anything and anything that hangs off window or document is implicitly a no-go because there's no DOM in a server)
It's always worth exploring other languages and tools because it gives you more choices in the arsenal for solving problems, and if you spend enough time in a language it will absolutely broaden your horizons by giving you a different perspective.
For example: professionally I build in PHP with JS when it makes sense. But professionally I've also done things with (in no particular order), Java, Swift, Go, Python and C#, and as a hobbyist I've also played with Rust, Ruby and myriad other languages that are highly situational (e.g. Inform 7).
I stick with PHP because it's where the applications I use live, and because it's very familiar and convenient, and it pays the bills. But the knowledge of the other languages means I know when I'm chasing something that I shouldn't be doing in PHP and switch to something more useful.
Practical example: not that long ago I had to do some stuff with GeoJSON - think about a 150MB JSON file that represents latitude/longitude boundaries of land regions, and I wanted to know 'given I am in this region, and I am looking at that region, are they neighbours'. So I want to turn this monster JSON file into a list of 'for this region, these are its neighbours'.
Could I have written this in PHP? Eventually, sure. I'd probably have to do a lot of the underlying stuff purely by hand because the main geospatial library for PHP is a bear to get set up properly on any environment unless I'm compiling it myself from scratch (which I never want to do if I can help it), but I know this is far easier to do in Python - so I fire up Python, I include a couple of libraries through pip and I write maybe 25 lines of code to take in the monster GeoJSON data and flip it into something that will spit out the relevant JSON files I will use. I was done in about an hour.
Meanwhile, spending time in Rust teaches me the value of what PHP gives me and what I don't have to think about when I'm writing PHP. Being reminded of that never hurts.
And writing some of the stuff I am for the ZX Spectrum Next just teaches me that in some fields I am not a master but a padawan, with much still to learn.
There are things that are pretty effortless to do in Node that are... less than ideal in PHP - and completely vice versa. For example, long-running processes that wait for things to happen, especially long-running processes that multiplex connections (think websockets, chat servers), these are things PHP was never designed for and simply isn't good at. Python needs help doing it (Twisted used to be the go-to here, no idea if it still is), while Node is pretty much geared to this sort of use case from the off.
That said, Node has other deficiencies (there is a reason Typescript exists as a language, and it's to mitigate things that Node itself won't do by default in terms of sanity in the codebase) and the 'you can share code between the front and backend' is still mostly a myth in practice.
I think the best thing to do is give it a go and see how you find it. Some languages just click with people, especially if it's already similar to something you know (Node.js is, after all, JavaScript - though you probably won't use jQuery for anything and anything that hangs off window or document is implicitly a no-go because there's no DOM in a server)
It's always worth exploring other languages and tools because it gives you more choices in the arsenal for solving problems, and if you spend enough time in a language it will absolutely broaden your horizons by giving you a different perspective.
For example: professionally I build in PHP with JS when it makes sense. But professionally I've also done things with (in no particular order), Java, Swift, Go, Python and C#, and as a hobbyist I've also played with Rust, Ruby and myriad other languages that are highly situational (e.g. Inform 7).
I stick with PHP because it's where the applications I use live, and because it's very familiar and convenient, and it pays the bills. But the knowledge of the other languages means I know when I'm chasing something that I shouldn't be doing in PHP and switch to something more useful.
Practical example: not that long ago I had to do some stuff with GeoJSON - think about a 150MB JSON file that represents latitude/longitude boundaries of land regions, and I wanted to know 'given I am in this region, and I am looking at that region, are they neighbours'. So I want to turn this monster JSON file into a list of 'for this region, these are its neighbours'.
Could I have written this in PHP? Eventually, sure. I'd probably have to do a lot of the underlying stuff purely by hand because the main geospatial library for PHP is a bear to get set up properly on any environment unless I'm compiling it myself from scratch (which I never want to do if I can help it), but I know this is far easier to do in Python - so I fire up Python, I include a couple of libraries through pip and I write maybe 25 lines of code to take in the monster GeoJSON data and flip it into something that will spit out the relevant JSON files I will use. I was done in about an hour.
Meanwhile, spending time in Rust teaches me the value of what PHP gives me and what I don't have to think about when I'm writing PHP. Being reminded of that never hurts.
And writing some of the stuff I am for the ZX Spectrum Next just teaches me that in some fields I am not a master but a padawan, with much still to learn.
Cory
Engaged Member
I tried using Node.js once while doing a course that included its usage on Udemy. It's convenient to use a language as a server-side base for something you're already familiar with. Still, in the same sense, it made me realize there's a lot of Vanilla JavaScript I'm unfamiliar with. I've used jQuery for far too long instead of practicing Vanilla JavaScript. I could try to write my codes using Vanilla JavaScript instead of jQuery, but I suppose that takes away the convenience factor of jQuery in the first place. I've primarily used ZetaBoards and now Jcink as my means for web development and they both have had jQuery installed by default, which is why I've always found myself dabbling with it for so long.
I know I'll never be close to your level of expertise, @Arantor! You know like 500 times more than I know. But that's mainly because I don't apply myself or feel like there are no projects that particularly interest me enough to be motivated to try branching out. I'm stuck in my ways.
When you or @Tyrsson start talking about programming I feel like you are from a different world.
I know I'll never be close to your level of expertise, @Arantor! You know like 500 times more than I know. But that's mainly because I don't apply myself or feel like there are no projects that particularly interest me enough to be motivated to try branching out. I'm stuck in my ways.
When you or @Tyrsson start talking about programming I feel like you are from a different world.
The only difference is time. I've been at this a while and circumstances fell in such a way that I found myself doing it full time - at a time when I had the capacity to spend time learning and refining.
HTML was much simpler in 1998 when I first tried it...
but honestly, the main difference isn't that I'm smarter but simply that I've been able to dump the time into it - and when I came to PHP it wasn't my first language, it wasn't even my first server language, I'd done what we'd now call ASP Classic before that, and I wrote desktop apps before that. I still have a little desktop Hangman-style game I wrote in Visual Basic in 2001. (Incidentally it still works, sorta, in Windows 10. Haven't tried on 11. Probably breaks under the high-DPI screen displays of now though.)jQuery was great when it first came about because browsers were janky and inconsistent about things like sizing and positioning (looking at you IE6) and AJAX was still way too annoying to do by hand when it was still ActiveXObject("Microsoft.XMLHTTP") that we had to use because XMLHttpRequest wasn't yet standard. These days it's very convenient for some work but honestly the biggest thing to relearn is AJAX, everything else is fairly straightforward. While some will advocate for axios, fetch is pretty standard now and after a fashion becomes fairly second nature to set up because syntactivally it's not that different.
The thing about what Tyrsson and I talk about is that it kind of is a different world, at least at first.
In the browser world, everything is event driven - you have the page, it has a DOM, and everything (give or take) is waiting for something to happen, and once that does, whether it's a keypress or a click or something else, you have an event listener that does something. Maybe it does some transformation of the DOM, maybe it fires off an AJAX call, which in itself fires off an event when it's done. The world persists in the meantime, within bounds.
In the server world, this is not really how it works. Yes, on some fundamental level, PHP is sat there waiting for an event - it's waiting for a browser to make a request, but at that point, everything might as well be entirely synchronous: we don't generally deal with callbacks and listeners in the same way, we think about the request being 'a request comes in, an answer is going to go out, and we're going to do a series of operations in the middle'. It is, for want of a better metaphor, a pipe. You set out what steps happen between the start and the end of the pipe and you have to remember that, by default, the world is a blank slate - the server doesn't, by default, know or care which user it is, it's just asked for a page and you have to give an answer. So we end up fiddling around concepts like cookies and sessions which are essentially grafts on top of HTTP for trying to remember who a user is because none of this was in the design, and we end up fiddling with databases for where we store the data in between the requests, and to serve 'the same thing to everyone'.
So it is fundamentally different on some level. But.... that said... the notion of a loop waiting for events is common to almost every area of computing (whether it's games, web, regular applications) - it's part of the circle of computing life: begin -> input -> process -> output -> feedback -> repeat. The only difference is how often that cycle happens, and what we accept as input, what we process and what we output.
Games do this in very tight cycles - reading input 60 times a second, updating the world according to its rules (and player input) and showing the output; applications like Word have the same loop but they don't need to do anything most of those 60 times a second, as they only need to update when the user does something; web has the same cycle again but the chances that a user interaction has a change are even lower.
The slice that Tyrsson and I see is that we're usually responsible for handling the input -> process -> output part and the user does the feedback and repeat parts in the browser. And we come from an environment where it's been actively worked on for the last 25 years such that it has a series of conventions, common design wisdom etc. where we've all been refining as we go for the last 25 years (PHP, such as you could recognise it as PHP, arrived in 1999 or so)
Where all this is going is back to the start: programming is programming, we all do the same fundamental things - we sit and explain, patiently, to a computer what we want it to do and we let it go do that, very quickly. It's also one of the reasons that 'learn more languages' is always encouraged because as you do that, being able to see how everything is all really the same, just taking different slices through it, becomes that much easier.
I'm sure you'll get there if you want to get there. There's also so many resources out there to learn from. The thing about applying oneself is that this also applies to me - I've been struggling with procrastination and burnout lately and I'm beginning to understand what this really means, that it's a pain avoidance response, and that the questions to ask are 'what has it already cost you by not applying' / 'if you continued to not apply, what would it cost you' and 'what would it mean if you did'. It seems trite but those three questions, if looked at honestly and critically, can change your outlook - if you want them to.
Cory
Engaged Member
But, no seriously, that was one of the most extensive, refined responses I've seen about programming on a forum. A lot of it made sense to me, of course, more on the front-end side of things than the back-end, but it was a well-thought-out response to someone who has struggled to learn more and find the motivation to do it.
