Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of JavaScript 2019

2019.stateofjs.com

Post reply on HN
Print view View original

271–280 of 372 posts

Re: State of JavaScript 2019

#271

Post by mekster »

734129837261 wrote: post #75
toastal wrote: post #12

It looks like more people need to learn about PureScript. I was happy to see it included this year though.

I really don't see the point of strong typed programming. JavaScript is fine without it. I've been working with TypeScript for a while now and I never think "this solves a problem I had!" On the contrary, I constantly think "why..." I feel strong typing JS is just a result of backend developers not questioning their upbringings and failing to use proper naming conventions, progressive enhancement in the form of JSDOC…

Suppose you're using an editor that actually gives you clever warning if types don't match?

Using plain vim with typescript makes no sense.

It gives me plenty of useful checks using TS. Lack of members, wrong types returned, missing return in switch statement etc.

Saying JS works for you fine sounds like "I have (or waste) good amount of brain memory on my program, so I don't need any further checking.", which can't be the case on code other people wrote.

Re: State of JavaScript 2019

#272

Post by erokar »

bradchris wrote: post #95

Wow, 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…

Svelte seems promising. I think it's a natural evolution from what I think is an over focus on FP and purity in React, to a more natural and intuitive DX without significant drawbacks.

Svelte does have an irritating wart IMO, citing their tutorial:

     Because Svelte's reactivity is triggered by assignments, using array 
     methods like push and splice won't automatically cause updates.
So for reference types that are mutated in place you need to do something like:

     numbers.push(numbers.length + 1);
     numbers = numbers;
Or:

     numbers = [...numbers, numbers.length + 1];
This looks like a leaky abstraction to me since it forces the developer to work according to the implementation details. Don't know how easy it would be to fix this.

Re: State of JavaScript 2019

#273

Post by mekster »

arvinsim wrote: post #106
734129837261 wrote: post #92

Earlier quoted context omitted.

So, I've worked with JavaScript since 2001. Up until two years ago I never used a strong typed flavour on top of JS. And I have never needed it. Not in big teams and not in small teams. At work we recently did a timed programming problem solving competition. 20 Teams got 1 hour each to solve multiple levels of the same problems. Some teams used TypeScript. None of the TypeScript teams got past level 5. All of the res…

Yeah, Typescript does slow a project down. It's not even about using types. Sometimes you get stuck trying to resolve Typescript issues that are not part of your core problem.

Sounds like you just don't know how to cast a type for your specific case rather than a TS bug, which is fair to say as sometimes you need decent time to learn how to do it.

Re: State of JavaScript 2019

#274

Post by Spooks »

acemarke wrote: post #31
HenriNext wrote: post #18

Redux has the largest shift towards "negative opinion" out of all technologies. Did people just get fed up with the boilerplate or is there something else going on?

Hi, I'm a Redux maintainer. There's been a lot of reasons for a shift in opinions over the last few years: - Redux is well past the initial burst of enthusiasm in the "hype cycle" - As you mentioned, there are a number of common concerns expressed by a lot of folks, most of which revolve around "boilerplate" - There are now a wider variety of other options that overlap with ways you'd use Redux: React's Context and H…

Just started working with the new Redux Toolkit package and it is really good in terms of simplifying things.

Re: State of JavaScript 2019

#275

Post by fuzzy2 »

buu700 wrote: post #248
fuzzy2 wrote: post #150

Earlier quoted context omitted.

Maybe because React is small (API surface) and does (or is felt to do) “one thing”. It is easy to wrap your head around it, even without fully understanding, say, the Virtual DOM diffing. Angular is very different in that regard. I recently had to read up on how Angular applies changes to the DOM. It was extremely difficult to get this information at all. For me, React with TypeScript is king. It trumps Angular in th…

* Angular templates are typed, but until version 9 (coming out in a couple weeks, but I've been using the RCs and they've been fine), any variable created in the template itself was defined as `any`, creating gaps in the compiler's coverage. A vscode plugin provides IntelliSense. * Agreed, this is an awful default and I don't understand why the Angular team hasn't already deprecated it. I suppose a slightly simpler "…

On templates:

Weeeell, no(-ish). Angular templates are text. They are checked during AOT compilation or otherwise at runtime (were most type information is gone already). And maybe at some other point I don’t know about.

The Angular Language Service (which came very late) is a lot of help, if doesn’t fail to pick up component members yet again. I’m not sure whether it knows about types either.

It also has problems with some complex use cases: for example, we have a derived `CdkTable` attribute, yet it doesn’t pick up its input properties.

tl;dr: I don’t like text templates! I really like React “templates”! :D

There’s also a minor annoyance: I’m not very fond of having the components as elements in the DOM. At least with modern browsers they behave predictably!

On change detection:

While `OnPush` is required for any sane application, you really need to fully disable Zone.js unless you want your application to re-render pointlessly. That could cause problems with third-party components I guess...? Either way, it’s really not as straightforward as it should be.

Re: State of JavaScript 2019

#276

Post by fatbird »

kabes wrote: post #260
fatbird wrote: post #243

Earlier quoted context omitted.

