From the Vue.js information page on that site,
'The concept of single-file component that includes template, logic and styles in a single file .vue file is really nice.'
NO IT IS NOT!
2017 JavaScript Rising Stars
31–40 of 101 posts
Re: 2017 JavaScript Rising Stars
#32I actually find this very informative, it gives a good overview of the js landscape right now. I'm however perplexed as to why the back button doesn't work, which makes navigation really hard particularly annoying on android mobile as pressing back ends up closing the browser. It uses react, so I thought that was pretty much supported out of the box. Any idea?
Where is the category for Angular ecosystem?
Where is the category for Ember.js ecosystem. It is actually huge and amazing.
Re: 2017 JavaScript Rising Stars
#33Earlier quoted context omitted.
Because a framework can't bring new language primitives, such as types?
No language that "compiles to javascript" really creates new language primitives - it would have to rewrite the interpreter to do that. What it does do - simulating new language features in javascript - could theoretically be done with a framework as well.
Well then do you think no language that "compiles to machine code" really creates new language primitives, either?
The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
Re: 2017 JavaScript Rising Stars
#34Hmm, this feels very misleading. What is the correlation between Github stars and real world usage? This is not statistics, it's just 1 variable.. It almost feels like Vue.js is going to take over React just because it received more Github stars? I use React already for years, never gave it a star on Github, and I think many with me.
Re: 2017 JavaScript Rising Stars
#35Earlier quoted context omitted.
Because a framework can't bring new language primitives, such as types?
No language that "compiles to javascript" really creates new language primitives - it would have to rewrite the interpreter to do that. What it does do - simulating new language features in javascript - could theoretically be done with a framework as well.
Just like no language that compiles to machine code can create new x86 assembler instructions.
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.
Re: 2017 JavaScript Rising Stars
#36Earlier quoted context omitted.
Because a framework can't bring new language primitives, such as types?
No language that "compiles to javascript" really creates new language primitives - it would have to rewrite the interpreter to do that. What it does do - simulating new language features in javascript - could theoretically be done with a framework as well.
No, you wouldn't get the required compile time checks. (Transpile time checks in exact)
Re: 2017 JavaScript Rising Stars
#37Earlier quoted context omitted.
No language that "compiles to javascript" really creates new language primitives - it would have to rewrite the interpreter to do that. What it does do - simulating new language features in javascript - could theoretically be done with a framework as well.
Well then do you think no language that "compiles to machine code" really creates new language primitives, either? The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
> Well then do you think no language that "compiles to machine code" really creates new language primitives, either?
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.
Re: 2017 JavaScript Rising Stars
#38We've had some questions on how libraries were selected. Basically, they were manually added and tagged on http://bestof.js.org , and we then reused the data to build the Rising Stars rankings. 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!
Hey Sacha, we both spoke at NordicJS where we met. You mentioned your survey found a bunch of stats on my library's growth, and I know it has gone up by +3K in 2017 (total of 7K+ now), yet it seems unfortunately left out because gun isn't "tagged" as anything more than a database, not even a NodeJS framework (when it is, at least as much as Feathers is). 30+ projects were highlighted with less than 3K+ increase in st…
Hey, sorry about that! It looks like we do have Gun in the BestOfJS db, so we could add it. Like you said the only problem is figuring out in which category…
Re: 2017 JavaScript Rising Stars
#39Earlier quoted context omitted.
Well then do you think no language that "compiles to machine code" really creates new language primitives, either? The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
> Well then do you think no language that "compiles to machine code" really creates new language primitives, either? 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 cha…
> 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.
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.
Re: 2017 JavaScript Rising Stars
#40Earlier quoted context omitted.
Well then do you think no language that "compiles to machine code" really creates new language primitives, either? The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
> Well then do you think no language that "compiles to machine code" really creates new language primitives, either? 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 cha…
> it doesn't actually change the grammar of the language
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.