4 ms·
I went a similar path, PHP to C#, and never looked back. When I had to switch to Node for one job I was pulling my hair out constantly (and quite literally) bec
by chrismeller 6y ago
I went a similar path, PHP to C#, and never looked back. When I had to switch to Node for one job I was pulling my hair out constantly (and quite literally) because of stupid things that would never have happened in what I called a “real” language (that being a typed, compiled one). I mean for $deity’s sake, there weren’t even any dependency injection options at the time and many many times it turned out a bug I introduced was because of simple typo in a camelcase property name.
I absolutely love Node for the ease of writing something quick and dirty. No dependency injection, no coding standards, nothing but a tool to quickly churn through a ton of data or to perform a single task really well. I also think there are some frameworks (using Typescript, like NestJS) that do JavaScript apps really, really well. I will still, never, ever, ever voluntarily write any kind of “real” application in a language that is not type safe again. The benefits just aren’t worth the perceived time savings...
- jkoudys 6y agoIf most business-side people actually knew what weak typed languages meant for their company, I can't imagine so many of them going for php/js as often as they do. You're always one expression with a `$contact` instead of a `$contract` in it away from a cancelled weekend trip or humiliating sales demo.
- eyelidlessness 6y agoIf the business side is making these kinds of technology choices, the business itself and the engineering side both have significantly worse and more important problems. And those problems will inevitably create those cancelled weekends.
- chrismeller 6y agoHonestly, I think there’s an equivalency there. Someone who is an expert in JavaScript means a couple of years. You can hire a high-end JS Dev for a lot cheaper than you could any other language or platform.
- alkonaut 6y agoNode isn't so bad now with typescript. The JS folks learned from endless fixing hot mess code that you couldn't really do with anything less than a good dev experience (Imagine a 5 minute turnaround from edit to test on JS to find a typo in a variable). With TS you get all the nice dev experience from JS, but also some of the C# niceness.
- eyelidlessness 6y agoHaving spent the last several years working in Node/TypeScript environments (and being firmly in the “I was wrong about types” camp), I think “isn’t so bad” is an overstatement. It certainly isn’t as bad. And especially as TS improves, the possibility to move more and more toward the “not so bad” ideal is there. But there’s some truly awful stuff in the ecosystem; in the underlying language and the platform’s DNA; in the compromises TS (rightly) makes to be a productive real world tool; in the commonly used tooling; and just peppered throughout everything you can expect to encounter in common third party libraries. Overcoming all that awfulness requires a lot of additional effort, is inherently limited, and isn’t common in the community (although that too is improving as TS becomes more popular, and as safer patterns become more idiomatic). I think if I were building a new greenfield project with my choice of platform today, it would be a difficult choice whether to take all that I’ve learned in Node/TS and accept those trade-offs, or to invest in learning another platform.
- azangru 6y ago> or to invest in learning another platform What other platform do you have in mind?
- eyelidlessness 6y agoHonestly haven’t given it a lot of thought, as I’m not currently starting a greenfield project with my pick of platforms. But I think off the top of my head, languages that I’d look at as first contenders include F#, C#, Kotlin, Swift. I’m sure there are other good choices, for the kind of space I tend to work, that are equally productive and have enough of a community for me to be comfortable adopting them, but I would need to spend some more time researching options to really say with confidence what else I would consider.
- jcranmer 6y agoThe other issue with dynamically-typed languages is that the language sometimes "helpfully" fixes the types for you. I came across one JS project that said this: for (var i = 1; i != Math.pow(2, 16); i <<= 1) Replacing Math.pow(2, 16) with 1 << 16 effected a 30× speedup--and this was in SpiderMonkey, which tends to be a little less finicky about optimizing mixed types than V8. (It's been a while since I coded PHP, but my recollection is that PHP tries to pull a strings-are-integer tricks a few times).
- pavel_lishin 6y ago> my recollection is that PHP tries to pull a strings-are-integer tricks a few times Yeah, the implicit casting in PHP is bonkers, especially when it comes to comparisons. The comparison table looks like the scribblings of a madman: https://www.php.net/manual/en/types.comparisons.php https://www.php.net/manual/en/types.comparisons.php (though granted, Javascript acts very similarly.)
- nucleardog 6y agoI have no hate for PHP, it’s been a tool in my toolbox for over a decade, I think it has a lot of good qualities, and it has made me a lot of money. That said, after ten years of use, I still see something like: function_returning_false_or_int() > -1 And sometimes have the wrong intuition about what it does. Now, nobody should write that shit in the first place, but turns out it’s equivalent to ‘!== false’. ‘(int)false’ is zero, but ‘false > -1’... is not true.
- three14 6y agoThis doesn't look to me like a dynamic typing problem. All the types are Javascript numbers. The issue probably stems from Math.pow's flexibility; it can even accept fractional exponents. The more general algorithm is probably slower.