6 ms·

There's some truth there in your comment but also a lot of wrong things. > 1. Over-reliance on tooling Everything has tooling, I defy you to find a single lan

There's some truth there in your comment but also a lot of wrong things. > 1. Over-reliance on tooling Everything has tooling, I defy you to find a single language you can use in a medium-size project without any tooling, good luck, I don't know any. > 2. Any serious JS project is a long term maintenance burden. The prevalence of "single line libraries" makes future-proofing of the code impossible. You don't only have to version-freeze your immediate dependencies, but dependencies of your dependencies It's the same for any language. Yarn has a yarn.lock for this exact purpose, for other languages you will have [your language package manager].lock, it's the same. > For practical purposes, JS code is barely as quick as Perl or python. It's currently 3 times faster than Python and the gap is only widening every year. You picked the wrong languages to compare the speed, at least you could pick Rust, Go or C++. > 5. Zoo of standards on the front-end, browser APIs changing on a whim. It's getting better with vendoring nowadays and the core features are there everywhere. You only need vendor-specific APIs if you build something specific. > 6. Zoo of sublanguages: Coffeescript, LiveScript ClojureScript, MoonScript, AtScript, TypeScript Only TypeScript is alive nowadays, all the others are kind of dead so this isn't true. Also MoonScript is for Lua so it's not even related to Javascript. > 4. Readiness to do breaking changes in between major hard versions, and no reservations for backward compatibility. Most features are not backward compatible, that's why you need to use some tooling. You cannot have no tooling and no breaking changes at the same time.

boobsbr 9y ago
Kinda makes you think the person you're replying too is not a JS developer and hasn't touched the ecosystem at all, and yet it's here spewing nonsense.
egeozcan 9y ago
> Most features are not backward compatible Important thing is: The VM (or the interpreter, or whatever runs your code) is almost always backward compatible. If you write code now, it keeps on running. JS code from the pages coded a decade ago runs just fine. I can't say the same for (from the top of my head) Android, for example.
- realusername 9y ago
  Ah yeah it's true, there's very few features that are actually removed from the browser. I just remember some kind of iframe version of window.alert (can't remember the name now) which got removed a few years ago but it wasn't used that much.
- baybal2 9y ago
  >JS code from the pages coded a decade ago runs just fine. Far from truth. A lot of breakage happen due to browser API security policy changes, obsolescence of browser APIs. In on case, I even saw a code failing because the behavior of mathematical operators with floats have changed over time. This is why there is little point for JS drafters being hellbent on backward compatibility to the absurdity (remember few pages long typeof null flamewar) >I didn't know about this. Do you have a source or explanation? (by the way, all numbers in JS are double-precision 64-bit format IEEE 754-2008 numbers so you mean they actually changed the operators?) As I understand, browsers' js engine, under some conditions, can provide more precision than what browsers were giving in nineties. That way if you vere reliant on if(1 - trickyFunction(0.000006464)) doSomething(), the condition will eval differently if function will return a value just a little bit bigger than 1.0000000000
  - egeozcan 9y ago
    > In on case, I even saw a code failing because the behavior of mathematical operators with floats have changed over time I didn't know about this. Do you have a source or explanation? (by the way, all numbers in JS are double-precision 64-bit format IEEE 754-2008 numbers so you mean they actually changed the operators?) > A lot of breakage happen due to browser API security policy changes, obsolescence of browser APIs Non-standard features, yes. Standard features? Rarely (like WebSQL, opening HTML data URLs directly from code and so on). Standard features with wide adoption across browsers? I have just one case because of the recent CPU bugs. Standard features with wide community adoption? Never.
baybal2 9y ago
>Everything has tooling, I defy you to find a single language you can use in a medium-size project without any tooling, good luck, I don't know any. On my memory, large projects on PHP and Python falling into that category are all around the place >It's the same for any language. Yarn has a yarn.lock for this exact purpose, for other languages you will have [your language package manager].lock, it's the same. No it isn't. Heck, the prime example of a "fragile language" - C, doesn't have these issues take to such extremes even on the most complex and projects thanks to good developer culture omnipresent emphasis on API compatibility, and good API design. Gtk+ for examples has huge list of dependencies, yet, not as single time my code failed to run properly because Gtk's own dependencies somehow influenced my code. This is not due to lack of data structures, objectized data is being used all around modern C. >It's currently 3 times faster than Python and the gap is only widening every year. No, the figure that you are giving is for synthetic benchmarks that do nothing more than arithmetics with primitive data types. I would like to see performance figures a tree sort or merge with complex data structures. The performance will suck equally. >You cannot have no tooling and no breaking changes at the same time. When you forego backward compatibility for the benefit of this approach, you do not resort to perversions with tooling to bring it back, resulting in a worse result.
- pluma 9y ago
  > No it isn't. It isn't because most other dependency managers don't allow dependencies to bring their own versions of other dependencies, instead you're stuck with version conflicts preventing you from upgrading to a recent version of library X because you're also using library Y and both libraries have a dependency on library Z (but the new release of library X uses an incompatible version of it). I was a Python developer in a previous life and in any Django project this would eventually happen and require you to either replace these unmaintained dependencies or ignore their version requirements and pray for the best (which was usually a gamble because semver wasn't a thing).
