Open source JavaScript activity as measured by pull requests has doubled (!!) in the past year. It's more than the next two languages (Java and Python) combined.
Most of the top repositories on GitHub are JavaScript too: https://github.com/search?q=stars:%3E1&s=stars&type=Reposito...
Demand for JS developers is growing too, as websites become more complex, Node.js becomes more popular on the backend, and frameworks like React Native (more popular than any other iOS or Android library on github) start to pick up mobile developers.
JavaScript performance is also starting to be significantly better than the other scripting languages, e.g. https://www.quora.com/Is-JavaScript-v8-faster-than-Python . Not because of anything inherent about JavaScript, more that it's worth a lot of investment from big companies in JS performance.
Basically, it's not just the number of frameworks. Everything about JavaScript is taking off right now, and leading to a network effect where all the other aspects get boosted too. Sort of funny to have this happen twenty years after its invention.
Activity does not equate quality.
But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum for delivering features / products / tools to users.
It's always fair to criticize so that we ask ourselves the hard questions. So, it's also worth asking ourselves if we are staring too close to the wall when we try to paint other languages as backwards and therefore bad (or at least a bad choice). Just maybe, the language feature bullet list in your head (and corresponding subtleties of implementation) isn't the thing that matters most. Maybe the thing that really matters is something not as easy to codify as a language tool chain, like human consensus.
Also, it is false association to suggest that quantity != quality is somehow particular to JavaScript. Infinite monkeys will produce infinite crap no matter what brand typewriter you give them.
Because JavaScript was, and basically still is, the only option for client-side web development - that is to say, it was, and basically is, the only option for distributing sandboxed, instantly-updating executable code to users at any scale. Any other language requires me to convince users to download an application that runs with full privileges on their account. (For a while we also had Flash and Java, but then we realized that Flash and Java basically also imply full privileges, in practice, because their sandboxes don't work well.)
Therefore, JS got popular; therefore, people used it. This has very little to do with the quality of the language or its libraries. Note that I am not criticizing the quality any more than I'm praising it, just saying that it's irrelevant as long as it's good enough.
Basically the same thing happened with UNIX and C at a much smaller scale several decades ago, except it wasn't about client-side app development, it was about getting things to run on servers at all. UNIX isn't a fantastic OS. C isn't a fantastic language. But, in the words of Richard Gabriel's "The Rise of Worse is Better", "UNIX and C are the ultimate computer viruses."
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
JavaScript and the dynamic web the new ultimate computer viruses. But they grew much, much more quickly, and haven't had the benefit of the last forty-ish years to get decently good. UNIX and C in the middle of the UNIX wars were at least as much of a disaster.
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 Javascript to Java (or C#), but most of my coworkers still think in Java, so that's another issue :-)
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, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%-80% of what you want from an operating system and programming language. [...]
Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.
The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.
(with apologies to the Dumb and Dumber movies)
(I don't really do PHP, but I have a feeling that I would find the experience closer to JavaScript from talking to colleagues and reading about it).
This is a problem we should be HAPPY to have. Having libraries doing EXACTLY what we want, that's just missing docs, is better than the alternative I've found in many other languages : no libraries, so we have to do everything ourselves.
That said, the docs on (most of) the libraries I have used are generally pretty good.
* Prototype - excellent docs (but library since overshadowed by jQuery)
* jQuery - initially the docs were hard to follow, but they seem to have gotten better
* Angular - good enough docs, and plenty of books on the larger concepts of how things fit together
* moment.js - excellent docs
* validatejs - excellent docs
* Ramdajs - generally excellent docs, but I am less familiar with some of the FP concepts used in a few cases.
The quality on some of the jQuery and Angular plugins varies a bit, admittedly.
You're implying this happened to JS because of some merit. But it didn't, it was just sheer coincidence and bad luck (for most of us at least, including users).
Also, I disagree that users are suffering as a result, but that is a different discussion altogether.
I believe JS came here because it actually is the best language we have had in the web. It's so easy to throw shit arround, but let's be honest with ourselves, this isn't purely out of luck.
It's pretty much the textbook instance of a compromise between vendors of competing interests to further the common web. Despite this, it took a really, really long time -- almost ten years -- for JS to receive additional browser-implemented APIs that brought that platform's capability to what we know today and comparable to that of what we had with plugins -- and still, not every vendor supports every spec yet, making this "open web" no less subject to vendor pressures, despite being 'open' and 'neutral' [1].
Today, Javascript is sooo interwoven with the DOM in browsers that it is near impossible to separate them. Google planned to do this for Dart, but gave up. If they had done this and other browser vendors had followed, adding a third and forth and more languages would have been (relatively) easy, because the abstraction were in place. Then we would have seen a healthy competition.
There is asm.js. Maybe we will get a "web bytecode" at some point, but that will easily take a decade and more. The pressure is increasing, because our CPUs don't get exponentially more powerful anymore. And delivering apps via the web is still going strong.
Dart was never going to make it, and adding 3 or 4 VMs with their own GCs is even less plausible.
2. See https://github.com/WebAssembly for progress on what asm.js showed was possible: a 2nd, initially co-expressive with asm.js, eventually more expressive, binary syntax for the Web. It's happening now, this year and probably shipping experimentally in 1Q2017.
Writing "easily take a decade" out of ignorance just says to me you didn't even bother to use google!
Unfortunately there wasn't a good way for the other browsers to implement it. Or perhaps fortunately, depending on your point of view…
It is the only language we have had in the web (modulo some minor experiments). The only reason it's popular in the browser is because it's the only choice at all. The only reason it is used on the server is because some folks are familiar with it from using (overusing IMHO, but that's a different rant) it in the browser and are not familiar with the advantages of using any other language.
I've written this before, but sometimes in my most morose moment I like to imagine what the world might have been like had Brendan Eich been permitted to implement a Scheme instead. And I don't even like Scheme!
I believe that part of the reason is the ease of access to JS development. It allowed an inordinate amount of poorly trained devs to enter into the job market. Because you can quickly whip up fancy UIs and show them to unsuspecting non-techie types, you can quickly earn a reputation as a "computer whiz".
I think there were many de facto ways of doing things before this, none of which were perfect, but some of which followed better design principles.
If you look at software industries where security and stability is of utmost importance, you will not find these newer frameworks in use - nor the languages they use. I'm thinking life critical systems here.
Consider this: just because a language is easy to pick up doesn't mean it attracts "poorly trained devs". It just means it attracts more devs, because it is easier to get into it. Putting aside any value judgement of mass appeal, my experience suggests that the most important differences between a poorly-/un- trained dev and any other kind are time and practice. So, being easy to use is a much more powerful feature for a language / framework / platform than most.
Also, we should all be aspiring to use tools that enable us to quickly spin up a prototype UI that looks convincingly useful. I'm not sure why that's a knock against JS.
Also consider this: the languages / frameworks / platforms before the web, and before JS, were harder to use and relatively very discouraging to new users (this also sometimes goes for the communities associated with those languages / frameworks / platforms).
We all started from a place of ignorance as software developers, and many of us never would have left that place if it weren't for someone looking at us and seeing a computer whiz in the making.
I never said that JS was easy to use. I said it was easy to access. With JS, you don't really need an IDE, compiler, runtime etc. You need a browser, and a text editor and you can get started. It's unlike a lot of other languages in that way.
In some ways, I'd argue that languages like JavaScript are harder to use, or at least harder to use well. There is a reason that languages like Ada exist with very strong type systems. Granted, Ada is not a web development language, but I think my point still holds true since languages like TypeScript are making inroads in this arena.
I think spinning up "convincingly useful" UIs is part of the problem. First, in a lot of ways it's the wrong place to start for software design. It raises expectations and can create a contract in the minds of the client, customer, or user that this is what the software will do, and it will do it perfectly.
I'm not claiming that I (or any other programmer) started out knowing everything. But taking the time to learn, apprentice, and hone the craft of software development (the full cycle, not just writing code) is part of the game.
I think the attraction of a lot of the current web frameworks is the "whiz-bang" results you get, and it's my humble opinion that you should no more build software that way than you should a smartphone, bridge, or building. I think people need to have more respect for the software engineering field, follow best practices, and not throw out everything we've learned as each new Next Big Thing (TM) comes out.
I agree with this sentiment, with a few (rather large) caveats:
∙ Best practices yesterday may be legacy practices tomorrow.
∙ The Next Big Thing™ is usually hidden lower in the stack (in the above example it was cheaper commodity hardware and free-as-in-beer operating systems), and while it may not force throwing away everything, it can still prompt throwing away a heck of a lot.
So, yeah, there is a lot of churn in the JS ecosystem right now. It's inevitable that there will be some sort of shakeout and some projects will emerge as de-facto standards around things like declaring dependencies, build tools, etc. The same thing happens in every successful software ecosystem exploiting a new niche.
I'm not suggesting that the Javascript ecosystem is filled with awesome stuff, but sometimes quantity leads to quality.
https://www.amazon.com/Art-Fear-Observations-Rewards-Artmaki...
There is a parallel though: bad art is weeded out over time, the good stuff remains. In software it is quite similar, the good stuff has staying power, the bad stuff will be forgotten soon enough. The average half-life of a typical javascript framework is quite telling in this respect.
* Do you really want to write CSS without a pre-processor?
* Do you really want to control a webpage's state without JS models in the browser?
* Do you really want to update html with individual jquery calls?
* Do you really want to write websites _without_ using jquery? Keep in mind that jquery is only 10 years old.
I'm glad that we have an open market to exchange people's ideas. Yes, a lot of it is crap, and even among the highly adopted packages there will be problems. But that's the beauty of the market-- people can vote with their feet.
This article sums up how I feel: http://mrmrs.io/writing/2015/07/27/too-many-tools/
> "Four–fifths of everybody's work must be bad. But the remnant is worth the trouble for its own sake." - Rudyard Kipling in 1890
Yes. It has evolved to counter-balance those advances in hardware power, in order to provide a sub-par 2000 native desktop application experience in a 2016 browser sandbox.
>Maybe we're re-writing computer history
Maybe?
>but if that's the case then it's because we have to migrate everything to javascript and the wiser old timers want nothing to do with it.
Err, why do we "have to"?
And what's with the "old timers" / hot young JS developers dichotomy?
I wrote the phrase "wise old timers" with respect-- y'all truly have things to teach us. But it often feels that y'all just want to complain about how we're doing things wrong, rather than actually helping. I suspect that "old timers" is correct maybe 80% of the time, since the complainers are probably people who have years of non-JS experience and are disappointed that the new bootcampers haven't gone through their coming-of-age programming rituals. But I have a friend who is a member of the C++ master-race, so trust me, I know that gripes about browsers & JS can come from many kinds of people.
Not much of an argument. We already have 24/7 internet connected laptops, tablets and smartphones, which is were those browsers run in the first place anyway.
Perhaps we could, and I'm going on a limp here, just cut the middleman and run on the metal?
If the problem is discoverability/installation/security etc we could focus on app stores and sandboxes (which modern OSes also have both), instead of rewriting everything on the web.
>* But it often feels that y'all just want to complain about how we're doing things wrong, rather than actually helping.*
Well, you first stop someone from drowning and then you show them how to swim...
To this day, I maintain that if Microsoft hadn't neglected that essential aspect of the Windows ecosystem for decades, they would probably still dominate the personal computing industry.
Oh, you mean 'personal computing' in it's original sense, which encompasses mobile platforms as well, not just desktop computers.
Show me another way to write end-user applications that are cross platform, and then (if it existed prior to 1995, or even 2005) explain to me why your particular alternative didn't take over the world.
Heck, even standalone desktop and mobile apps are now being built with web technologies (react-native, Electron, etc.) rather than GUI frameworks like wxWidgets.
Not him, but yes, I absolutely do. Pre-processors mainly have the effect of forcing you to have a build tool workflow, and the nice thing about web design is that you don't need stuff like that.
It's reasonably "thin", but I can use variables to hold repeated style elements that get mixed in various selectors.
Well, it does, if you don't emulate the same effect with other means. But imho, needing modularity in CSS means (for most projects that are not gigantesque) that the CSS is too big anyway. It depends on what one does, specific web apps might need it. But normal web pages never.
Why?
What I really want is the whole browser to go away.
The obvious question is: what would you replace it with? Do you want to replace it all with native apps? Or do you think that this whole internet thing is overrated?
In pretty much every respect, native apps are better for the user than web apps. The person that benefits the most from web apps is the developer.
For example, web apps are often easier to discover, easier to update, easier to manage (since you only have one version in the wild you have to handle), easier to launch (especially for first-time users), easier to use from different platforms, more secure (debatable, but since the browser has huge companies working to keep it secure, and your native app that's just opening sockets doesn't, it probably is true), ...
There's pros and cons to both sides. Just framing the situation as "my side has these benefits, therefore there is no reason to consider your side" is not an honest discussion.
How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store.
> easier to update,
because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?
> easier to manage (since you only have one version in the wild you have to handle), Except when there are cache issues. Or when you have multiple servers and need to upgrade them without downtime. Not to mention all the stuff required to host your app needs to handle enough scale to load not just any potential server side data but also the entire ui, possibly every time someone loads it (opposite of the cache problem above). Must be easier though, I've never heard of any web apps being unavailable because the servers were overloaded.
> easier to launch (especially for first-time users), How is typing a or clicking a link easier than tapping/clicking an icon?
> easier to use from different platforms,
If your browser on your platform is supported. And you have the right version.
> more secure (debatable, but since the browser has huge companies working to keep it secure, and your native app that's just opening sockets doesn't, it probably is true)
This is a joke, right? Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps? Pretty much no web apps use local storage exclusively. So your attack surface is not "the browser", it's the browser, the network stack, the network itself (see: ddos on Dyn, Comodo/WoSign bullshittery to name a couple from the last month alone), your server host(s), your server os/stack, your server side app logic, your server side db/storage stack.. Do I need to go on?
Because when I come across a web app in a search engine, I can click it, use it instantly, evaluate it, and decide to stay or leave, all within seconds. No checking if the app I found supports my platform, no click-through to my native app store, no download and installation process, no delay, instant feedback.
> because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?
Not sure I follow. Are you asserting that native apps are easier to update than web apps?
> If your browser on your platform is supported. And you have the right version.
The combinations are smaller than the combinations of operating systems and phones one would have to worry about.
> This is a joke, right?
Is this a good way to have a productive conversation?
> Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps?
Do you think only web apps communicate with servers?
I've also gotten a pretty bad taste in my mouth about some companies pushing a native app down my throat. TripAdvisor would only show me the first three reviews on a place if I was browsing via mobile, as a way to push me to download the app. And now that they're on my android they sent me a couple of spammy notifications before I disabled them. I wanted to treat TripAdvisor like a website, not like an app that has access to all phone.
If a bank/credit union/etc doesn't have a native app in 2016, I doubt they have a web app that's usable on a phone either.
> A native app for each news site I read
Right, because RSS readers and aggregators aren't totally a thing.
> A native app for every social media site
Those literally exist today.
> A native app for all the map searches, directions, etc. we all use
You realise you don't need a new app for each search you want to do? I don't even understand this premise.
> Security updates? Nightmare
Right, because having half-baked web-apps with millions of user's personal data all stuck in a big fat juicy database in one spot, just waiting to be breached and spread like herpes in a brothel has worked out so fucking well.
Every major mobile platform and the two leading commercial desktop platforms have app store infrastructure which provide automatic updates of client-installed apps.
> Multi-OS support? forget about it.
Right, because no app ever has been developed cross platform, and every web app ever created works perfectly in every browser with zero effort from the developer.
> We'd all be back to a Windows monopoly.
Wat.
Edit: additionally, a number of the things you describe, i.e. news sites, aren't web-apps in the way most people think. They offer very limited if any interaction or functionality for the user except navigating to find/read other news content, and possibly leave feedback. Those sorts of things are what the web excels at, because they're essentially used for one-way content viewing.
Users also benefit. For instance, linux users can use the same web apps as windows users.
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
It will, as a side effect, save 1G in RAM.
Yes. The only things that are worth having one for are variables and that’s not enough to add the development overhead.
> Do you really want to control a webpage's state without JS models in the browser?
I prefer to avoid controlling a webpage’s state in the browser as much as possible.
> Do you really want to update html with individual jquery calls?
No, I want to update the DOM…
> Do you really want to write websites _without_ using jquery? Keep in mind that jquery is only 10 years old.
… without jQuery, yes, because it’s designed horribly.
These practices also happen to result in a website that is actually possible to develop and view on my computer with reasonable performance, because I’m one of those users nobody cares about who can’t afford the latest MacBook.
Now more and more JS abstractions are heaped upon the pile and we call it the best thing since sliced bread. No.
- 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 mutability)
- Forms of control flow
- Frameworks providing more magic
- Calls for less magic and more explicit control flow
- Exception handling good
- Explicit errors better
- Event loops
...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)
It's definitely frustrating to see. And it's also frustrating to see the vitriolic reactions to anyone who criticizes the current culture of the JavaScript community.
I use React and all of its associated tools and ecosystem, and while I find them productive and useful, the whole situation is a bigger mess than it needs to be. I don't think it's necessarily anyone's fault; I don't see a willful desire to ignore the hard-won computing knowledge we'e accumulated. It just seems as though the JS community's enthusiasm has, at least recently, has exceeded the rate at which good tooling can be developed.
I think that's changing, though. From what I've seen, in the past year there has been more of a push toward building mature, reliable, maintainable JS applications. I've also seen more interest in optimization. The Closure Compiler has been around for a long time, and at least in the Angular 2 community I've noticed jump in the number of people looking to use Closure and other tools like Rollup to optimize everything and deliver the smallest possible code bundle to the browser. And ES2015's statically analyzable modules go a long way toward making more optimization possible.
So I agree, things are a bit crazy. And I agree that activity does not equal quality. But there's a lot of activity, and some of it is of high quality. I can't guarantee that the high quality work that brings more of those lessons learned to the JS world will become popular, but I'm at least seeing a positive trend in that direction.
Everyone is just trying to do the best they can with the incredibly complex stack of technologies in play today.
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.
That seems like a bit of a reach.
The JS community at large isn't reinventing the wheel, just iterating on a wheel as it moves, if that makes sense.
These libraries were checked into Git because it was more convenient at the time and I hadn't set up a good build system, as they were non-critical side projects.
I know I'm not the only one who has done this in the past. I'd be curious to see GitHub stats that tried to account for this.
These stats prove the hype, not that it is good quality code, with good quality documentation, with a friendly and safe community, and a reliable archiving system for it's dependencies.
I have nothing against JS in particular, but there is a bit too much hype about it.
And then everyone started to build "rich" web applications (it is called differently every year), with the "best" tool existing. I personally see two major problems – usually cool startups who can afford using the bleeding edge will die soon (or will get enough money to completely rewrite it), so 'maintanence' in idiomatic way doesn't work here – life cycle is extremely small, and it reflects in the way libraries are written in JavaScript. Also, the barrier is low, and therefore we have a lot of complex websites built by novices, running in development mode in the actual production.
Community also is very "poisoned" with the idea that you _have_ to work in your evenings (contributing to OSS, writing your own or just playing with hot technologies), and therefore new stuff is baked extremely quickly. It is usually very low quality, and you have to cope a lot in order to make it work, and often you have to dive into source code, and it is considered as normal, which is quite sick from my point of view.
Also, it is truly "hype" community, which is super excited about what is hot now – and it means that today kings will be overthrown very soon (right now stuff like Cycle.js and Vue.js is gaining traction). Nobody wants to maintain their libraries – and very often you can see projects with a lot of stars completely abandoned.
Recently, Babel.js was defined as _defacto_ standard, and it basically started transpiling era, which is not going to end in the foreseeable future. It shakes the stability, and makes extremely easy to add new features (like stage-0), and people just used to unrealiable tools.
So, all of this works as a snowball, which only speeds up. People create more and more complex web applications, and also js is going into other fields (like microcontrollers, Node.js grows in popularity, React Native is super hot now). When it will stop? Nobody knows. Maybe WebAssembly after implementing will stop it (people will spread over competing technologies), maybe no.
To make a successful open-source project is not easy and is about balancing a range of factors, including balancing their work/life. Not everyone can do this, or wants to do this. I think rock stars earn their status.
Yeah, that's true, that they invest a lot of personal time in this stuff, and they do a very good job in balancing, but the problem is that people trust them in important questions like performance even despite the fact many of them don't know CS basics properly (like data structures, etc).
I don't want to say all of them are this way, there are some well-educated people who definitely know a lot and deserve all of this. But as it was mentioned earlier, a lot of them are just 22 years old hip guys who released something what became mainstream/were involved in it and became ambassadors.
I think this is part of the tradeoff that they excel at. There is a huge difference between perfecting and optimizing vs. shipping and growing an ecosystem.
I think that's mostly bunk. For every rockstar there's 100 equally talented individuals who will never get recognition because they were not in the right place at the right time.
Rockstars are incredibly lucky.
IMO, social media and blogosphere driven complex work cannot be deep, just confused.
Any kid with a new idea can have his ideas listened to. This means we don't get stuck.
I would claim that any technical undertaking without understood goals using a process whose main design feature is not efficiency but sluggishness is a pathological one.
A computer system is far more simpler than any countrys political system - it's tractable and optimal solutions can be found. Unless, of course, unless the design process is lost in confusion and bafflement.
I would claim a place where any kid is listened to is precisely the one where everyone will get stuck. If people spend more time reading blogs rather than on CS basics they cannot understand a great ideas because they are on the Kruger-Dunning level of skill development.
This is the only necessary component of stardom.
When something is actually good, it'll retain its popularity.
I'm not a huge fan of the "Javascript programmers are novices" myth. It's quite damaging.
Javascript is a kitchen-sink language these days in the ES6+ world. You've got the functional programming features... monads, functors, applicative and even immutable data structures are just a library. You have classes, interfaces, protocols and of course event-driven programming, prototypes, etc, etc, etc. It's not a small spec these days.
The point is that there are smart people who use the language to great effect. Enough with the "unwashed masses," story please.
Personally I'll take an ML or Lisp based language anyway... but thankfully I can have my cake and eat it too by compiling to Javascript.
There are novice programmers and many of them choose Javascript is more accurate. The aforementioned assertion is used as a pejorative by programmers from other languages who think, perhaps rightfully so, that Javascript is inferior to their language of choice. That doesn't make Javascript programmers as a whole inferior despite what such a blanket statement implies.
And this is not a single story; I've also interviewed some people and for some reason my experience is that JS has very low entry barrier.
Yes, with tail recursion we'll have almost full FP (only pattern matching is missing), but it doesn't mean that every novice will go and study them right after landing – in fact, the opposite, because there are much more tutorials about OOP JS.
I'm a Python guy who's working in Java at the moment. I don't particularly care for JS or frontend work, and I make no bones about it. But if someone were saying all this about the Python or Java communities, I'd be asking for evidence. And, frankly, I'd be pissed. So I think we should hold ourselves to similar standards -- don't just shit on a community because that's how you feel. Provide cases. And possibly even advice on how to improve!
Except COBOL started in 1959, not 2009.
https://github.com/angular/angular.js/releases?after=v1.0.4
...
And I actually prefer ng-1 to the transpiling mess that is ng-2, as well as preferring to use functional composition rather than pseudo-static classes for the controller logic.
JS development will probably go on like if nothing changed, but people that don't like it will be able to opt-out.
If WebAssembly takes too long, I can see JS compilers getting very good, but it's looming availability is discouraging that.
Because having an extra compile step or language to learn is inconvenient no matter what you target.
> If WebAssembly takes too long, I can see JS compilers getting very good, but it's looming availability is discouraging that.
I haven’t seen any of this.
For an environment that's as dynamic and open as Javascript, my POV is that one should be able to dive into library source code -- but that changes resulting from this should be an unusual circumstance, having to do with edge cases. If the normal situation is that you are always doing this, and it is always is flat-out basic debugging, then this is messed up.
The ability to dive into and debug everyone's source code should be considered a blessing. It's a great way to learn coding style and programming! It's one thing that was great about working in Smalltalk. However, the need to do so just to fix library bugs should be viewed as a symptom!
I found the Tessel (https://tessel.io/), but its hardly a microcontroller - its a MIPS SoC.
It looks like the Espurino is more of a traditional microcontroller. But the unit cost is high - $40!
Is anyone using JS on a microcontroller in a high volume product?
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 is this more prevalent in JavaScript? Front end inherently has more new comers. Long time hackers or cs grads feel less of a need to prove themselves making free software?
I think it's natural that the web programmers would understand web self promotion better than other languages. Guess who's better at Twitter? The js people! Why? They were writing the web to begin with!
I wish it would stop. Our qa engineer is writing web driver tests in JavaScript and I don't understand why! There's nothing about testing that NEEDS to be async! The python API would likely be no slower and much easier to write and debug.
Sane defaults are an important part of tech, and default async is a terrible setting. Python sync is easier, and Go routine concurrency is easier. Always on async just seems like a terrible default. For speed I'd do Go, and for all else Python.
And we have async/await too now, which means async code can also look almost the same as sync code. So I would still choose JS over both Python and Go (at least for that particular use case). mypy still has long ways to go before its anywhere near TS or Flow.
Python (and its type system) + Go routines
Where can I find that!?
In theory, python is better (mypy, pypy, async/await). In practice most libs don't use asyncio (in node everything does and can be auto-promisified), can't run on pypy (in node everything runs with the fast JIT optimizing things) and the typechecker is not mature enough to express most things (unlike TS/Flow).
If the app you're testing is messy, some of the test code will have to be injected into the browser by webdriver (so obligatory Javascript, and oblygatory async for getting the results back...) and some (hopefully most!) will run outside, in the test-runner, so JS ends to be the only sane option if you don't want to write "Python with strings of JS sprinkled around".
Also, webdriver itself is a mess with a horrible API forcefully riding another bigger mess (the browser adapters and browser itself), riding a top another mess (your app, however non-messy you imagine it to be, it's still a soup of crap running though the bowels of the browser)... so no "clean" solution here even if you're using Python.
Probably the way out of "webdriver testing hell" is to use a frontend framework with good testing support and write good front-end unit-tests: but they will obviously be Javascript :)
It's not fully polished yet, especially error reporting is a bit ugly, but it works and supports most of the WebDriver API.
I'm using it more for automation than testing but it could definitely be used for QA.
I'll admit im not sure.
As far as I'm concerned, jQuery & lodash are part of the "standard library". Certainly there are cases where one or the other isn't needed for a particularly application. But if you're doing anything with the DOM, or doing anything more complex than simple if/then callbacks, you're either using them or you're reimplementing them bit by bit.
Certainly jquery has some... warts... but I haven't seen any project emerge that's succeeded at being a cleaned up replacement. And jquery 3.0 looks like it's trying to forge ahead in that direction itself.
(Still hate jquery's inconsistent ajax callback signatures. sigh.)
Lodash looks nice, though, in that its partial function application mechanisms seem a bit more flexible than curry (only) - e.g. - I want to make a function with 0-arity, and bind it to an event handler, which Ramda won't do.
Haskell's version of "everything is async" works wonderfully. It's JavaScript that is bad, not the concept.
But probably not for your qa engineer who most likely already (and possibly only) knows javascript.
One language is all we need? Who needs Assembler or C or LISP or HTML or CSS or Bash Script or Python or Perl??? WHO NEEDS THAT?
SINGLE STACK!! /s
For example, I'm working (part time) on a relatively simple backend server for a nonprofit with a tiny budget and short deadlines. I know I can do it cheap and fast in Python, and it will work "ok". Go would be better, and I'd like to learn it, but I'm uncertain I could pull it off in time.
EDIT: Then again, it looks like I could realistically learn enough Go for this project in a weekend. Only problem is there could be data analysis, I know good libs in Python, don't know how hard that would be in Go.
It depends really, there is no single true language (except LISP) to solve all problems in the entire stack.
My main problem with LISP is that I stopped liking Python after learning it.
[End] Sarcasm :-)
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 followed its standard, except the one that had 90% of the market. At long last, in the past few years, market share has passed to companies that are much more willing to follow open standards.
But at the same time, the user base is huge, a churning mass of millions of programmers of every level of ability, and each one of them can now publish their framework on Github. Plus there are several large web companies that are competing with each other.
Thankfully at least the language itself has a single standards track. Cross-browser agreement isn't perfect, but it's much better than it used to be. It's just that we don't have a standard library, like Perl's CPAN. Instead we have NPM.
I wasn't paying enough attention when Perl and these other languages developed, so I don't know for sure why they're different, or even if they were that different at this stage. Even they have their different web frameworks to this day.
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.
In my opinion, we need to realize that webapps are not documents, and document-oriented HTML is the wrong tool. I don't think things will get better until we start looking at webapps as essentially drawing on the screen, like native UI APIs. I think we need a standardized virtual machine, like a lightweight JVM (or, better, a heavyweight Lua), which would allow people to use whatever language they prefer, as long as it can compile onto the instruction set. Static-type people can use a statically-typed language, and dynamic types can use dynamically-typed languages. Make an instruction set that maps well onto native CPU instructions, and provide well-thought out input and drawing primitives. We essentially need a PostScript for apps.
Security is doable because BrowserVM does not need to do everything. It isn't generable purpose like the JVM, it is an embedded VM like Lua. Lua has great security, as far as I am aware. I expect that having a secure VM is no more difficult than having a secure ECMAScript implementation.
I think we want low-level execution primitives (i.e. assembly), which pretty much forces a VM, because it gives people flexibility to use whatever language they want. However, even the minimum of keeping JavaScript and having the page be a large canvas with (fast) drawing primitives would sufficient. Writing windowing systems and UI toolkits is a solved problem. I think the browser should, at minimum, provide primitives for drawing widgets, so that webapps can take advantage of OS-native widgets. A well-designed toolkit, though, would be handy. And here we have a number of examples. Qt is very well-designed and a pleasure to use. Cocoa is a little clunky, but effective. Even Java/Swing was fine (aside from horrid aesthetics). We know that Microsoft-style MFC is a bad idea, the Win32 callback idea is clunky, and Android is a mess. In particular, a constraints-style system seems to be clunky. It was clunky in Motif, clunky in Android, and even Apple's version doesn't seem all that great. Constraints seems to suffer from the same problem of HTML: describing the system is clunkier than just telling the system what to do. Hence, Qt and Swing's layouts are a lot easier to reason about.
Against this point: Few languages are used for what they were designed for. Java was designed as a control language for "smart" TVs. PHP was designed for making personal homepages a little bit reactive. JS was designed for making client side pages dynamic.
And now all three are being used as server software.
To be fair, a lot of languages compile to Javascript. Do we really need a second standard?
This sounds like a cool idea! What primitives would you suggest?
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 communities started to follow and improve. When it came out, most developers who were already working with the web could see that it would be very useful, it solved real-world problems they had, it just made sense.
This is much less clear with JavaScript frameworks. They usually have a tough learning curve and the benefits are not always coming as expected. So people keep trying to find a model that works well.
The GP post has a point. Almost every MV* JS framework starts from scratch because they all believe their slight variation of the paradigm is better than everyone else's, but the greater scheme of things they are more similar than different. When one comes out with a framework that in earnest changes how JS development is done -- and achieves some staying power -- things will be different from the myriad of near-equivalent-but-totally-incompatible choices.
[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 just aren't familiar with what's out there.
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 was breath of fresh air from the configuration-heavy Java frameworks of the day -- represented by Struts [3], but others weren't much different in this regard, as these books from 2002 and 2004 about alternatives to Struts show [4][5]. Several ASP developers, detail their positive experiences in switching their web development to Rails [6][7][8]. The PHP world is forever changed -- by 2006, frameworks inspired by Rails abound [9]. "Ruby on Rails" becomes a popular phrase, some frameworks borrow the naming scheme along with the ideas: "Groovy on Grails" [10] tries to bring Rails' ideas to the Java world, "PHP on Trax" (formerly "PHP on Rails" [9]), "ColdFusion on Wheels" [11].
I'd say Rails made quite the splash.
[1] https://blog.phpdeveloper.org/2005/12/31/25/ [2] https://developers.slashdot.org/story/05/12/14/0034219/ruby-... [3] http://weblog.rubyonrails.org/2005/2/22/comparing-struts-to-... [4] https://www.safaribooksonline.com/library/view/programming-j... [5] https://www.safaribooksonline.com/library/view/programming-j... [6] http://weblog.rubyonrails.org/2005/6/28/asp-net-vs-rails-ana... [7] http://weblog.rubyonrails.org/2005/12/20/neters-tell-scoble-... [8] http://weblog.rubyonrails.org/2005/7/5/not-knowing-where-it-... [9] https://h3rald.com/articles/rails-inspired-php-frameworks/ [10] http://grails.1312388.n4.nabble.com/Groovy-on-Rails-is-no-mo... [11] http://cfwheels.org/blog/how-oo-almost-destroyed-business/
The source you quote says "Groovy on Rails", which was the official name until it was contracted to "Grails" due to the insistence of the Rails crowd that "on Rails" not be used in any other product names. The "Groovy on Grails" phrase you wrote was a later unofficial but intended mispronunciation of the earlier name put out by the Grails crowd to make it sound like "Ruby on Rails" as a snipe at the Rails crowd. To those of us who thought Groovy would make a good language outside of its use in Grails, the mispronunciation made it sound like someone in the Grails crowd thought Groovy's only use was for scripting Grails.
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.
Well, there are the people who have moved on to React and are raving about it, and then there are the really hip people who have moved on to Elm from React and are raving about that: http://elm-lang.org/
The stuff coming down the pipe (mainly modules, but a lot of ES2017) is really going to get the language to the level where it's going to be natively capable of even supporting a framework on the level of Rails.
As far as I know (GitHub is down, cannot confirm) Sails is still running Express 3 (the maintainers are supposedly upgrading to 5), has a variety of other major issues with respect to its ORM, Waterline, and is a bit lacking on the "contemporary best practices" front. Long story short, it's broadly (perhaps unfairly, perhaps not) considered dead or dying.
There aren't any viable Rails alternatives for Node. (Flask, Sinatra, on the other hand? — sure. You'll have no trouble finding a good micro-framework.)
ThinkJS, Adonis and Strapi are the only entries I've seen in the Rails/Laravel/Django space, but they all have problems too -- to wit, ThinkJS recommended hashing passwords with MD5 (!!!) on their front page until quite recently, Adonis is aggressively NIH, and Strapi uses Waterline, which is (by many accounts) bad at just about everything.
There's also Nodal, which I've heard good things about, but it's limited to APIs with Postgres.
https://news.ycombinator.com/item?id=10821986
http://thinkjs.org http://adonisjs.com http://strapi.io http://nodaljs.com
Even looking back about 20 years, how many companies where making CPUs? How many different architectures where there? How many companies where making PC clones?
Remember
RISC is going to change everything - Hackers
This is natural the world isn't ending
The ARM architecture is RISC. And mostly every phone/tablet/wearable(even stuff like your TV) has one of those.
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.
What's being disparaged is bending web technology to unsuitable purposes instead of adopting something better, not individual projects that, ignoring the often insufferable hype and smugness, are often technically clever, as good as a bad premise and a bad purpose allow.
"Bending web technology to unsuitable purposes"... This could mean anything, it only depends on what specific orthodoxy you're implying.
Good vs. Bad. Immature vs. Mature.
The world is actually a colorful place if you open your mind and heart just a little bit!
I wonder how much of that shift is also just perception within a certain bubble/echo chamber, though. There's certainly a trend in online forums and startups to ask applicants for their GH profile, but I suspect this is one of those things that some employers are doing because they think everyone else is. Are those employers really then reviewing all of those profiles to see which include projects where an applicant really made a meaningful contribution and which are just token updates or yet another ad hoc, informally-specified, bug-ridden, slow implementation of half of someone else's popular and established work?
The only thing I know for sure about that sort of policy is that it would immediately rule out most of the best developers I've ever worked with. Most of those people are busy building working projects for their businesses/clients/employers during work hours, and then having a life at other times. Some do contribute back to OSS projects or help answering questions on online forums as well, but not as a resume-building exercise, and it's rarely where you'll find the best indications of what they are capable of building.
Every framework has a "sponsor". Every strong "sponsor" either has a vested interest in the web, or, a vested interest in some other platform with which the web competes.
The importance and power of the web are obvious. So, it is a dance. "Embrace, extend and extinguish". And, hop, here we go again.
I think it based on two factors:
1. the size of the community, JavaScript popularity is huge, it's probably the biggest programming community in the world, even the not so popular frameworks have a bigger community then the biggest frameworks in other popular languages (as a not at all accurate measurement, see vue.js and Python's django github stars/followers).
If you look at js frameworks/methodologies/libraries compared to the sum of the other languages' frameworks then the pace of change in Javascript compared to how many people use it is not as bad.
I had a similar experience with Java when it was the king of the web frameworks - JSP, JSX, JSF, Spring MVC, Struts, Stripe, Wicket and a dozen others.
Java was big enough to contain all of these frameworks, and it was big enough for people to support new ideas rather then iterate on existing ones.
I'm not familiar with C/C++ enough, but I think it has a similar amount of change to Java (which is somewhat less the JS)
2. the other big factor is how decentralized it is - JS is extremely decentralized, there are tons of big organizations contributing to it's advancement, to frameworks even building their own compilers (all the browsers).
Java is very similar in this regard, even in their governing model (a collection of companies that decide on standards together, though Java has drifted from that model with Oracle's lead lately).
C# is the opposite, it's one of the biggest languages but doesn't have a lot of change in it - everything is dictated by the central authority (Microsoft) and competing frameworks that don't get popular enough.
There are other factors of course, but I think most of those can be seen in other languages with less change, and are less relevant overall.
As you walk, you realise that each of them uses selection of screws and chisels and screws and wheels, and types of wood and door handles and all of them are somehow different. Not because they have to be, but because they were acquired independently by each worker. You come with an idea that if you standardise on some set of commonly used wheels and handles and chisels. This means you will need less of them, it will be easier for each worker to acquire, reuse and combine them, less time spend relearning different tools and a lot more other benefits. Once you did that, you may realise that the things built on top of that - like drawers, doors, covers - can benefit from the same standardisation. And so you do and keep improving your factory. Notice however that such idea would never come from single worker.
So JS is stuck at being early-stage factory. Main thing that it lacks is a boss that looks at it and improves it. Any proposed change has to gather momentum, convince some committee and even than it takes years to push it. It takes so much effort that most of the time anyone who tries just gives up. Where in other languages its enough to send complain email and propose a solution to one mailing list to get someone involved and get proposed change deployed in the next release a month later, you can't do it with js. For the same reason there is nobody to make a sweeping change and wipe this disaster from earth. Too much politics involved. So everyone hack his way around it, and hacks are not very maintainable, so you'll need to redo them on next project, but very differently. Making any two projects incompatible and hard to build one on top of another.
Java had its Sun, Python had BDFL Guido, JS has no such thing.
For JavaScript the TC39 is responsible for its improvement and standardisation. Thats were ES6 was developed. ES2016 aka ES6 took a fair amount of time, but the TC39 switched to "rolling releases". ES2017 aka ES 7 is already in the works and is going to be released 2017.
There's nothing quite like this anywhere else in tech, as most platforms are dominated by a single vendor. Imagine what Windows development would be like if, in addition to the need for backwards compatibility, there were three or four competing vendors of Windows, each with different feature sets and bugs.
Second, tools and libraries can overcome many of these problems, but these fixes come with costs, including library maintenance, cognitive overhead, security risks, complex build and deployment processes, and retraining and hiring issues. Because JavaScript is used across many industries and teams of all sizes, what is perfect for one may be completely inappropriate for another. Many projects, like GWT, meet the needs of the environments in which they were designed, while being so much a product of those environments that they become anti-productive elsewhere. So we have a very diverse set of tools on top of a very messy and relatively old set of underlying technologies.
Finally, many new programmers come into this incredibly diverse, sometimes frustrating, environment every year. It is an environment that encourages open-source contribution. It's no surprise that many new tools and libraries are released every year, and some of them gain adoption.
Relatively recently the standardisation, improvement of the language itself, real origin policy, common frameworks and finally npm released whatever was holding it back. It shot out from the rubber band and it's trying to catch up in months where other languages had years to find the way. You may notice that even though a lot is changing, not much is really new. Async existed before, so did dynamic languages, so did MVC, so did immediate mode UI, so did many other things. Js is now going through all of those ideas quickly because the path is known and clear. It will slow down though. There's only so many paradigms that we know. At some point people will run out of easy ideas and will have to start slow experimentation just like all the others.
Compare it to say, creating a new operating system. Sure the world could benefit from a better OS, so why not make one? The perceived benefit is small (why do this when Linux exists) and the cost is large (it's hard and you need a lot of knowledge).
Also a lot of half baked ideas. The number of js writers is huge but on average very inexperienced compared to other languages.
JS used to be a horrible ecosystem where different browsers behaved differently, the language itself had various pitfalls and most code was written in classical script kiddie style. This has been changing for the better for a long time in small steps, but frankly something has always sucked, warranting the next evolution.
The second point is politics: JS is huge these days, and there's still a lot of room for improvement. Everyone wants to be the company behind the de facto standard library for web apps.
This is appropriate because websites and web apps are more complicated than ever before, and face the same challenges that traditional enterprise software faces: large codebases that stay around for a long time and need to be maintained and refactored, integration with various APIs, asynchronous communication, separation of concerns, separation of model and view, business logic, test coverage, development of different parts of the application by different parts of the engineering team, etc.
At some point, the benefits a framework provides outweigh the time it takes to adopt and learn the framework. A framework provides an overall way of doing things that gives structure to the project and makes a lot of the challenges I mentioned easier to deal with. Frameworks significantly reduce the number of "how do I implement this feature?" questions that are bound to arise, by providing a standardized way of doing things. They make it easier for teams to collaborate, because the codebase is relatively consistent and engineers aren't constantly dealing with other team members' idiosyncratic code. (Yes, that means there is less room for individual creativity and expression, and it makes programmers interchangeable to some extent. Welcome to the world of business.)
So, why are there so many more JavaScript frameworks than Java frameworks? I suspect it has to do with the low barrier to entry of programming in JavaScript as compared to Java. I also think that dissatisfaction with whatever frameworks are current is a major driver behind the creation of new frameworks. (I suspect that a lot of the dissatisfaction with the current frameworks is misdirected and is really due to the nature of JavaScript as a language, and TypeScript is an example of an explicit reaction to that).
Another reason for the proliferation of frameworks is that the playing field keeps changing. Most recently, it has been smartphones and social media that have revolutionized the way people use the web. Before that, it was streaming video and "Web 2.0." Whatever the next big thing is, I'm sure it will inspire a new flurry of new web development frameworks.
In comparison, java, PHP have undergone some more than welcome mutations in terms of syntax clarity. Evolution in JS is made by adding features in frameworks, not in the core definition of the language.
You could see JS as the assembly language of the browser and all the frameworks as some C/fortran/C# that translates into JS.
The problem is the web would look definitively balkanized/ghettoed between old and new computers if you made a non backward compatible change of JS ...
JS is the most ducked taped language of the landscape of computers. And it is leaking memory, performance, abstraction from everywhere.
Angular 1 has been released in 2010 and Angular 2 in 2016. Obviously, if you started to learn Angular 1 last year it can be frustrating (specially with Angular, it's not the easiest framework to learn out there [1] [2] ). But I would say the majority of Angular developers has used it for 3 or 4 years now and most of them probably enjoy to have the chance to learn a new modern framework that fixes the design issues of the first version.
To generalize: The front-end world is surely overwhelming for the new comers (but is it not the same in all the other fields of programming?). However, after some years into it, you realize that you have mostly sticked to the same tools for years. [3]
[1] https://www.bennadel.com/resources/uploads/2013/feelings_abo...
[2] https://i.imgur.com/5rJH3co.png
[3] https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19...
Let's assume he wants the skills/tools to still be relevant in 1-2 years time in a sizable percentage of the job market (noticed that many startups don't like people with web experience that isn't in React/Angular/Node).
While the JavaScript ecosystem does move insanely fast a lot of consulting companies need to have people with similar skill levels in a framework/etc. Which means you can't just switch frameworks every year (You can, however, create smaller teams with new technologies, so if a few of the guys learned React you can just make a React team with them as a base.
A big misconception I've seen is that a lot of JavaScript stuff disappears after a couple of years, while in reality a lot of Consulting companies are still recruiting people for jQuery positions (In my country, might be different in the US).
Sure, the new startups who are using all the newest coolness maybe won't touch jQuery and similar technologies with a 10 foot pole. That doesn't mean those technologies disappear.
It depends on your goals as a person. Personally I enjoy chasing the newest thing, learning is fun. Maybe when I become more jaded at re-learning stuff every year I'll move from that kind of ecosystem.
All in all, the advice I wish I could've told myself years ago is to invest a bit less time learning frameworks in depth and a bit more time learning JavaScript. JavaScript has a lot of pitfalls, but if you learn to navigate around those you are left with a very fun and powerful language. And most importantly, that knowledge is still gonna be relevant 3 years from now even if you are switching frameworks.
https://github.com/airbnb/hypernova
http://thenewstack.io/netflix-uses-node-js-power-user-interf...
> if I'm server side and using something dynamic, I might as well
> use something nicer like ruby or python.
The code is pretty much identical between Ruby, Python, and Javascript once you have a yield/await abstraction in the latter.
A) Types are low level
B) C++ and C are the only competition to JavaScript
C) Not having to worry about types makes you faster or in any way better
A) is simply refuted by looking at java or SQL. SQL is a very high-level language compared to other stuff, yet it's heavily typed simply to ensure that data is either valid or the query fails (SQL Injection is still valid data in this case)
B) Take a look at Go. It's blazing fast. It beats Node.js in all benchmarks but Regex matching -> https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
Furthermore, Go is statically linked which means deploying to production is a simple scp operation to drop the binary.
Lastly, Go is opinionated on how you write programs, you will write programs that are scalable simply because of how simple goroutines are, using channels you can utilize asynchronous execution as you would in node.js but also utilize all available cores without having to think about threads or synchronization. Just pipe data through the channel!
C) Is a red herring, depending on who you ask it's either opinion or static typing being "better". http://danluu.com/empirical-pl/
Some studies indicate that it does not matter, some indicate faster development but more bugs for no types and others indicate less bugs and slightly longer development for types.
IMO Types are good. I want to worry about the types because when I receive user input I can be sure that once parsed it's 100% an int or a float or it fits in a certain struct. For the same reason I think relational databases are better than document stores, they ensure that my data is valid.
I don't have to write as much validation logic. It is sufficient to know that my function has been passed an int-type, I don't have to check if it's nil or a string.
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 generating stupid cluttered code)
We have bigger problems (not that JS really addresses them, either).
Mutable data, cyclic update graphs and temporal coupling. (at least JS makes it easier to do FP type programming and to freeze objects to force immutability if you need to). This is a paradigm change we probably won't see until after most of us raised in the C/Algol era are dead, sadly.
Pet peeve: infix operators, and precedence rules. I have seen this bite badly in subtle ways, but it's a sacred cow of computing that you MUST have algebraic expressions. Lisp had it right - parens first, now you are trained.
Now that we have effective garbage collection, can we please STOP writing (thinking) in Algol/Simula 67 dressed up with curly braces??? (which really isn't that much higher level than COBOL/CICS, especially when you look at most Java dreck)
If you can make type inference scale, then I would be all for it. If I'm restricted to a small LoC count, might as well use a dynamic language.
Static typing is a scalable tool. It lets me avoid an entire category of bugs and unit tests. It make refactors easier as I just have to change my thing and then fix all of the obvious compile errors once. It helps me define parts of API contracts in code vs documentation and unit testing. And when a project gets large, the automated nature of static typing helps a lot!
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)
If the compiler can safely infer a type, it should do it, that's a no-brainer, modern compilers are very capable of doing just that. This is why I like languages like Rust or Go.
For FP to some extend, I imagine Rust would be nice since mutability is opt-in rather than opt-out.
Cyclic Graphs are always complicated, they're hard, some languages just do the hard part easier while others just gnaw their teeth out.
Also agreed on LISP, LISP is probably the only good language ever, it becomes what you need it to be, if you want it's purely functional and in the next line it's object oriented.
Modern Compilers will probably coerce languages into a superposition of types, tho there will still be two sides to it, some people will always prefer explicit (as in: type is forced and checked) typing and some will prefer implicit (as in: type is fluid) typing.
SELECT *string* foo, *string* bar FROM banana A INNER JOIN beer B ON *int* B.id = *int* A.id
My problem with Go and other languages is that you have to be verbose like str = string = "string"; Where the compiler could probably figure out it's a string because of the quotes. And use a default numeric type when dealing with numbers. A compiled language also has the advantage that the compiler can thoroughly analyze the program, optimize and chose the optimal types if they are not explicitly set. My biggest issue though is the inferior module system compared to NodeJS (commonJS) module system that makes it possible to not write complexed code, because it's lexically scoped and do not have hidden globals.
I'm aware that an imperative low level language that can talk directly to the hardware will beat NodeJS and JavaScript in performance. But for the most part I'm willing to sacrifice that for increased productivity and simplicity. What do you think about languages that compile to JavaScript ? And do you think adding types to JavaScript would make it more simple ?
Which completely misses the point, this is called a file system btw, but a SQL Databases is designed from the ground up to have a validation schema.
You simply cannot put data in a SQL database that is not conform to the schema on which the table is defined. You can't simply put a string into an int column but this also means that any data you may read from this column will always be an int no matter what.
It means that if your transaction completes, including large scale database upgrades, at no point where types violated and you can be sure that all data is valid (or deleted because you forgot the WHERE clause)
>In ES6 you can now go very low level and deal with raw bit buffers.
I doubt you can write to registers and manipulate memory allocation, that is actually low level.
Manipulating bits is something every turing machine emulator can do.
>My problem with Go and other languages is that you have to be verbose like str = string = "string";
Which shows me that you haven't bothered to actually look into any statically typed language because I know of no common language that uses this syntax.
Go actually infers the type if possible, you simply write `str := "string"` or `var str = "string"` and go will use the correct type.
You can do this even with complex objects no problem. You only need to define the type if it's non-obvious, like you want to use an interface but the assignment uses the raw type, but this is something now compiler can do (it would be guess work)
Furthermore, there is no sacrifice in productivity, actually the opposite.
You don't have to wonder if the parameters you receive will have the correct type. If your function signature is `func (int) int` you can only ever receive an integer and you can only ever return an integer.
>NodeJS (commonJS) module system that makes it possible to not write complexed code, because it's lexically scoped and do not have hidden globals.
Go actually has a very neat module system. It's rather simple; all uppercase fields and funcs are exported, everything else is private.
The architecture of the standard library in Go and the language itself discourage globals and encourage default global states which can be exchanged for user defined states seamlessly.
Check out logrus or any of the popular logging frameworks in go. You can either use the default logger which is globally exposed or you use a custom one and pass the variable.
>I'm willing to sacrifice that for increased productivity and simplicity.
If simplicity and productivity is your goal you should use one of the LISP variants like ClojureScript. Nothing beats a language which you can program to be more efficient for you.
And you probably should check out some Go code too, it's easy to understand even without knowledge of the language as long as you know some basic CS101 stuff.
I mostly agree with what you're saying, but note having a channel doesn't mean one stops worrying about synchronization. If two goroutines both started waiting for data from a channel they'd be deadlocked.
Which means well-designed services will remain available even if only with degraded performance.
If all go routines are deadlocked, the runtime will terminate the service.
It's a kind of graceful and somewhat safe degradation.
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.
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.
In Javascript you're not ensured to have an error, your program might continue working based on wrong data because some type has been randomly converted to a float.
In Go or C# you'd get an overflow error if the type is an int or you know it's a float and you get inaccuracy, if you need the accuracy you use a decimal type which will also ensure that any result is always of it's type.
Typed languages mean I cannot loose data accuracy without explicitly doing so. I have to tell Go that I want this uint64 as uint8 otherwise it's an error.
Performance? That is a good reason, but again if you actually pay attention to defining (and testing) your APIs that is in most cases a solved problem - use a fast language for performance sensitive endpoints.
Team's lack of knowledge? That's the only real argument. But that works both ways. If you have a team of experienced Node/JS developers then it would be foolish to implement your backend in Java (given no other constraints).
Regarding performance, your solution means that in order to understand your site, you need to understand another language and javascript now. At which point, why swap between languages and mindsets when the other language can already do everything javascript does, plus gives you a performance edge?
With the knowledge pool, it really does depend on the sort of application you're making, and how much code is reused and where. If your application has a web-based, and desktop/mobile app, you may very well be better off coding the entire thing in a language more amenable to native compilation.
Knowledge-wise, and long-term developer comfort-wise, Javascript's fast churn is problematic. When big packages' idea of long-term support is three years or less, you're going to be spending a lot of engineering time rewriting your code just to keep things from collapsing into a bug-ridden insecure heap. Examples like Angular.JS show just how brittle the javascript environment is, and how difficult it's going to be to keep a site maintained.
Regarding performance, why don't we write our web applications in C++, Rust or Go?
There is a lot of churn in front-end frameworks, but for back-end frameworks the ecosystem is more stable (I like ExpressJS, which is like the Rails for NodeJS).
If you factor your architecture correctly (e.g. separate your domain model from your views), you can also switch a bit easier between front-end frameworks.
Lots of people with little experience contribute, which is great, but "the ecosystem" is largely built by people with plenty of experience and training.
With HTML5, CSS3 and ES6 being released, and seeing wide adoption, the web-application layer and APIs suddenly have access to a magnitude more functionality, and we're essentially in the early romantic period where we're pushing these new features to the max, and figuring out what sticks.
Over the next year, we'll settle at the maxima of efficiency and usefulness with the web framework. Despite some negative voices, IMO these are very exciting times for the web :)
I think it's due to the fact that Javascript is so terrible at any scale, yet is so pervasive, that working with/around it becomes this deer-in-headlights thing you can't ignore... since most HAVE to work with it in some form, doing any Web stuff.
I recommend Elm, as a way around Javascript's problems while still allowing you to run in browsers: http://elm-lang.org/
Also these JS frameworks tend to be opinionated with how databinding works etc, such that there's always something that you have to work around when you're using the framework in real-world projects. People get annoyed enough that hey it's easier just to create another framework.
A lot of the churn going on is due to people trying to work out the best way to use these new features, along with whether or not to keep backwards-compatibility with existing frameworks and libraries.
Brendan Eich initially designed JavaScript in an infamously short time--he coded and designed the first prototype of JS in just 10 days.
It quickly became the only programming language you can use in a web browser, with multiple vendors, including Microsoft, owning mostly compatible implementations. Due to trademark disputes they couldn't even call the language standard "JavaScript," so the language standard is called "ECMAScript."
Microsoft didn't want/need JavaScript to change or grow at all. Once Internet Explorer 6 became the dominant browser on Windows, (which was and still is the dominant PC operating system,) they stopped releasing new major versions of IE for five years (2001-2006), and IE7 wasn't a very big upgrade, especially in terms of JS language features.
Mozilla unilaterally released new language features that only worked on Firefox, so nobody could use those language features in practice on the web; in many cases, new language features wouldn't even parse in IE.
In 2007, there was an attempt to build a major new JavaScript version (ECMAScript 4) with a ton of new features, (classes, a module system, optional static typing, algebraic data types) but it was scrapped due to disagreements between Mozilla and Microsoft. They wound up implementing a much more modest upgrade (ECMAScript 5) which shipped in IE9.
In all this time, there was essentially no interest in running JavaScript in command-line tools or on the server side. That changed in a big way in 2009 with Node.js. It used V8, Google's JIT engine for JS, and it was surprisingly fast.
This is when the language really started to unthaw. IE declined in dominance as Chrome rose, and the demands of server-side development started to be felt more strongly in the JS community.
ECMAScript 6 started to add back in a number of cool features, and by this time, JS developers were desperate to use them. This lead to the development of "6to5," (now called "Babel") which allowed you to write code in ES6 and "transpile" it into older JavaScript versions, so developers could experiment with new language ideas without pushing them through the standardization process.
Languange evolution kicked into high gear at that point. There are a bunch of interesting pluggable transpilers out there, including TypeScript, JSX, and Flow, and countless non-standard plugins for Babel.
And that's just the language itself! The "standard library" for JavaScript for years was just "whatever IE6 could do" and that wasn't very much. IE6 was pretty buggy as well. jQuery became popular as a library to smoothe over differences between browsers, but mostly to work around bugs in IE.
Client-side frameworks were tough to implement on IE6, not least because IE6 was just so darn slow. As newer, faster browsers came out, it became possible to trade off some performance to improve developer productivity.
And everybody has their own ideas about what those trade-offs might be like!
At the same time as IE6 started to decline in popularity, the mobile web on iPhone and Android rose in importance. Smartphones include a bunch of new sensors (GPS, orientation, camera) and new limitations (RAM, slow/unreliable network). This spurred on browser vendors to "compete with native apps," adding features to the browser platform, inviting developers to respond to these with new frameworks.
As for the JS server-side, Node.js is still a relatively young platform as these things go, and so it's not surprising to see a lot of churn in server-side libraries/frameworks, especially given how much churn the language itself is undergoing.
Node.js is also the first major platform to be born in github, which IMO encourages experimentation (and flame wars) via forking.
Node.js's standard library is designed to be small, (they call it the "core" and resist Python's "batteries included" philosophy,) forcing folks to rely on libraries and frameworks to keep the lights on. Even most libraries themselves need to take dependencies on other libraries, because of this "small core" philosophy.
I think it's going to be at least a few more years before things start to cool off a bit. Enjoy the ride, if you can!
Angular 1 was written by people who knew nothing but OO programming. JavaScript isn't OO. So they spent a lot of time square pegging a round hole because they were ignorant of what they were doing (probably a group of young coders).
People are now starting to get on the functional train (which JavaScript is more like than OO), and angular is trying to now fix the fact they were short sighted and too opinionated about the wrong things.
JavaScript, in general, has always been in a rapid state of change. Or, more broadly, the UI of the web. From flash and silverlight to mootools and jquery and CSS animations and canvas... there isn't a good way to do web UIs yet. There is a lot of trial and error happening which makes for some rough waters.
The variety of backend requirements, and the flexibility of UX, led people to solve many individual workflow bottlenecks or generalize to any/many.
Then so, like the English language, exploded to the simple-->jargon range of overloaded usage and niche comprehension, very quickly fragmenting, but universally powerful.
Developing a framework as a startup for a particular use case may take more time than prototyping on an existing framework--this is why the prototype should be discarded, and a critique of how open source/reusable code has always been a source of technical debt apart from the rare, shining outliers.
Frameworks as a popular thing started because people (rails?) started sharing their code and no other can share code as easily as JS and npm.
Angular 2 should be called Begular because it doesn't have anything to do with Angular but inspiration. You can stay on Angular but don't be surprised that people will prefer to develop something else since Angular folk painted themselves into a corner so hard that to make framework that sucks less they need to go back to drawing board.
If you want your code to work in the future, you are ultimately responsible for your code and all of its dependencies. The less code, the better. (Although some libraries have earned a track record of dependability, projects and companies may be abandoned and you may need to pick up the slack)
That's unusual. These frameworks extend the language. Angular's developers reasoned that anyone smart enough to figure out Angular 1 will be able to migrate their code to Angular 2. It's looking more like C++ and less like CSS. :)
Take a look at Meteor's code sometime. It does things I never expected possible with JavaScript.
https://spion.github.io/posts/javascript-is-not-cancer.html
TLDR: I believe its mostly due to the lack of basic language facilities in pre-ES6 JS. With ES6 covering the basics this will probably slow down (At the very least people will stop writing their own module and object systems)
However, moving fast does percolate down from the top. Look at Node.js and how often they release new versions.
Also, some of these things are getting addressed over time, so I'm kinda going to talk about the state of JS over the past decade rather than the state it is in right now. Some of these things are being mitigated (very few things are really being "fixed"), but it's still early. These issues have historically included, but are not limited to:
1. Poor modularity brought on by being not just a "scripting language" like, say, Python, but a language actually designed to write small event handlers that fit into a single HTML tag attribute. "x = 56" defaults to putting x in the global namespace. The language did not provide modules or very much in the way of separation by default. You've pretty much always been able to namespace things, but you had to really work at it; the language did not help. (I'll also toss in the dynamic typing here, just because I don't want to give it a full slot here, but it does inhibit making big projects easily.)
2. Very poor control-flow management ability due to the choppiness of event-based programming. There has historically not been a way to maintain a call stack across events, which strips away all the tools of structured programming, a set of tools so fundamental to how we operate that we often don't see them as a fish doesn't see water. Promises and generators allow us to try to mitigate this, but at the cost of spending design budget; promises for instance introduce a second entirely new set of control flow mechanisms that mirror the base language's looping and flow control constructs, particularly annoying because you must control both error and normal flow on both of these levels.
3. The browser's interface to JS is the "Document Object Model", which due to historical reasons is a Java-designed API bolted on to the side of JS. A native JS model could have been much more powerful and easier-to-use, requiring us to burn less design budget on simply interfacing to the browser in a reasonable manner. A lot of the design churn is attempts to answer the question "How can we make manipulating the DOM more JS-native?" There are also several performance issues introduced by the fact that the DOM model, combined with the rendering model, is extremely rich; things like manipulating a node on a page vs. detaching the node, manipulating it, and reattaching it have historically had end-user-significant differences in performance, as every DOM change triggers an incredibly complicated set of updates to a widget toolkit that was designed for flexibility rather than performance.
4. Browers themselves further introduce many complications. Then you have all the security issues that arise from being fundamentally client-server with dubiously-trustable servers. You have all the details like what cookies flow between what domains and where and when, that you need a different domain for your static content both for security and performance reasons (prior to HTTP2 particularly), and any number of crazy APIs that also vary across browsers, requiring the developer to use shims for things as simple as XMLHTTPRequests because you just never quite know what you actually have.
5. I could have list "client-server" in #4 there, but it's also worthy of its own callout. Many frameworks have different solutions for client-server interactions, ranging from ignoring the problem and letting you solve it up through Meteor-like attempts to completely blur the lines between the two, and everything in-between. Client-server interaction has been further inhibited by the fact that historically, there have not been any reliable and high-performing mechanisms for streaming things between the client and server, creating a design limit around needing to be request-based, further creating a wide variety of ways of hacking around this problem, each with their own quirks.
6. As an open standard, nobody is really empowered to fix these problems in a coordinated way. As a result we're sitting on top of 20ish years of standards, some well-done, some poorly-thought out, some hackily fixed after security issues, many poorly-understood by developers, and all in the browser.
7. Finally, one must not ignore the fact that web pages continue to become intrinsically more and more diverse. The best framework for a document-centric app is one thing, the best framework for a CRUD app another, and neither of those will help you much with an intrinsically real-time streaming app like a chat client.
And there's probably a couple more dimensions I could come up with if I thought more. What you see is that there's a lot of possibilities for mitigating all these issues ("solving" is often not on the table, these are mostly fundamental issues arising from layers below the JS), and the framework churn is in many ways nothing more than people combining all of the various combinations of possible answers to these problems, looking for synergies, solving different problems (per #7), and basically frantically rifling through 60+ years of computer science theory looking for the perfect solution to problems in an environment with so many fundamental strutural issues that no perfect solution is possible. Which is also why you see such vigorous advocacy sometimes; someone thinks this is it, this solves all my problems once and for all because it worked for a couple of weeks, and only once the community has chewed on it for a while does it become clear that there's a lot of people with different needs for whom that doesn't work so much, and it also didn't actually solve all the problems once and for all after all.
BTW, none of this is criticism of the JS community, merely explanation. Given the hand we've been dealt in the web browser, lots of people trying lots of things is the best we can hope for. The fatigue is just an unfortunate, but unavoidable, side effect. The best solution for the fatigue is to concentrate more on the fundamentals being explored than the details of a particular framework. For instance, "reactive" programming is its own paradigm, with its own lore and learning; learning how to program that will also let you write better spreadsheets and be better at creating database triggers, for instance. Concentrate on the fundamentals. The fundamentals are not churning that fast.
That's not the problem, angular 1 and angular 2 are 2 completely different frameworks that share the name and the team only. The team wanted to piggyback on the fame of the first version, but they share absolutely nothing conceptually. and contrary to what the Angular team says there is no "upgrade path", you need to learn the stuff from scratch once again.
The problem is, and the Angular team will find out very soon, "second systems" unless they provide huge advantages over the first version, are always a failure.
Skip the chart, look at the long tail of listings.
Should there be?
...and it is where a lot of excitement is now. Excitement drives development (of tools themselves and general usage). Much of the time, it is for the best.
People tend to get lost in tooling, which I can understand.
It's always on. Anyone from anywhere can interact with what you create instantly. What else is like that ?
There are very great developers in the ecosystem, who write great tools and libraries which become popular, are well maintained and documented. But the majority of the developers are just average developers. As everyone, they attend conferences and bootcamps, and when I then talk to them, the usual thing they learned there were two things: (1) make a blog and write about what you are doing and (2) make some OSS projects or participate in existing projects.
It is very great to have people who create projects and bring in new ideas, it helps create a mature technology. But the truth is, most of the average developers have never been in larger projects, have never been digging into complicated/large open source libraries and have never had to manage larger applications. One of the most important things you learn in such projects is to be calm and think about documentation, architecture and dependencies carefully.
And this leads to the current situation;
- we have a lot of libraries doing the same things, just because developers do this "just create an oss project on GitHub/npmjs" thing without searching for existing solutions
- some hip developers have so many projects that I always ask myself how they are planning to support all these
- when a problem arises, e.g. a bug in a library, many developers these days seem to tend to write their on lib fixing that problem (if it is a small library) or building an internal workaround instead of contributing back to the original project
- on the other hand, there are a lot of project maintainers who ignore issues and pull requests just because they have a very strong opinion about what their library is doing. Oh boy, sometimes it took me days to write a PR which (from my point of view) improved something or added a new feature, carefully followed existing guidelines (code formatting, docs, etc) just to get the answer "nah, that's not my scope. Fork the project or write your own"
- it seems to be easier to convince people with less business experience. They often jump on the next hot train coming along that sounds good. I don't want to exclude me here completely; as I read about React, it started working with it directly - because it seems to solve all the problems I had with Angular and Backbone
- I have the feeling that a lot of developers today (still) have this "read the f*g code" mentality. Even mature libraries developed for years have so bad documentation (even though they have their own .io domain just for it) that I have to read their source to see what parameters I can pass into a function.
I think, browsers/engines/tech companies/... are also part of the problem. For years, JavaScript has been "developed" (language spec) slowly and browser have been adopting features slowly. But then, suddenly, everything exploded. And now we have very awesome features in the language that allow for things that have not been possible before. And in fact, these features deprecate some libraries or frameworks. And instead of abandoning a project by deciding that only bugs will be fixed in the future and no new features will be added, the developers either try to move to the new technology with their product; or are forked by people who were part of the project but didn't like its developers/strategy/whatever and want to use the new opportunity with the new language feature to change things; or get company by another project that does basically the same but started from scratch and uses all new language features; or all together.
As a side note, I work with JavaScript every day and that is only my opinion on the topic. Please don't feel offended.
[edit: typos and formatting]
we need a full IDE, Language, Library combo for better development.
Use JS to do FP (functional), rather than OOP, and it totally rocks. Refactoring stuff works pretty well with nested functions - function names have to be "real" (if avoiding eval()), as opposed to properties that can be provided as associative array string indices (not that there's anything wrong with that, if that's what you need).
I'm not a script kiddie, either - I have been programming since the early 80s when I was earning my CS degree. I'm not scared of dynamic scripting languages
- Has no standard library. - Is used to automate host platforms that have either no standard framework or very little (e.g. Node on v8 doesn't have nothing but it's quite small). - Has no module/namespace system.
The effect of this is that immediately, anyone building anything in non-trivial has to make a decision about how to fill in things that would be covered in a standard library. I'm not even talking about fancy stuff, just the stuff supplied by underscore, lodash, etc. The choices are basically:
1) Write all the code yourself. This is an extremely low ROI option 2) Adopt a series of libraries and hope you can get them to work together 3) Adopt a framework, that by its nature, will be designed to use some sort of new pattern and this pattern will be expressed on top of whatever libraries the framework uses, so just draft behind that.
There aren't really many other mainstream systems where a language is used to specialize applications on a platform where this situation obtains. Windows, OS X, iOS, Android, even Java, come with enormous, enormous amounts of library code. Generally, this library code also pushes one fairly firmly towards certain design patterns.
Imagine if we all decided to use...hmmm...Scheme, I guess, to develop Windows applications, and you took away everything but the lowest-level Windows APIs. I'm using Scheme because the Scheme standard outlines a remarkably small language that has nothing approaching a standard library.
We'd probably be in a similar situation. How do you do this? How much does adopting this or that library force you to do this or that? It's just not very common to have a situation where to do anything non-trivial, you need to either: - adopt an enormous amount of third party code (because the situation works at every level, each third-party solution will also not be built on a standard library ecosystem) - write an enormous amount of boilerplate code.
And further, the issue is exacerbated by the fact that js doesn't really have a standard module system, so even the approaches taken to fill these gaps are frequently non-compatible, or just choosing which system to use to manage modules often means replacing huge chunks of your application.
There are other reasons why JS the language is moving, all of the sudden: JS has had a lot of rough edges and all of the sudden a confluence of interest, capability, and technology has made it possible to sand down some of those edges.
But I think even if the ES process slows down, and we all agree that language-wise the features in the language are pretty good or something happens that freezes, we'll keep seeing lots of churn because of the interaction between every project being built on towers of third party code with far-reaching effects.
When Java, for instance, was released, the standard library it shipped with included: - a set of standard container classes: hashes, vectors, arrays, etc. - a rich set of real types (e.g. numbers that weren't insane, Objects for compatibility with the object system, primitive types in the language for performance) - a whole tree of calendar/date manipulation code - a standard way of connecting to SQL databases and all the code for that - a standard GUI-drawing and event-handling system - a big, rich set of APIs for handling IO of various kinds with different performance/complexity tradeoffs. - a concurrency api, threadpools, etc.
That's just a sample. And all of the bits worked together, and sort of implied patterns in how things should be built and used.
You could certainly replace anything, should you choose to, in your project (e.g. the calendar stuff really sucked), but the point is, there was a default, and there was a standard pattern for where and how to bring in new library code, and that new library code would in turn be built on as little third-party code as possible.
Look at an average iOS project's Podfile or Carthage file, Android project's Gradle file, and then look at a Node or browser js project's package.json. Then actually look in Pods and node_modules. The average amount of third party libs in a JS project is many orders of magnitude higher than in the others.
There are like, what, five or so competing implementations of Promises in javascript land? And they aren't mutually compatible always, so this means if you want to use non-ES6 babel-compiled Promises in your code, you have to: - choose a library - hope that other libraries and frameworks you use use the same style - add shims or something where they don't, or else switch out the library and framework.
This is just like...no one writing an Android app is like "which Runnables library are you using?". No one writing an iOS app is like "soo...the new GCD spec looks interesting, which GCD lib are you using for your project? Oh yeah how spec-complete is it? Does it work with AFNetworking?"
"Lodash makes JavaScript easier by taking the hassle out of working with arrays, numbers, objects, strings, etc. Lodash’s modular methods are great for:
Iterating arrays, objects, & strings"
Iterating arrays, objects, & strings is something that most other languages have decent std lib support for, and so even your third-party libs will use the host language's affordances. In Javascript you have to ask these questions all the time.
The "JavaScript standard library" (or lack thereof) is a clear example of this: NPM is the LARGEST collection of packages of any language, and you can almost always find someone who has already written what you need most the time. It never ceases to surprise me. During the Pokemon Go craze I was curious to play with the protocol: there was already a package to do it. I wanted to ping my find my iPhone, there's already a package to do that. Its incredible. And yet the actual built in standard library is notoriously lacking. Although not by design, certainly the end result is that that has become "OK" thanks to NPM.
Compare this to something like AppKit (and UIKit), which were very much in the pre-internet/sharing mentality: there is one framework everyone has and becomes experts in and is fairy stable, because its kind of the only thing you can rely on being around. Sharing code is very difficult, to the point where just copying and pasting files is still a valid contender.
The explosion of options and the increase in churn is a natural consequence of this. There are simply more people working on more problems, all encouraged by an environment where sharing code is a fundamental property. If step 1 of setting up node is downloading other people's random packages then it should be no surprise that step 4 of sharing your own packages will seem natural. We should expect this to only get faster -- the more people program, the more crazy ideas will be tried, the more switching there will be. I really don't understand what the alternative is: arbitrarily choosing frameworks to be around for a 5 years (a decade?).
We are simply taking the last measure of stability, which was largely governed by how long it used to take information to disseminate to the entire community, how long it used to take one controlling body to get their large waterfall releases out the door, and using that as an arbitrary comparison point to how long it takes hundred of individuals to release their individual takes on software. Asking to "stop the churn" is a strange request: there's no single entity pushing stuff out "too fast", this is the aggregate affect of all programmers in the node community publishing their ideas. Who are we asking to slow down exactly? I can understand saying the single case of Angular 1/2, but the "JavaScript fatigue" people actually feel is due to the interaction of all the JavaScript projects that each gain and lose popularity.
Unless you believe we're really close to figuring this whole "software development" thing out (whatever that means), I wholeheartedly believe that programming 20 years from now will look more like this -- faster pace of developments.
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.
Better languages have sensible defaults, and a decent standard library built in. If we could run Python or Java natively in the browser, nobody would bother with all of this illogical complexity that has arisen to try to make writing Javascript moderately tolerable.