8 ms·
The same problems mentioned here plagues JavaScript yet it’s the most used language on the web. JS achieved popularity because it was the ONLY choice in its do
by gaius 9y ago
The same problems mentioned here plagues JavaScript yet it’s the most used language on the web.
JS achieved popularity because it was the ONLY choice in its domain. That's a rarity in PLs, and can't be extrapolated to any other language that I can think of offhand.
- artellectual 9y agoNodeJS is a choice, not a compulsion like client side. Be sure to make that clear separation.
- gaius 9y agoI can see the value in minimising the number of languages you need, and you're already constrained by the client, but I take your point. Node is an abomination, noone would choose it freely.
- simias 9y agoNode is "Stockholm syndrome". Since you have to use JS for the web if you want to reduce code duplication and the number of languages you use you have to bring it on the backend.
- mbrock 9y agoOut of all the dynamically typed scripting languages, I prefer JavaScript. Is there something horribly wrong with me? Linguistically, my second choice would be Scheme, but I still find JavaScript to be more ergonomic for most tasks. It's also way more familiar to more people, obviously, so I think it's a totally reasonable choice for a lot of tasks.
- simias 9y agoI think Javascript is not as fundamentally unsound as, say, PHP. You can see that it was designed by people who had a clue about how languages are supposed to work. The big problem with Javascript is that conceptually it's closer to a functional language than C or Java, yet it opted for a C-style syntax with a bunch of hacks (semicolon insertion being arguably the biggest) so I find that its syntax doesn't really match the way it's used and you end up with rather clumsy looking code even for very idiomatic constructs. Not to mention the super weird type conversions. But that's rather subjective, IMO the biggest problem is simply the lack of a comprehensive standard library even for basic things. I'm not really a webdev but I have to maintain a web interface for one of our products, it uses JQuery, underscore.js and d3.js for various things. There's a significant overlap between these libraries when it comes to standards algorithms and DOM manipulation so you have to learn two or three ways to do the same thing depending on the situation. I shouldn't need external dependencies to have access to underscore.js's "map" or JQuery selectors. Coding in JS feels like coding in C if it was standardized without stdio.h and string.h. Have fun re-implementing strcat every time you need it.
- throwanem 9y ago> I shouldn't need external dependencies to have access to underscore.js's "map" or JQuery selectors. Been a while since you did need. document.querySelector and .querySelectorAll are everything about jQuery that's worth having, and every browser has implemented them for years. Arrays have a map method that does what you expect it should, although do be aware of the odd calling convention. Objects don't map natively, but their keys do, which I very rarely find fails to suffice. (And for those things that really can't be expressed in stdlib without considerable reinvention, Lodash is a strictly better Underscore.)
- always_good 9y agoIt's just a reminder of how incredibly outdated the intel is from HNers weighing in on Javascript in a negative light.
- simias 9y agoI explicitly mentioned that I wasn't a webdev, I never pretended I was some kind of authority about JS. I maintain my point though, so far most sizeable JS projects I've seen depend on JQuery for one reason or an other, so clearly even competent JS coders feel the need to supplement the functionality of the standard library. As for the built in map, the fact that you can't use it on objects is the reason I ended up requiring underscore.js (alongside with the .find and .uniq methods, and probably a few others). I could also have mentioned how hacky and messy it becomes if you decide to split your JS project in multiple files. Or the hack to create "modules", which is at the same time very clever and pretty terrifying.
- always_good 9y agoBut you're also conflating server-side and client-side (jQuery) Javascript. Client-side applications have baggage (infinite deploy targets) that you don't have with server-side applications (one deploy target), so the comparison is disingenuous.
- mcgarnagle 9y agoFirst choice is prefer javascript and second choice is scheme? Can confirm something is wrong with you. Trust me, I'm from the internet. Is this the order you learned programming languages in or something?
- mbrock 9y agoQuick, what's the syntax for updating a hash table in Scheme? "Well, it depends on if you mean SRFI-44 maps, SRFI-69 hash tables, R6RS hash tables, Racket hash tables, MIT hash tables, Scheme-48 hash tables, or . . ."
- pjmlp 9y agoSome examples. - UNIX and C. - Android and Java - Windows and .NET/C++ - JME feature phones - iOS and Objective-C/Swift Or to taking it down to memory lane, - Burroughs and ESPOL/NEWP - IBM RISC systems, IBM zOS and PL/8 - IBM 400 and PL/S - Lilith and Modula-2 - Native Oberon and Oberon - UCSD and Pascal - Lisa, Mac OS and Object Pascal - Lisp Machines - Smalltalk workstations - Xerox Star and Mesa - SpinOS and Modula-3 - .... (plenty more to list)
- distances 9y agoI'm not familiar with the older examples, but only feature phones from the first list are as tightly coupled as Web is with JavaScript. On all others platforms you can either run native code, or code compiled for the platform's default VM, or both.
- pjmlp 9y agoThen by that way of thinking the Web is not tightly coupled with JavaScript, because you can use JavaScript as a target language on a compiler backend. The alternatives to the languages I listed, don't enjoy the same support to 100% of plaform APIs, and respective SDK tooling. Going outside the eco-system means manually writting FFI bindings, not being able to use the GUI designers if available, lack of debugging and profiling support at the same level as the platform tools.
- porfirium 9y ago>Windows and .NET/C++ Not true. .NET is VB, C#, which are completely different from C++, and you can write a Windows application in almost any language imaginable.
- pjmlp 9y ago.NET is VB, C#, F# and C++/CLI. Sure you can write a Windows application in anything else, but be prepared for a 2nd class experience, writing FFI bindings on your own for the Windows API, without access to the tools provided by Visual Studio.