Live data from Hacker News

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

news.ycombinator.com

171–180 of 303 posts

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

#171
post #110

Earlier quoted context omitted.

Maybe replace "shepherd" with "standard lib". Python has a pretty complete standard lib. Javascript is lacking it, and that vacuum encourages things like jquery. But then there are people who see jquery getting bloated, and they really just want a few features, so they write underscore and lodash. We've got no standard lib, so we have a continual ebb & flow of unstandard libs.

hundred percent agree with this. A standard lib bundled with all browsers would solve so much of the framework madness.

Not saying it's well architected, but the standard (and experimental) suite of types and events in JavaScript on modern browsers is comprehensive!

https://developer.mozilla.org/en-US/docs/Web/API

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

#172
A lot of comments here seem to suggest it's just because of people creating projects to get attention. I think this reason is massively overstated, and appeals to the unfortunate HN meme of disparaging other people's work to signal that the commenter is smarter than the herd.

However, I would suggest that we are now building applications at a level of complexity which has not previously existed on the web before (unless you include non-standard tech like Flash/Flex or Java Applets, which both had their shortcomings).

If you accept that some of the things which are being built actually unlock new possiblities in terms of user interface fidelity, and therefore has at least some purpose, then I would point out that the level of churn can be explained by the following:

1. JS has become very widely used very quickly, which means that there have been lots of hastily built things, which have been replaced by better things (and for every 'better thing' there are many alternatives which fell by the wayside), and a larger pool of people to build them.

2. It's easier than ever to build new tools (or any kind of app, for that matter), because the npm ecosystem makes it trivial to combine existing smaller pieces of code into new combinations.

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

#173
There is a high rate of change in fads, not in reality. What is actually worth learning and following has a normal change rate. Fads are governed by a vast community of hipsters who clearly prefer to spend time and effort on earning 15 minutes of celebrity with some library or tool than on more productive tasks like improving their own web site, working for customers or learning principled computer science and software engineering. Meanwhile, web standards like HTML, CSS and ECMAScript and web browsers evolve at a reasonable pace and in a saner way: doing more things and doing the same things in a nicer way. The traditional design attitude of figuring out how web standards and imposed technology allow to do what is needed and only then selecting tools and libraries that look useful is the main way to ignore fads.

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

#174

Earlier quoted context omitted.

To a large extent this is true because the javascript community is busy with the re-invention of all of computer history, only without applying all of the lessons learned. Activity does not equate quality.

Things re-invented in JS (and by most language communities as they evolve): - Build systems - Dependency management - Some form of code modularity and references between modules - Preprocessing/macros/templating - Source to source - DSL embedding - Compartmentalization of state (globals bad) - More advanced type systems - OO-ish systems - Forms of data flow - Message passing - Functional style (including limiting mut…

On the one hand, I really miss simply being able to use "Make" for builds (Damn you to HELL, Microsoft!).

On the other hand, I loathe the spam code that checked exceptions causes (alas MS/Anders/C# gets this right, and Java got it wrong)

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

#175

Earlier quoted context omitted.

>What's wrong with native apps? Because you really don't need a native application to look up the time the local Thai place is open or if the local independent movie theater has a showing tonight. Installing two native apps to do that is burdensome on consumers and producers

You don't need web applications to do that either. Simple HTML will do.

> Simple HTML will do.

It will, as a side effect, save 1G in RAM.

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

#176

Earlier quoted context omitted.

Give me a break. The entire internet and software landscape is changing and everyone is in a constant rush to stay current. You make it seem like it's some kind of concerted effort to insult the sensibilities of good, proper software engineers who know the right way to do things. Everyone is just trying to do the best they can with the incredibly complex stack of technologies in play today.

"The entire internet and software landscape is changing" Really? Is it Web 4.0 now? People are changing the stack because they don't know any better and trying to justify their salary. That's the bottom line. The rush to stay current is just bandwagon-hype.

I love you.

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

#177

Because nobody has yet invented a compelling way to write JavaScript applications, so people keep trying. We're still waiting for the Ruby on Rails of frontend development. I'm not saying Ruby on Rails is the best backend framework (I don't use it anymore), but when it came around everybody understood that it was getting something right. It popularized a new model for server-side web development that all other commun…

Plenty of people (including me) took one or two looks at RoR and dismissed it, too. I don't think it was the slam-dunk you're making it out to be. React seems to be doing pretty well these days, but it is too soon to say if it is going to dominate the field.

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

#178

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…

> The python API would likely be no slower and much easier to write and debug. But probably not for your qa engineer who most likely already (and possibly only) knows javascript.

QA? Do it in Perl please!

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

#179

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…

> default async is a terrible setting

Haskell's version of "everything is async" works wonderfully. It's JavaScript that is bad, not the concept.

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

#180

Because nobody has yet invented a compelling way to write JavaScript applications, so people keep trying. We're still waiting for the Ruby on Rails of frontend development. I'm not saying Ruby on Rails is the best backend framework (I don't use it anymore), but when it came around everybody understood that it was getting something right. It popularized a new model for server-side web development that all other commun…

I would say react is the way to write large data driven applications, but JavaScript, without a tool like Google closure, is not suitable for 100k lines of source code app that is being actively developed. Personally I am playing around with typescript and webstorm and that seems to me to be good enough.

The trouble is that it's very difficult for a single tool to meet the use cases of everyone who uses JS.
Post reply on HN