- realusername 9y ago
  > On my memory, large projects on PHP and Python falling into that category are all around the place You need at least a package manager in a large project. On PHP you will have composer, on Python you will have PIP. If your PHP project is web-based, you will likely have some tooling to setup your environment (SQL migrations, static pages...), that's also tooling. > Gtk+ for examples has huge list of dependencies, yet, not as single time my code failed to run properly because Gtk's own dependencies somehow influenced my code I've also been a GTK developer and I did had lots of issues with GTK incompatibilities between version, it's not a coincidence a lot of people moved to Qt recently, they did experience the same thing. You probably picked the worst library for backward compatibility in your example. Also GTK is not a language but a library so I don't see your point. > No, the figure that you are giving is for synthetic benchmarks that do nothing more than arithmetics with primitive data types. I would like to see performance figures a tree sort or merge with complex data structures. The performance will suck equally. I've never seen any test where Python has the same speed as Javascript, arithmetics, sorting or whatever else, it generally lags behind. All of that is due to the massive competition between JS engines and the massive amount of money people are throwing at it, Python can't match any of that, it's not 2003 anymore. > When you forego backward compatibility for the benefit of this approach, you do not resort to perversions with tooling to bring it back, resulting in a worse result. I don't really understand your point. In Javascript you can't control the client who executes your code. That's why you have to use some tooling to make sure it works even for the crappiest browser you support.

boobsbr 9y ago

Kinda makes you think the person you're replying too is not a JS developer and hasn't touched the ecosystem at all, and yet it's here spewing nonsense.

egeozcan 9y ago

> Most features are not backward compatible Important thing is: The VM (or the interpreter, or whatever runs your code) is almost always backward compatible. If you write code now, it keeps on running. JS code from the pages coded a decade ago runs just fine. I can't say the same for (from the top of my head) Android, for example.