Good lord has it been that long? It's on Meteor 1.6 now, and you'd be mistaken about "much changes". Blaze to React was a nearly a rewrite; Atmosphere packages to npm was a significant change for the internal dependencies we developed; removing the custom file loader itself that preceded Atmosphere packages meant touching every single file. The original code might have still worked, but the code would be helplessly o…

But if you had picked any other tool from 2014, you'd probably also be stuck with a legacy code base now, without any clear transition path except a big bang rewrite. You would have probably picked angularjs or backbone back in 2014 and a switch to react would have been even more trouble. Meteor allows you to mix blaze & react, mix atmosphere & npm packages, mix their old module systems with commonjs and ES6 modules.…

True: we'd have faced the same transition with any other stack. In hindsight, Meteor wasn't a bad choice, it just didn't live up to its promise of sidestepping churn and offering an opinionated stack that would endure. I don't know that any did.

Re: State of JavaScript 2019

#277

Post by hajile »

nailer wrote: post #199
bradchris wrote: post #95

Wow, 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…

Yeah Svelte is the next thing. Backbone and Angular were great, but then came Vue and React. Vue and React were great, but then came Svelte. It's: - Simpler. You change values with `=` not some method call. - Faster, as the svelte compiler dynamically creates bindings at build time, vs a virtual DOM that has to dynamically track binding at run time - Smaller, since Svelte's output doesn't include Svelte.

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 faster than Svelte or Preact (the benchmark author had to do some rather convoluted re-writes of vanillaJS over the years to keep ahead) and it uses a virtual DOM, but has a few optimizations that React doesn't have or can't use due to its external API.

stdweb is the real thing to keep your eye on as it seems to show that WASM can be every fast. They still haven't gotten the vanilla benchmark up to the same speed.

https://stefankrause.net/js-frameworks-benchmark8/table.html

React's Fibers do some cool batching behind the scenes which means that large updates (especially constant ones like animations) don't have large negative impacts on user interaction. I doubt this would be possible without a vdom or something very similar to track all changes before deciding batches and update priority.

Also, remember that vdoms have gotten a lot more efficient too. Newer ones can do things like re-use existing sub-trees or recycle vdom objects (they can also recycle the associated real DOM nodes too). Preventing all that extra garbage goes a huge way toward keeping those vdoms efficient.

As to svelte in particular, you aren't "just using an equals". It actually compiles behind the scenes into a completely different set of reactive code. This gets at my biggest issue with such frameworks. Their abstractions aren't free. I have to learn their proprietary syntax and markup. I then have to learn how their compiler works behind the scenes when its time to debug the code I wrote. When I compile a React-style component into ES7 and run it in the brower, I have to deal with webpack for imports and I have to understand that JSX is really just JS functions. Otherwise, what I wrote is what I'll see.

https://cdnjs.cloudflare.com/ajax/libs/preact/8.5.2/preact.m...

Re: State of JavaScript 2019

#278

Post by arxpoetica »

hajile wrote: post #277
nailer wrote: post #199

Earlier quoted context omitted.

Yeah Svelte is the next thing. Backbone and Angular were great, but then came Vue and React. Vue and React were great, but then came Svelte. It's: - Simpler. You change values with `=` not some method call. - Faster, as the svelte compiler dynamically creates bindings at build time, vs a virtual DOM that has to dynamically track binding at run time - Smaller, since Svelte's output doesn't include Svelte.

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.

Re: State of JavaScript 2019

#279

Post by exdsq »

imiric wrote: post #160
734129837261 wrote: post #92

Earlier quoted context omitted.

So, I've worked with JavaScript since 2001. Up until two years ago I never used a strong typed flavour on top of JS. And I have never needed it. Not in big teams and not in small teams. At work we recently did a timed programming problem solving competition. 20 Teams got 1 hour each to solve multiple levels of the same problems. Some teams used TypeScript. None of the TypeScript teams got past level 5. All of the res…

> At work we recently did a timed programming problem solving competition. Thankfully, real world software development is not done under arbitrary time constraints with teams competing on who can be first to complete a prototype. High quality software is very difficult to produce, and taking the time to adopt sane development practices that reduce cognitive load and detect bugs early on in the process often leads to…

Also, if you are using a statically typed language there are tools for property based testing like QuickCheck which eliminates the need to write those thousands of very trivial tests. I've seen one advertised for JavaScript but you can't guarantee it'll find everything thanks to typecasting.

Re: State of JavaScript 2019

#280

Post by adamsea »

BiteCode_dev wrote: post #76
5350-uiop-1130 wrote: post #21

Wow, 39.9% of respondents mark themselves as "Expert" at CSS. I've been doing front-end in various guises for 12 years and I would only rank myself maybe 5 or 6 out of 10. As I've gotten more experienced in my career I've become more aware of what I don't know as opposed to what I do know. It's funny that "Advanced" is mastering animations and transitions whereas "Expert" is being able to develop a full-front end con…

Half of my income is from training people in JS and Python. I have 50% of those missions that are requested to be "advanced" courses. The vast majority of the participants are not up to the task. They are paid professionnals, but they consistently overestimate they level, skills and needs. They often are not very good, and of course, they don't know what they don't know. So I always check for that first, and rewrite…

If you don't mind my asking how did you get into training people in JS and Python, and, how do you like it?
Post reply on HN