Live data from Hacker News

Ask HN: Why is everything in JavaScript changing so fast?

news.ycombinator.com

271–280 of 303 posts

Re: Ask HN: Why is everything in JavaScript changing so fast?

#271

Earlier quoted context omitted.

Compile time types are nice to have, if they stay out of my way (type inference, the ability to easily opt out for certain "tricky" code...) Types keep things (except for database column names or JSON import...) from blowing up the very first time you try to run it, rather than stopping the compile. That's useful, as far as it goes. (as long as it saves me more time not fixing a typo and rerunning than it does genera…

Type inference is horrible. Mostly because as soon as your project gets large, type inference eats inordinate amounts of time during compiling and indexing and developer experience degrades. Combine that with operator overloading and generics and it gets even worse. Right now I'm suffering through it with swift with a +100k LOC project. The obj-c equivalent compiles and indexes 5-10x faster. If you can make type infe…

Operator overloading is doubly evil :-)

FWIW, I mentioned that I think even the built it infix operators are a bad idea, rather than functions, such as variadic add(...), multiply(...), or(...), and(...). (subtract() and divide() really should only have 2 arguments, and not() just one)

Re: Ask HN: Why is everything in JavaScript changing so fast?

#272
post #265

In an industry without a guild / license / what have you, the incentives skew towards articles of proof. Articles of proof could be demo websites, screen shots, and open source libraries. Being the creator or top two contributor of a library is now worth so much more than being a small time contributor that the incentives are skewed towards everyone just making a new thing, always. It's their way to stand out. So why…

On the other hand, Go's type system is so bad that it nullifies all the benefits it brings to the table. I'd rather have no type system than Go's type system, but why even ponder that if I can have everything? With JS I can start out with dynamic types, then switch to static types if the need arises (typescript, flow), fully or partially. Oh, and both of those have really good generics btw. And we have async/await to…

Python has async/await now too (and it's considerably nicer than JS's version).

Re: Ask HN: Why is everything in JavaScript changing so fast?

#273

Earlier quoted context omitted.

Why use an OOP language when you can use an FP one? I must have missed the memo that proved that Java / C# / C++ / Simula 67 are the one true path to productivity. Async I/O is clumsy on the server side, though.

FP can still have types, like haskell. Typing is independent of OOP vs FP

Sorry. Generally, when I hear people complain about the lack of "types" in a dynamic language, I'm pretty sure what they mean is [static] "classes", so that "intellisense" (auto-complete, for non-MS/VS-bubble-land) works.

Then next, a hair-brained XML configuration scheme (with reflection) will be used to work around the inevitable deficiencies, which an IDE plug-in may or may not parse accurately.

Tragedy ensues. (Or hilarity, if I get to stand back while somebody else has to support the monster)

YMMV.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#274
post #166

Earlier quoted context omitted.

There's a certain amount of irony in mentioning "Worse is Better" in this context. People trying to use Javascript as a surrogate C++^H^H^H Java will be sorely disappointed. People trying to use Javascript as something that blends Scheme and Smalltalk will be using it as its creator intended. While this won't make the extreme purists happy, for many of us, Javascript is an acceptable Lisp. I have come to prefer Javas…

Yeah, it's very true that JS is much more of a Lisp than a curly-brace language, despite its syntax. But I think the reference is still fitting because JS is an absolutely terrible Lisp. :) And the story of JS interpreters, JITs, etc. in browsers (and not in browsers) matches the story of C compilers in the essay, just with changes in timing: C is therefore a language for which it is easy to write a decent compiler,…