realusername 9y ago
Ah yeah it's true, there's very few features that are actually removed from the browser. I just remember some kind of iframe version of window.alert (can't remember the name now) which got removed a few years ago but it wasn't used that much.
baybal2 9y ago
>JS code from the pages coded a decade ago runs just fine. Far from truth. A lot of breakage happen due to browser API security policy changes, obsolescence of browser APIs. In on case, I even saw a code failing because the behavior of mathematical operators with floats have changed over time. This is why there is little point for JS drafters being hellbent on backward compatibility to the absurdity (remember few pages long typeof null flamewar) >I didn't know about this. Do you have a source or explanation? (by the way, all numbers in JS are double-precision 64-bit format IEEE 754-2008 numbers so you mean they actually changed the operators?) As I understand, browsers' js engine, under some conditions, can provide more precision than what browsers were giving in nineties. That way if you vere reliant on if(1 - trickyFunction(0.000006464)) doSomething(), the condition will eval differently if function will return a value just a little bit bigger than 1.0000000000
- egeozcan 9y ago
  > In on case, I even saw a code failing because the behavior of mathematical operators with floats have changed over time I didn't know about this. Do you have a source or explanation? (by the way, all numbers in JS are double-precision 64-bit format IEEE 754-2008 numbers so you mean they actually changed the operators?) > A lot of breakage happen due to browser API security policy changes, obsolescence of browser APIs Non-standard features, yes. Standard features? Rarely (like WebSQL, opening HTML data URLs directly from code and so on). Standard features with wide adoption across browsers? I have just one case because of the recent CPU bugs. Standard features with wide community adoption? Never.

baybal2 9y ago

>Everything has tooling, I defy you to find a single language you can use in a medium-size project without any tooling, good luck, I don't know any. On my memory, large projects on PHP and Python falling into that category are all around the place >It's the same for any language. Yarn has a yarn.lock for this exact purpose, for other languages you will have [your language package manager].lock, it's the same. No it isn't. Heck, the prime example of a "fragile language" - C, doesn't have these issues take to such extremes even on the most complex and projects thanks to good developer culture omnipresent emphasis on API compatibility, and good API design. Gtk+ for examples has huge list of dependencies, yet, not as single time my code failed to run properly because Gtk's own dependencies somehow influenced my code. This is not due to lack of data structures, objectized data is being used all around modern C. >It's currently 3 times faster than Python and the gap is only widening every year. No, the figure that you are giving is for synthetic benchmarks that do nothing more than arithmetics with primitive data types. I would like to see performance figures a tree sort or merge with complex data structures. The performance will suck equally. >You cannot have no tooling and no breaking changes at the same time. When you forego backward compatibility for the benefit of this approach, you do not resort to perversions with tooling to bring it back, resulting in a worse result.

pluma 9y ago
> No it isn't. It isn't because most other dependency managers don't allow dependencies to bring their own versions of other dependencies, instead you're stuck with version conflicts preventing you from upgrading to a recent version of library X because you're also using library Y and both libraries have a dependency on library Z (but the new release of library X uses an incompatible version of it). I was a Python developer in a previous life and in any Django project this would eventually happen and require you to either replace these unmaintained dependencies or ignore their version requirements and pray for the best (which was usually a gamble because semver wasn't a thing).
realusername 9y ago
> On my memory, large projects on PHP and Python falling into that category are all around the place You need at least a package manager in a large project. On PHP you will have composer, on Python you will have PIP. If your PHP project is web-based, you will likely have some tooling to setup your environment (SQL migrations, static pages...), that's also tooling. > Gtk+ for examples has huge list of dependencies, yet, not as single time my code failed to run properly because Gtk's own dependencies somehow influenced my code I've also been a GTK developer and I did had lots of issues with GTK incompatibilities between version, it's not a coincidence a lot of people moved to Qt recently, they did experience the same thing. You probably picked the worst library for backward compatibility in your example. Also GTK is not a language but a library so I don't see your point. > No, the figure that you are giving is for synthetic benchmarks that do nothing more than arithmetics with primitive data types. I would like to see performance figures a tree sort or merge with complex data structures. The performance will suck equally. I've never seen any test where Python has the same speed as Javascript, arithmetics, sorting or whatever else, it generally lags behind. All of that is due to the massive competition between JS engines and the massive amount of money people are throwing at it, Python can't match any of that, it's not 2003 anymore. > When you forego backward compatibility for the benefit of this approach, you do not resort to perversions with tooling to bring it back, resulting in a worse result. I don't really understand your point. In Javascript you can't control the client who executes your code. That's why you have to use some tooling to make sure it works even for the crappiest browser you support.