3 ms·
> if one of your application requirements demanded streaming live data to the browser via websockets, PHP would be a bad choice compared to something like Go or
by meesterdude 9y ago
> if one of your application requirements demanded streaming live data to the browser via websockets, PHP would be a bad choice compared to something like Go or node. Another example might be a webservice that takes some input and has to do computation-heavy work like image processing or rendering, it'd be a big mistake to implement something like that in PHP rather than than, say, a JVM based language.
A nontrivial problem with this line of thinking you employ, is that it expect you'll be proficent/efficent in all of these languages & toolings, when in reality you may just be a really good PHP dev.
It can be beneficial, for sure, to have an idea of where something would do well; doing calculations in SQL vs in server code, for example. But jumping right to it can be foolish if there is a cheaper / "faster" way to do it first.
Part of tool evaluation needs to evaluate your own proficiencies, and the ability to delay optimizations. Maybe PHP is crap for websockets, but maybe you can spin up lots of machines to handle the load and that's good enough; or maybe (in some ways more likely) the project goes nowhere, and that optimization that could have been, was never needed.
- root_axis 9y ago> in reality you may just be a really good PHP dev. If your only tool is a hammer... > Maybe PHP is crap for websockets, but maybe you can spin up lots of machines to handle the load and that's good enough Well sure, you could treat every problem like a nail by going to whatever lengths necessary to solve the problem with a hammer, but that is a waste of time and effort since a more appropriate tool could magnify your productivity instead of frustrate it.
- meesterdude 9y agoyou can do a lot with a hammer. It is my view that it's better to bang out what you can with the tools you've got, and later reach for better tooling when the need or pain point truly arises; instead of trying to optimize from the start with tooling you don't know for perceived potential future productivity. And I consider this not to be a waste of time and energy, but an optimization of available resources. Often, building with what you know is more important than hacking together with something you don't. Especially if you're trying to build a product on it. Of course, building something like a web app in excel would be entirely the wrong approach; your tools have to at least be in the ballpark of applicability.