Worse & Worserer: Windows and C++, which even more people run :-(

(with apologies to the Dumb and Dumber movies)

Re: Ask HN: Why is everything in JavaScript changing so fast?

#275
post #265

In an industry without a guild / license / what have you, the incentives skew towards articles of proof. Articles of proof could be demo websites, screen shots, and open source libraries. Being the creator or top two contributor of a library is now worth so much more than being a small time contributor that the incentives are skewed towards everyone just making a new thing, always. It's their way to stand out. So why…

On the other hand, Go's type system is so bad that it nullifies all the benefits it brings to the table. I'd rather have no type system than Go's type system, but why even ponder that if I can have everything? With JS I can start out with dynamic types, then switch to static types if the need arises (typescript, flow), fully or partially. Oh, and both of those have really good generics btw. And we have async/await to…

Ive never put the words together, but you've basically highlighted what I want:

Python (and its type system) + Go routines

Where can I find that!?

Re: Ask HN: Why is everything in JavaScript changing so fast?

#276
post #81

Is it because it lacks a shepherd? Perl has Larry Wall. Python has Guido van Rossum. PHP had Rasmus Lerdorf and later Andi Gutmans and Zeev Suraski (Zend). Ruby has Yukihiro Matsumoto, and Rails has David Heinemeier Hansson. JavaScript came from Brendan Eich, but it was like a work for hire, wasn't it? Microsoft and Netscape just kind of ran with it. Then I guess it did have a shepherd, the W3, and all the browsers f…

It's not necessary to have a single person in charge, but it helps to have a single entity that can push changes through. Mozilla added a lot of features that never went anywhere because IE lacked them. The W3C never standardized JavaScript, but eventually ECMA did. The stagnation was caused by competitive factors between browsers and standardization didn't change that.

Chronology: when I was at Netscape and still (apart from part-time help) the only person working on JS and the DOM and the rest of the browser embedding, we took JS to ECMA (now Ecma) in 1996. It was never brought to the W3C.

The IE stagnation came later, after IE4 which was innovative (because Microsoft wanted to embrace/extend/extinguish Netscape and the Web).

Almost everything we added to JS at Mozilla made its way into standards. Examples range from __proto__ to generators in ES6.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#277
post #86

Earlier quoted context omitted.

What do you mean by "deliberate"? It sounds like you are hinting at some kind of bad faith or at least perverse incentives but I can't tell what exactly.

There is no "bad faith". There are "diverging faiths". JavaScript frameworks as an analogy for life :)

It seems we agree. Each framework is deliberate, while the number of frameworks being higher than everyone agrees it should be is a side effect.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#278

My theory, which I think goes fairly against what others will say here, is that JavaScript/Node is the first truly post-internet environments to reach critical mass. By post-internet I mean they consider sharing and open source as foundational to the environment (as opposed to tacked on later, or merely supported). The "JavaScript standard library" (or lack thereof) is a clear example of this: NPM is the LARGEST coll…

"post-" usually means after, so I initially thought you were saying the internet is over. Maybe you could say "internet native" or something. I don't think it's true, by the way (the CPAN folks would have a word with you, just to mention one that comes to mind).

In response to your point, eventually, most of us who build software just want to use tools we know to get things done. There's a tremendous benefit to having few and highly trusted dependencies. Imagine civil engineering if every week there was a new flavor of concrete with different construction methods and structural properties.

Not too many people with a decade or more of development experience think that "downloading other people's random packages" is a fantastic or a confidence-inspiring idea. Ideally, those line-of-business CRUD apps that the modern world runs on should be write-and-forget, not rewritten continuously. This is why "churn" is a bad word to some. And yes, writing CRUD apps is pretty much solved, that is, it hasn't gotten that much more efficient in the last ten years if you look at the best tools.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#279
post #81

Earlier quoted context omitted.

It's not necessary to have a single person in charge, but it helps to have a single entity that can push changes through. Mozilla added a lot of features that never went anywhere because IE lacked them. The W3C never standardized JavaScript, but eventually ECMA did. The stagnation was caused by competitive factors between browsers and standardization didn't change that.

Chronology: when I was at Netscape and still (apart from part-time help) the only person working on JS and the DOM and the rest of the browser embedding, we took JS to ECMA (now Ecma) in 1996. It was never brought to the W3C. The IE stagnation came later, after IE4 which was innovative (because Microsoft wanted to embrace/extend/extinguish Netscape and the Web). Almost everything we added to JS at Mozilla made its wa…

Thanks for the clarification!

Re: Ask HN: Why is everything in JavaScript changing so fast?

#280

Earlier quoted context omitted.

> how most people actually want to write software. [citation needed] Honestly, Rails wasn't the first or last RAD platform and I don't think a randomly-selected subset of programmers who have used it would describe it as a shining beacon of light. JS frameworks are actually pretty diverse, and if you think the ecosystem is a bunch of MV* variants just waiting for something innovative to come along, with respect, you…

> [citation needed] Okay. The year is 2005. PHP5 was fresh out of the oven and most people were still on PHP4. From PHP's point of view, there's rumors of something happening in the Ruby community that will be big, and should be talked about [1]. Then Rails 1.0 drops at the end of the year. From this Slashdot thread [2] on the announcement you can gauge the contemporary reaction; comments detail the fact that Rails w…

I think we disagree on two points. First, I don't think the influence of RoR was as sweeping as you do. This is probably just a difference in perspective or preference.

Second, regardless of that, I think the JS ecosystem is well-enough explored that the chances that some single new idea or platform is going to dramatically change everything doesn't seem very likely to me. For reasons I've mentioned in my top-level comment on this page, I think diversity of the JS ecosystem is going to be with us for a while.

Post reply on HN