Live data from Hacker News

The State of JavaScript 2018

2018.stateofjs.com

191–200 of 286 posts

Re: The State of JavaScript 2018

#191
post #176

budding dev here! I'm so impressed with the :onhover action of 'Start' button of https://2018.stateofjs.com/ Can anyone provide me a direction how to achieve that?

First, see if you can figure out how to animate the boxes the way they are when you're not hovering over start: they're moving around the screen in a straight line until they reach the edge of the screen.

The animation we're looking at is moving SVG boxes around the screen, so if you search for tutorials about how to animate SVG with JavaScript, you'll quickly figure out how to make the animation happen. Although the technique isn't really specific to SVG; it'll work the same if you're moving divs around instead.

Once you've figure out how to animate DOM elements, to recreate what you saw on the start page of the survey, you'll want to keep track of each box's x and y velocity to know where to move them when you render each frame. If a box hits the top or bottom of the screen, reverse its y velocity, i.e. if its y velocity was 2, when it hits the top or bottom edge, it'll be -2. If it hits the left or right edge, reverse its x velocity.

Next, let's look at what's happening when you hover over the start button: each of the boxes has an assigned position, and when you hover over the start button, each box rapidly moves itself back to its assigned position. And it is timed so that each box reaches its assigned position at the same time.

To make that happen, you'll first need to figure out how far each box will have to move horizontally and vertically to get back it its assigned position. To get this, you just do (assigned y - current y) and (assigned x - current x). This will tell you how far each box needs to move in both directions to get to where it it needs to be. Based on this, you can calculate new x and y velocities for the boxes. Each box will have to move at a different velocity, because they'll all be at different distances from their assigned locations.

I've deliberately been a bit vague here, I know. I was going to put together an example on Codepen, but decided against it because it is so, so easy to take a look at someone else's code example and think you know what's going on without really understanding it. Whereas if you learn how to animate elements yourself, and then follow the thought process I laid out, you're a lot more likely to learn this deeply and remember it.

I hope this all helps, but if any of it seemed unclear, let me know and I'll do my best to clarify.

Re: The State of JavaScript 2018

#192
post #64

Earlier quoted context omitted.

I think we should also consider that most people have gotten used to the fact that JS is the language of the web, and there’s basically nothing we can really do about it in the short term, so let’s just have a positive attitude towards it! P.S. I don’t, but most people I have met seem to have this kind of mentality.

Yep, the Stockholm Syndrome. I still swear a blue streak when I get pulled from my nice backend world over to do some trivial UI work on the front-end, and it takes me frigging forever because there's no type system, and no compiler, and the tooling is stone age, and it takes me longer to run gulp and babel to build it to see changes than building my entire backend solution and running all my tests. It's all we've go…

That isn't surprising because the backend is simple and the frontend is not.

By that, I mean that you get to choose your entire playing field on the backend. What language are you going to use? What database? What OS will it run on? What (reliable) network connection? All can be tailored to your heart's desire.

No such luck on the frontend. Your code is going to run on a diverse set of clients, which you have no control over. The connection quality might be awful. The CPU on the device might be awful, or it might have low memory.

As much as people like to crap on JavaScript, it isn't the reason the front-end is difficult to program for. And WebAssembly isn't going to solve all of these issues either.

Re: The State of JavaScript 2018

#193

Earlier quoted context omitted.

What's 'catastrophic' about Yarn?

Not exactly Yarn or NPM. The problem is that JS is suffering from extreme dependency hell, due to overly fragmentation of modules. It's appalling. It is not a good thing starting a project, doing a install and having hundreds and hundreds of modules on node_modules, some with less then 50 lines of code. Of course things must be modular, but unwraping everything in a folder like this is far from good.

I'm curious: why is it bad? I very, very rarely have to delve into my node_modules folder to take a look at something.

Re: The State of JavaScript 2018

#194
post #61
post #18

People are generally happy with the development of JS the trends of always improving languages along with frameworks makes developing with JS makes developer increase in happiness for the third time in a row. ES6 is good, TypeScript is gaining ground, people are moving away from Flow. Angular is dead? Most don't even want to touch it again ( Great ). Ember hasn't moved a bit in three years with a declining of interes…

