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.
Ask HN: Why is everything in JavaScript changing so fast?
171–180 of 303 posts
Re: Ask HN: Why is everything in JavaScript changing so fast?
#172However, 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?
#173Re: Ask HN: Why is everything in JavaScript changing so fast?
#174Earlier 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 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?
#175Earlier 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.
It will, as a side effect, save 1G in RAM.
Re: Ask HN: Why is everything in JavaScript changing so fast?
#176Earlier 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.
Re: Ask HN: Why is everything in JavaScript changing so fast?
#177Because 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…
Re: Ask HN: Why is everything in JavaScript changing so fast?
#178In 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.
Re: Ask HN: Why is everything in JavaScript changing so fast?
#179In 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…
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?
#180Because 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.