Earlier quoted context omitted.
Are Grunt and Gulp still not used?
*aren't -not
Maybe in really old and ossified projects?
State of JavaScript 2019
341–350 of 372 posts
Re: State of JavaScript 2019
#342I dream of an alternate timeline in which today we would release "State of ClojureScript 2019" with Javascript being listed as a ClojureScript flavor :)
JavaScript is slowly feeding off ClojureScript's design.
Re: State of JavaScript 2019
#343Wow, just learned of Svelte from this. After reading their explanatory blog post and coming upon this blurb: That all changed with the advent of hooks [React and Vue], which handle state in a very different fashion. Many frameworks started experimenting with their own implementations of hooks, but we quickly concluded it wasn't a direction we wanted to go in ... We can just use the language. Updating some count value…
The biennial JS framework migration makes me glad to be in ClojureScript world, where it's a little more static (in a good way). Well, perhaps thats a function of its smaller developer base. ClojureScript + Re-frame + GraphQL subscriptions (Hasura) is the most fun combination I've used in a while. I hope nothing 'better' takes the CLJS market anytime soon.
Re: State of JavaScript 2019
#344Earlier quoted context omitted.
Angular ng-is ng-very ng-opinionated and requires a ton of boilerplate knowledge. It requires typescript knowledge, and I've noticed that (finally!) a lot of developers are realising that typescript actually doesn't make life easier at all. React, on the other hand, is a very intuitive library instead of an all-encompassing framework. You can easily setup a React application in a few seconds and get started, adding w…
Typescript doesn't make things easier, and react is intuitive? You know April fool's is still a few months away right?
I have to say, although I agree that type-safety is nice, in practice having worked on many javascript apps large and small throughout the past decade, type errors have never been something that slowed me or my team down. Lately I've been questioning whether the hype around TS, and the extra layer of complexity, is really worth it. I guess it depends on the team etc, but I certainly question whether it's a good choice for new or smaller projects.
Re: State of JavaScript 2019
#345Earlier quoted context omitted.
https://stefankrause.net/js-frameworks-benchmark8/table.html Preact diffs against the real dom and is faster than Svelte in benchmarks while the library is only around 3.5kb (the minified code fits easily on a single screen). I'd note that authors from most of the frameworks represented have submitted their own optimizations, so performance isn't strictly based on the author's familiarity. InfernoJS is massively fast…
> https://stefankrause.net/js-frameworks-benchmark8/table.html The version of Svelte used there is roughly 100 releases and a year and a half old. These days Svelte's performance appears to be much closer to Inferno's than Preact's. https://krausest.github.io/js-framework-benchmark/current.ht...
Comparing average numbers in that chart, Preact is 22% faster than React, Svelte is 12.6% faster than Preact and Inferno is 14.5% faster than Svelte. (note: Preact 10.1 is out and this uses 10.0)
Vanilla JS 1.04 (5.8% faster than Inferno)
Inferno JS 1.10 (14.5% faster than Svelte)
Svelte JS 1.26 (12.6% faster than Preact)
Preact JS 1.42 (22% faster than React)
Vanilla JS 144kb
Inferno JS 163kb
Svelte JS 146kb
Preact JS 153kb
Vanilla JS 3.3mb
Inferno JS 4.8mb
Svelte JS 4.4mb
Preact JS 7.5mb
Vanilla JS 20.3ms
Inferno JS 21.6ms
Svelte JS 20.4ms
Preact JS 19.4ms
Vanilla JS 1882ms
Inferno JS 2033ms
Svelte JS 1883ms
Preact JS 2031ms
Why would I want to choose Svelte?
Re: State of JavaScript 2019
#346Earlier quoted context omitted.
https://stefankrause.net/js-frameworks-benchmark8/table.html Preact diffs against the real dom and is faster than Svelte in benchmarks while the library is only around 3.5kb (the minified code fits easily on a single screen). I'd note that authors from most of the frameworks represented have submitted their own optimizations, so performance isn't strictly based on the author's familiarity. InfernoJS is massively fast…
This statement makes no sense: > I have to learn their proprietary syntax and markup. One of Svelte's raison d'etre is to "use the language" and err on less proprietary syntax / api / markup. Of the big three (not including Svelte), Svelte uses far less proprietary syntax, boilerplate, and API coverage. It errs on using as much native JS, CSS, and HTML as possible.
React has one and only one syntactic conceit which is JSX. Truth be told, that is based on a subset of the now deprecated e4x standard.
Let's look at Svelte's special syntax going over the docs. Everything mentioned here is NOT part of either the HTML or JS spec.
* Uppercase HTML is special (I really don't understand this one as this seems like the perfect opportunity to go all-in on web components)
* Interpolation using curly braces
* magical $$props object
* custom if..else..end syntax
* multiple variants of the custom loop syntax
* custom await, promise, and handler syntax
* custom HTML escape syntax
* custom debugger syntax
* custom element directive syntax
* tons of stuff using the element directive syntax (especially events and data binding)
* 4 non-standard pseudo-DOM events
* magical (lowercase) HTML element
* magical (lowercase) HTML element
* magical $: syntax for binding updates
That's a ton of magic and doesn't include all the magical code generated to wire everything together. That wouldn't be important except that you can't really avoid it. In React, I can just step over library calls, but since there's no Svelte library, I have to step through the spaghetti it creates from my code (spaghetti because efficient machine-generated code is always spaghetti).
Re: State of JavaScript 2019
#347Earlier quoted context omitted.
(Survey author) The Netherlands doesn't have a large population, so it's never going to show up as a large part of the results. For next time it would be interesting to also let you toggle a relative view of participation vs population though.
It’s a small country but with nearly half the population of Spain, and the most densely populated country in the world outside of Taiwan. Not to mention a massive development community (and one of the largest internet infrastructures in the world). So, more relevant than you’d think :)
Taiwan and The Netherlands are not even close to being the most densely populated countries in the world. Taiwan is 652/km² and Netherlands is 418/km². Compare that to Macau 20,286/km² or Singapore at 7,804/km².
But I agree that The Netherlands has a pretty big development community, and generally their English is fairly close to being native.
Re: State of JavaScript 2019
#348Earlier quoted context omitted.
> https://stefankrause.net/js-frameworks-benchmark8/table.html The version of Svelte used there is roughly 100 releases and a year and a half old. These days Svelte's performance appears to be much closer to Inferno's than Preact's. https://krausest.github.io/js-framework-benchmark/current.ht...
Comparing average numbers in that chart, Preact is 22% faster than React, Svelte is 12.6% faster than Preact and Inferno is 14.5% faster than Svelte. (note: Preact 10.1 is out and this uses 10.0) Vanilla JS 1.04 (5.8% faster than Inferno) Inferno JS 1.10 (14.5% faster than Svelte) Svelte JS 1.26 (12.6% faster than Preact) Preact JS 1.42 (22% faster than React) Total Size isn't that different either. That's an 11% pay…
Your total size numbers are almost entirely dominated by Bootstrap and a font, which are the same for all the tests (and not something that would be used on a site where payload size matters). Svelte's JS output, gzipped, is about 40% smaller than Preact and 65% smaller than Inferno.
Assuming those ratios hold up for larger apps, that would be one reason to consider Svelte.
Re: State of JavaScript 2019
#349Earlier quoted context omitted.
> branches cost nothing. They are very lightweight, unlike in SVN, you should create as many as you want. Ahhhh. So the distinction matters if you bring in a bad assumption from SVN. It had never occurred to me that a labeled branch would be noticeably more expensive than the weight of the commits making up the branch. > you can put a branch anywhere you want. You like an old commit and wanna try something new from i…
> This one's a little weirder; if you delete a branch, you _can_ recreate it, but it's only blink-of-an-eye easy to do if there's another branch containing the head of the old branch. Otherwise you're mucking around in the internal data. git reflog is very useful for this. Also, when you delete a branch, git helpfully prints Deleted branch foo (was da2bb5d) so you already have that information, right there.
Was going to say that. reflog should be in every tutorials.
When I started using git, I checked out back in time, then git logged and was baffled to not see my most recent commits in the listing. I panicked, though I lost my work.
Git terrible UI didn't help there: who though it was a good idea to just hide everything with no hint of how to get back at it?
Of course, I could have just git checkout master to get back where at was, I just didn't know it. But that's the point of reflog: if you are not sure what you did or where you are, it's always there for you, it has your back.
Re: State of JavaScript 2019
#350Earlier quoted context omitted.
It helps to NOT think of a branch as a commit node, nor a chain of commits ending in that node. A branch is a separate concept, it's not even stored in the history DB but in a different dir. See it as a label attached to a commit, since a commit can have several branches attached to it, or none. A branch will be moved across the history, while a commit will keep his place in the history. A branch is designed to be ea…
> branches cost nothing. They are very lightweight, unlike in SVN, you should create as many as you want. Ahhhh. So the distinction matters if you bring in a bad assumption from SVN. It had never occurred to me that a labeled branch would be noticeably more expensive than the weight of the commits making up the branch. > you can put a branch anywhere you want. You like an old commit and wanna try something new from i…
> In your opinion, how many of these points are "git gotchas" that the first group need to be trained in, and how many are "subversion gotchas" that only really come up for the second group?
Many years ago, SVN users coming to git were indeed a huge source of head scratching.
Not anymore.
Now we just have a lot of people that just don't think in a way that will lead them to say "So, there's an isomorphism between (1) a commit node; and (2) the chain(s) of commits ending in that node.". In fact, they don't know what isomorphism means, nor that the word exists.
Personally, I like to picture git as applied graph theory. One command = a bunch of operations on the graph.
But there is an old git joke that says:
"Git gets easier once you understand branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space".
It is nonsensical (it's a meta reference to a Monad joke), but I think it gets the point perfectly: we need to bring git to the people that needs it, not to ask the people to come to git. I don't care what level of abstraction they are comfortable with, I want them to feel like they can trust their ability to be productive with the tool and feel their project is safe.
And I find that this way of explaining branches is the most universal way for people from all sorts of background to have a decent model of how git works under the hood. So that when fall in a trap, they can use this model and find a pragmatic way out by themself.
Being right used to be my objective when I was younger. Now I just want to be helpful.