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

281–290 of 372 posts

Re: State of JavaScript 2019

#281

Post by wffurr »

cstuder wrote: post #7

The most interesting data in my opinion are the conflicting opinions on the overall state of the ecosystem:: https://2019.stateofjs.com/opinions/ While there is a sharp downtick of people who think that JavaScript is moving in the right directin, most agree that the overall situation in terms of complexity and velocity is getting better. I don't have any explanation for this, but would agree: Developing in JavaScript…

The "sharp downtick" is largely a shift from "strongly agree" to "agree". That doesn't seem too sharp to me. Mostly it seems like people are happier with where JS is now. There's less momentum behind changes the language, and fewer large developer-experience-changing features coming.

Re: State of JavaScript 2019

#282

Post by TomMarius »

leshow wrote: post #262
TomMarius wrote: post #171

Earlier quoted context omitted.

Not a single developer I know (I was in leadership position in a company with 300+ devs, now I lead a small startup dev team) cares about "heyday". They care about their experience during development being significantly worse with plain JS due to stupid ("we'll use TS because it checks names of properties") but also not so stupid ("we'll use TS because it checks that switches are exhaustive", "we'll use TS because it…

Most of the types you write in TS will be structural

Indeed, but the few ones that are nominal are making the difference.

Re: State of JavaScript 2019

#283

Post by nkingsy »

Bahamut wrote: post #71
samspenc wrote: post #61

I'm surprised to see Angular drop in ratings and rank so poorly compared to React. I personally prefer Angular myself because it's (a) opiniated and (b) has everything included (HTTP REST calls, Material UI, etc). Just curious why so many people prefer React and mark it so positively.

It surprises me too personally - the testing experience is worlds better, better built in modules than what you get in the React ecosystem (especially routing, http request layer, forms, testing, etc.), and opinionation that helps improve the overall experience of working with it. I miss my time with Angular sometimes - my only gripes is TypeScript being limiting with regard to function composition, and creating a co…

It’s just a bad framework for code reuse.

-No dynamic directives -Nothing dynamic works with @ContentChildren, making anything that uses it the “last stop” for abstraction. -DI system makes inheritance/mixins nearly impossible, and without dynamic directives there are situations where the only solution is a massive copy paste job.

I work in the framework every day and spend countless hours shaking my head at cryptic docs any time I try to do any type of abstraction.

Re: State of JavaScript 2019

#284

Post by yesimahuman »

warent wrote: post #5
Thorentis wrote: post #3

Sad to see Ionic in the avoid category. Their latest release I thought was quite polished, and I've enjoyed using Capacitor rather than Cordova. I think the key to further success is breaking away from Cordova entirely, and expanding the native features supported in Capacitor. Right now I find myself having to use both due to some things not being implemented in Capacitor yet.

At this point with React Native (or even Flutter if we're considering things apart from JS) there really isn't a compelling reason to build anything in a Webview as far as I know. Also in my personal experience their support team members have been pretty impatient and passive aggressive in the Github issues tickets so I'm not entirely surprised that they're building something that the community has moved away from.

There are a ton of compelling reasons to build apps targeting mobile web views, and despite Ionic's poor showing on this survey, we are seeing a lot of serious apps and brands doing so and picking it explicitly because of those benefits.

Perhaps the biggest is the overlap with web dev tech, team skill makeup, and the hiring market for web devs being incredibly vibrant. Vast majority of teams have struggled to go native and build/hire those teams, and are instead excited about using the web devs they already have or taking advantage of that hiring market.

One trend that is really interesting is that many teams have decided they need to be prepared for a PWA future and can't afford to have two separate efforts to accomplish that (i.e. app store apps and PWA). They see Ionic as a way to do both and be ready for the expansion of PWA adoption which is early but happening fairly organically, and has some key enterprise benefits that make it attractive for those teams.

Sorry you had a bad experience on our github issues. We're a small team relative to the size of the community and have had to resort to automation and tooling to figure out signal from noise. It's been a constant process of iteration on that front.

Re: State of JavaScript 2019

#285

Post by hajile »

hacker_9 wrote: post #131
734129837261 wrote: post #94

Earlier quoted context omitted.

TypeScript slows down a project. Nobody seems to ever point out what benefits it supposedly offers. My claim: TypeScript offers no benefit. Ever. That's 2 years of fulltime TS experience talking and 18 years of fulltime JavaScript experience, on top of a whole bunch of full stack (Java and .Net with C#) experience. I think the popularity of TS is going to decline. And I think it's only popular because of the influx o…

Slows down what? Compile times? By a small amount sure, but with the incremental compilation we're talking maybe a few tens of seconds max. Any longer and you need to look at improving your build dependencies for better parallelism, and upgrading your hardware. Development time? Types reduce mental overhead and abstraction for the developer, speeding up development. Run time? Variables with types that stay static exe…

> Development time? Types reduce mental overhead and abstraction for the developer, speeding up development.

React has proptypes that make contract guarantees -- ones that don't disappear at compile time. Most stuff is local to a single file. If your imports and shared objects are so poorly named and poorly understood that types become the major blocker, you have bigger issues.

> Run time? Variables with types that stay static execute faster in JS engines.

The biggest issue in JS engines is making functions monomorphic. Typescript is perfectly happy with every single function in your system being a slow, megamorphic call.

As to changing variables, judicious use of `const` is the real answer here.

There is definitely something to be said for enforcing object structure though. Adding and removing properties to an object is a significant issue. The non-type solution here is the addition of records and tuples to the system. Since they cannot be modified, the general performance will go up.

https://github.com/tc39/proposal-record-tuple

I like the idea of types, but dislike typescript. Most importantly, it is not a sound type system and the illusion of sound types is worse than dynamic types IMO. If I ever adopt a type system into my current project, it will undoubtedly be F# (fable) or ReasonML (ocaml) where I can gain sound types and better syntax without giving up the practical need for mutation (like with Elm where lots of garbage and poor interactions with JS libraries are the result).

Re: State of JavaScript 2019

#286

Post by Merad »

deckard1 wrote: post #147
hacker_9 wrote: post #131

Earlier quoted context omitted.

Slows down what? Compile times? By a small amount sure, but with the incremental compilation we're talking maybe a few tens of seconds max. Any longer and you need to look at improving your build dependencies for better parallelism, and upgrading your hardware. Development time? Types reduce mental overhead and abstraction for the developer, speeding up development. Run time? Variables with types that stay static exe…

> writing maintainable code is the real challenge If you think these same developers can't do it without TS, then you really haven't seen the sort of mess lesser developers make when they try with TS. Unless the JavaScript developer has a strong background in C/C++/Java, they are going to truly fuck up a code base with TypeScript. I'm not making a static/dynamic typing argument here. I'm making an observation that th…

I'm totally in favor of using TS, but I agree that lazy devs can set up an absolute mess when they try to use TS without really learning it. I think probably the fundamental weakness of TS is that you really need a good understand of how it's limited to compile time type checking, and how easily you can set up situations where the actual run time types don't match what you have in TS.

For example, it feels like I'm in a constant battle with some of our front end devs about typing their models correctly... they don't seem to understand that they keep setting up the type system to lie to them. For example, if a property in our API is nullable, then the property will always be present in the json with an explicit null value, so the model should be typed `propName: string | null`... but they prefer being lazy when mocking out data on the front end, so they instead type the model as `propName?: string`. Likewise with properties that are date/times (ISO-8601 strings in the json) they love to use Date as the type for those properties, then everywhere they use that property they end up wrapping it with `new Date()` because "it doesn't work" otherwise. Yikes.

Re: State of JavaScript 2019

#287

Post by fourthark »

stupidcar wrote: post #144

State of JS is always a fun and interesting survey, but I am wary about drawing conclusions from its results because of the self-selecting nature of the participants means they are probably not a representative sample of JS developers in general. They're inevitably going to trend towards English-speaking developers who read coding news sites, participate in social media.

Every year I glance at it, thinking maybe I will learn something about the state of JavaScript. Then I remember that it's a popularity contest and I get bored pretty quick.

I'm not sure why I should care what everyone else wants to learn. I guess it's worth finding out if there is a new popular framework this year. Sigh.

Re: State of JavaScript 2019

#289

Post by 8bitsrule »

"State of Javascript trends", yes.

Not much useful there for someone who just, you know, plods along with mere vanilla javascript.

And when I flipped to 'inverse' (because of the blinding white) ... there went the color scheme.

Re: State of JavaScript 2019

#290

Post by buu700 »

fuzzy2 wrote: post #275
buu700 wrote: post #248

Earlier quoted context omitted.

* 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 wi…

In what sense do you mean that Angular templates (with the language service) more "text" than other programming languages?

Everything definitely has a type, and I'm not having any issues with syntax highlighting, mousing over things to see what they are, or peek / go to definition. There are a couple hiccups[1], but those are just tooling issues.

The template is ultimately compiled to TypeScript, which is type checked as one would expect. In my mind Angular-HTML is the same type of thing as TSX/JSX, except with the problem of being more unique / further removed from the target language, so not benefiting as much from preexisting tooling.

It's actually a minor annoyance for me right now that my existing code isn't yet compatible with the strictest compilation setting[2] because it was developed against the older, more lax compiler that littered its emitted TS with `any`s. If you're having trouble with the complex use cases (which I've definitely run into as well), Angular 9 / Ivy will be a welcome upgrade.

(And totally agreed re: Zone; it needs to die in a fire.)

---

1: 1) "Find All References" isn't working for me (I'll file a bug report if there isn't one already), and 2) I have to peek definition to see what something's type is; as-is it just says "(property)".

2: https://next.angular.io/guide/template-typecheck#strict-mode

Post reply on HN