Ironically, that Redux and React equivalents are some of the “batteries included” in Elm can make it harder to pitch because at first it seems like you’d have to add that stuff in.
The set of languages on state-of-JS is therefore artificially constrained to what the creators of the survey think deserves a place there, rather than the actual community thinks.
I'm a fan of elm, but but overall population of functional programmers is quite small, so I wouldn't be shocked of Elm, PureScript, and Reason had similar populations of developers.
1 - https://nim-lang.org
Elm also removes classes, inheritance, == vs ===, and a bunch of other JS junk drawer stuff that turns out to be unnecessary when you have immutability and a thorough type system.
“Perfection is not when there’s nothing more to add, only when there’s nothing more to take away.”
Or you could have a runtime development option to detect mutations similar to existing redux-type solutions. This also still doesn't explain why the need for a new language instead of decoupling the two. As I mentioned in another comment, all these features make working in Elm probably a superior experience, but I fail to see why it's mandatory and the mandatory-ness is what makes this a much harder sell.
In a large enough codebase, reaching every code path is non-trivial. It’s very easy to write code that only runs when it gets a certain response from a server, and at that point you need an entire integrated environment, plus a humongous space of configuration and use cases. (Or highly detailed mocks and 100% test coverage, which is even more rare.)
By contrast, you get that much certainty every time an Elm program compiles.
Maybe it’s possible to statically analyze JS to the point where you can get the same guarantees as compiling from a stricter language, but that seems very very hard.
Isn't immutability a problem in a garbage collected environment? I come from a C++ and ActionScript background, and on the ActionScript side garbage collection was a major issue. Would I not have the same if not worse issues in Elm?
The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
>The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
So sure, what Elm gives you can be done with just a framework, but it wouldn't be very productive. There is a reason why hardly anybody programs in assembler anymore (unless they have a good reason). Higher-level languages provide better abstractions, allow you to write more expressive code, are safer etc.
Except that it unfortunately falls short of that.
Quite a few projects (Node.js and Backbone) achieved wide adoption before 1.0.0.
For the record I’m not sure the Elm project has any claim one way or another, apart from the current version of 0.18 and the main contributors having large code bases in production at private companies.
So maybe it’s not that damning, and we still haven’t heard the GPs thoughts on how Elm has fallen short for them.
Over 2017 me and my (former) small dev team embraced Vue.js, built a non trivial checkout flow and visited the first Vue.js Conf Poland. I’m neck deep in Vue for other projects.
That guy in 2014 was of course Evan You, creator of Vue.js, and I guess I bought the domain for one one of the candidate names for Vue.
I chose to make a desktop app with Electron and Vue and Element UI without having any experience with any of those and hardly any JS experience. I had a full working app that synced with a server and allowed multi-user editing with auto updates in under 3 months.
Shared libraries and projects are definitely accelerating developers' abilities to quickly build things.
Even searching Github for 'import React from 'react' and 'import Vue from 'vue' results in similar percentages. Roughly 7-8 million projects in Github on React, under a million on Vue.
Despite the hype, Vue has been mostly a flat over the last 2 years with a slight upward bend, but only to the point where it begins to catch up with the old Angular 1.x.
Describing this trend as "mostly flat with a slight upward bend." is very misleading.
Go 2 years back on that page and you see a clearer picture, yes it did grow, but relatively contained compared to its competitors, specifically React.
And is it any wonder to anyone? I really ask myself. Would you go back to a stryingly typed templating framework with a complex api and ever changing ruleset, reliant on dependency injection and all the other stuff we went through with Angular? I don't think anyone would. It rather looks like Vue is catching the last remaining Angular 1.x refugees, but there isn't an ever increasing supply of those.
As it stands npms numbers coincide with all the other sources you could pull: projects on github, tracked project dependencies, size of eco system, job market, etc.
I think I was overstating Alibaba and Tencent's use of Vue with that of other Chinese developers or software shops.
So if you see a library missing, it could be because we didn't know about it and didn't add it to the database, or maybe tagged it in a way that excluded it from a specific category. Feedback welcome!
30+ projects were highlighted with less than 3K+ increase in stars, so it is just frustrating/disheartening to see mine left out. :/ Any chance there could be a "Everything Else" category or adding "NodeJS Framework" as a tag to us?
Please examine other possible causes for a 30 second page load, unless you're running on an 1st gen raspberry pi, 56k modem and a browser with a showstoppingly bad js engine.
EDIT, using chrome's dev tools I tried loading with the "slow 3g" preset, rendering of useful textual + hyperlink content took under 10 seconds, images slowly came in after that over a longer period.
That is not an achievement.
If it were a plain text document and it was only JS loading and parsing that slowed it down then it would indeed be embarrassing.
My response is to the person asserting that JS is the reason this page is slow. I'm not making a statement that this is the greatest and fastest loading page on earth.
It is a bit much, but this article is pretty heavy for a 250kbps connection even with just html and images.
I am sure english will remain the dominant language for a while but I wonder if it makes sense to start learning new (human) languages just to open up the number of communities you can learn from?
Secondly, shouldn't the fact that that would have made Polymer #3 given you some thought?
Polymer has ~19k stars total.
React has ~85k stars total.
Vue has ~80k stars total.
AngularJS (v1) has ~58k stars total.
Angular (v2+) has ~32k stars total.
Ember has ~18.6k stars total.
Preact has ~17k stars total.
So Polymer is behind React, Vue, AngularJS and Angular on total stars, having just surpassed Ember. Placing it 3rd in the rising stars list would have placed it before Angular.
I'd think "Polymer is more popular than Angular" would have been pretty newsworthy.
It's great to see Vue.js getting so much love. I've been extolling it's virtue on HN and elsewhere for years now. The fact that it has gained so much traction and is not the baby of one of the big Internet megacorps is a testament to it's genuine quality as a frontend Web framework. After many devs finally realized that Angular sucked even though, or especially because, it was backed by Google, it was sad to see the same people jump on to the React bandwagon, in a large part, because it was backed by Facebook. There are legitimate reasons for liking React but a lot of its adoption has been due to FOMO. Vue.js stands on its own.
I hope the big guns like Alibaba or someone else acquire Vue.js and make it a real competitor to React.
>>Use multiple frameworks on the same page without refreshing the page (React, AngularJS, Angular, Ember, or whatever you're using)
>>Write code using a new framework, without rewriting your existing app
>>Lazy load code for improved initial load time.
Unfortunately also missing in lists like this one.
Feel free to put that in scare quotes, as if you can barely register its existence! In fact, that whole enterprise is probably misguided and full of falsehoods, anyways, having witnessed the lies and attacks, first hand, for years! Better nip it in the bud now, while you still can!
I don't think the author had malicious intent.
Unfortunately, we use quote marks for at least 2 different meanings:
(1) <scare_quote>type checking</scare_quote> ... as dismissive sarcasm
(2) <term_of_art_quote>type checking</term_of_art_quote> ... as a delimiters for industry vocabulary
Based on all the other uses of quotes in the blog post, he's using it as (2) terms of art. Some style guides suggest using italics instead of quotes for terms of art but a nice property of "quotes" is that it survives copy & paste into plain text files.
NO IT IS NOT!
Aside from that, single file components are completely optional.