> TypeScript is gaining ground, people are moving away from Flow. Is it really the case? Both projects are watched and have quite big number of stars in github. I have tried flow and liked it. I have used typescript in the past and I'm not crazy about it. Therefore I would like to get better understanding here. Is there anything I could read about it?

I started using TypeScript professionally for the first time this year. A few more datapoints: I've had recruiters calling me for TypeScript projects, but not for Flow. This is in the Netherlands.

Re: The State of JavaScript 2018

#195
post #18

People are generally happy with the development of JS the trends of always improving languages along with frameworks makes developing with JS makes developer increase in happiness for the third time in a row. ES6 is good, TypeScript is gaining ground, people are moving away from Flow. Angular is dead? Most don't even want to touch it again ( Great ). Ember hasn't moved a bit in three years with a declining of interes…

And my biggest surprise is how Javascript turned from one of the most hated programming language ( besides PHP ? ) into being acceptable and loved.

I enjoy modern JS myself, but I'd be careful about coming to a conclusion like that based on this survey. All it tells us is that JavaScript is very well liked among people who wanted to take the time to complete the State of JavaScript survey.

People who dislike or hate it JS probably wouldn't see the value in completing the survey, so the happiness factor might be a bit biased as a result.

Re: The State of JavaScript 2018

#196

Earlier quoted context omitted.

Yep, the Stockholm Syndrome. I still swear a blue streak when I get pulled from my nice backend world over to do some trivial UI work on the front-end, and it takes me frigging forever because there's no type system, and no compiler, and the tooling is stone age, and it takes me longer to run gulp and babel to build it to see changes than building my entire backend solution and running all my tests. It's all we've go…

But client development is always hard. Comparing backend work to browser client development in an effort to attack Javascript never made sense to me. At least you have pretty good wiggle room to use other solutions on the browser client, whether it's other languages (TypeScript, Elm), to completely new abstractions (React, Elm again, etc). For example, Elm or React are a fuck ton better than anything we have native o…

Look at flutter. Please.

Re: The State of JavaScript 2018

#197

18000 respondents are men vs only 900 women The State of What Men Think about Javascript but seriously how was this survey distributed and is there any explanation for the gender discrepancy?

Maybe that's actual representation of the genders in the web development field. If so, then it's still "What JS users think of JS."

https://www.ncwit.org/blog/did-you-know-demographics-technic...

According to this woman make up around 30% of web developers in the US. The highest amount of respondents are from the US so I would expect the woman respondents to be more than a measly 5%.

Re: The State of JavaScript 2018

#198
post #195
post #18

People are generally happy with the development of JS the trends of always improving languages along with frameworks makes developing with JS makes developer increase in happiness for the third time in a row. ES6 is good, TypeScript is gaining ground, people are moving away from Flow. Angular is dead? Most don't even want to touch it again ( Great ). Ember hasn't moved a bit in three years with a declining of interes…

And my biggest surprise is how Javascript turned from one of the most hated programming language ( besides PHP ? ) into being acceptable and loved. I enjoy modern JS myself, but I'd be careful about coming to a conclusion like that based on this survey. All it tells us is that JavaScript is very well liked among people who wanted to take the time to complete the State of JavaScript survey. People who dislike or hate…

JS is not loved. Is hated less :)

BTW, I insist that is a missed oportunity of clean JS even more (ala typescript, whit some of the wats removed).

I don't know a language in a better position of improve by a HUGE margin than JS.

Re: The State of JavaScript 2018

#199
post #103

Earlier quoted context omitted.

as someone who tried Angular and was so relieved with the simplicity of React, I have no idea how they can come to that conclusion. But then again, I'm not very well know with the field of enterprise customers

React requires too much FP concepts for the typical average enterprise developer. It feels like doing Haskell with JavaScript.

I dunno--most of what I end up doing has state, if not context. Not super Haskell-ish.

Re: The State of JavaScript 2018

#200

I don't understand what is "Native Apps"? No links are provided. The description is "tools_descriptions.native-apps", on the page https://2018.stateofjs.com/mobile-and-desktop/native-apps , which is probably, a bug. My guesses are: 1) Non-JS mobile native apps built on Java and Swift. 2) Native script https://www.nativescript.org/ 3) Smth idk about.

I'm guessing it was a bug, because now the page you linked to says: The majority of mobile and desktop apps are still built with native languages like Java, Kotlin, Objective-C, or Swift.

NativeScript has its own separate page.

Post reply on HN