2017 JavaScript Rising Stars
risingstars.js.org
risingstars.js.org
Yes it’s a different language that compiles to JavaScript, but unlike other languages that do this, Elm exists solely to excel at front-end web development.
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 compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
No, because javascript isn't machine code, it's a high-level interpreted language. The metaphor of javascript as "bytecode" is just that - a metaphor.
>The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
Fair enough, but it doesn't actually change the grammar of the language, because those new "primitives" have to be implemented in, and interpreted as, javascript.
This is a psychological distinction, not a technical one. There is no fundamental difference between machine code, byte code, or a “real” programming language. There were machines that executed lisp, and at the dawn of time people programmed in assembly. Heck, people programmed in machine code (punch cards) and assembly was a programming language!
Scala introduces a hell of a lot of “new primitives” over jvm bytecode, and type erasure compiles it all down to the jvm anyway. Or JavaScript, if you use scala.js.
This is, in fact, precisely what compilers do (or transpilers—again: psychological distinction, technically the same thing). That is their job, their function: translating from one language into another. As long as both are Turing complete, you can do anything.
But, I don't think the distinction is entirely psychological. Every numeric type is implemented in javascript as a floating point Number, that's all javascript has. New types aren't added to javascript when other languages compile to it, they're compensated for within the limits of what a javascript parser considers valid code, either through existing javascript types or facades which imitate types. Whatever Scala or any other language considers an Int, BigInt, Double, etc. must still be implemented as a Number when compiled to javascript, or some object which imitates the semantics of the original language. But an Int() object in javascript is still not an integer.
It doesn't make sense to say that languages which compile to javascript add anything to the language. Or maybe I just don't understand types, and they really do, and it really doesn't matter. But to me, the distinction seems to matter.
I should probably stop tilting at this particular windmill, though.
Yes it does! That's the entire point.
It doesn't change the grammar of the language that the generated code is using, but you don't care, because you're not writing in that language.
But that's the grammar I was talking about, so no it doesn't.
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.
The point of Elm is not just the architecture, it's the language that allows you to write robust websites with little to no debugging necessary, all maintaining that robustness no matter how much you extend, tweak and refactor the codebase without having to be an expert in the language.
"Zero runtime exceptions" is no exaggeration, it's a reality in practice guaranteed by the compiler, meaning "after all it's compiled to js" makes no sense.
In Elm you don't have exceptions, so the framework does not accomodate for them like, say, React does.
It's also a pure language, so the separation of main state mutation and other side-effects without Elm the language is nothing more than convention, so you're not doing any better than Redux+Redux saga on that point.
I'd suggest you try out Elm in a small project and see for yourself why it makes no sense to try to make it fit in the context of JavaScript.
It's simply that Elm the framework was designed without regard for the problems of other languages, and making full use of the features of Elm the language.
On the other hand, Redux was inspired by Elm to replicate the same model in JavaScript while accounting for the deficiencies of that language. The closest you can get to Elm is probably that.
The biggest thing here is that Elm does not allow mutation. This turns out to be great because it eliminates little pockets of state that make your app’s behavior hard to predict and that eventually cause bugs. It also seems like it would be very hard to bolt this on to JavaScript; you’d have to break existing code and then your runtime would miss out on the performance benefits of assuming everything is immutable.
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.”
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?
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.
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.
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.
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.
React has a self sufficient cross platform eco system. I don't think people using primarily web frameworks even realize the implications of that yet. React works outside of the browser, and not just natively on mobile but literally everywhere. Imagine you use React as you always would to make a native command line application (https://github.com/Yomguithereal/react-blessed), but now you want to have a store or move things around, so you `npm install react-redux react-motion` and you just apply it (https://github.com/gaearon/react-blessed-hot-motion). Look at the code and try to picture the overhead if you had to do this in C++.
Being able to transfer code and knowledge, and seeing new renderers pop up for the wildest platforms each day, as well as official renderers made by big vendors (https://github.com/Microsoft/react-native-windows), the idea of a web-bound Angular-like framework seems odd in 2018. I wouldn't expect Vue to get the same kind of popularity without at least competing or doing something new.
https://github.com/lyonlai/blessed-vue
Either way, it's not such an issue. It's not hard to build on React when you want react and Vue when you want vue. They're easy to pick up the concepts on.
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?
It is a bit much, but this article is pretty heavy for a 250kbps connection even with just html and images.
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.
https://github.com/dvajs/dva/issues/1#issuecomment-334334184
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?
[1]: https://playoverwatch.com/en-us/heroes/dva/
[2]: http://batmanjs.org/
https://github.com/polymer/polymer https://risingstars.js.org/2017/en/#section-framework
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.
Single SPA - a Javascript Meta Framework https://github.com/CanopyTax/single-spa
>>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.