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

State of JavaScript 2020

2020.stateofjs.com

Post reply on HN
Print view View original

181–189 of 189 posts

Re: State of JavaScript 2020

#181

Post by wildermuthn »

judofyr wrote: post #151
wildermuthn wrote: post #83

I’ve been doing web FE in various capacities for about a decade. First jQuery, then backbone, then Angular, then ClojureScript with React, now React and Apollo. While I get the criticism about what might seem like an anarchic state of JavaScript, at each transition point there have been clear, demonstrable, and worthwhile changes. Backbone addressed jQuery spaghetti code. Angular addressed backbone boilerplate. React…

While I think it's important to fight against the "FE is easy; BE is real programming" stigma, I think you're going bit too much in the other direction. You're painting FE almost as the most difficult thing that exists. However, it's not like GUI applications is a new thing. GUI applications which talks to the Internet is not exactly groundbreaking either. > Updating a user’s role on the BE is a single SQL operation…

You’re right, I did go overboard. The hardest thing I did last year was battling race-conditions for concurrent BE operations. By far. But your point about some BE problems being solved and Cocoa state management still receiving complaints, suggests that browser state management still remains an unsolved problem.

Having said that, Apollo Client’s local field type definitions (akin to GraphQL resolvers for FE state) are as close as a solution as I’ve ever seen.

To add to your point, I do think that most complexity should be delegated to the BE, because the BE is almost always better equipped to handle it.

Re: State of JavaScript 2020

#182

Post by ehutch79 »

notapenny wrote: post #139
ehutch79 wrote: post #22

Vue is the 3rd in framework ranks... and like the 16th ranked? "Testing Library" is the top testing library apparently? Had to check that this was an actual library, I'm sure many people just left it as a 'whatever' choice. Someones data is dirty dirty dirty

I don't think it would be a "whatever" choice personally. I didn't take the survey this year, but other years you had to explicitly specify what your level of interest/satisfaction with a particular technology was. Personally I'm not surprised that testing-library came out so high in satisfaction; its an incredibly useful layer over Jest and and incredibly popular in React-land.

I mean, if you don't know it's a library, you may think this is the 'other' choice.

Re: State of JavaScript 2020

#183

Post by lytefm »

systemvoltage wrote: post #53
jamesgeck0 wrote: post #37

Earlier quoted context omitted.

Javascript tooling is crazy. A couple years ago I tried to build an older Ionic app that nobody had touched for six months, and the build had just bitrotted. Something somewhere in the dependencies hadn't been screwed down tightly enough, and everything was broken. I feel like the Yarn 2 package manager is a good move towards in making frontend development more stable (The "Plug'n'Play" feature allows you to store yo…

> having an extremely stable platform that never breaks backwards compatibility is exactly what the web needs to be. Frontend development tooling would be so much better if it was more like browsers. This is precisely my fear [1]. I need something robust and will continue to work for a good foreseeable future. Do you recommend Angular for frontend? I've just tried React and Svelte, but I am told to stay away from Ang…

I definitely second these comments. The app that I maintain at work started with Angular 5. We're now on Angular 11, but upgrades have never been an issue! I also like how Angular can be quite easy to get started with when simply using two-way data binding without rxjs or some complicated state management library. Not every company has access to devs who are proficient in reactive state management and functional programming. Angular work surprisingly well for the average developer.

Re: State of JavaScript 2020

#184

Post by erikpukinskis »

wildermuthn wrote: post #180
viraptor wrote: post #95

Earlier quoted context omitted.

> GraphQL finally forced backend engineering to coordinate with frontend engineering I'm curious what do you mean here? The way I see it is the exact opposite - front-end making new kind of queries without having to coordinate with backend. With positive effects (faster results) and negative ones (so this new query takes a minute to resolve and it's in production - fix it now!)

My view on this may be idiosyncratic and wrong, as I haven’t read about other teams doing this intentionally. Having said that... The most powerful but underused feature of GraphQL is that it abstracts away the details about the BE database model, which is for the FE (i.e., the product and user experience) an unnecessary implementation detail. A poorly designed GraphQL schema (and my teams did a lot of this at first)…

> a well-designed GraphQL schema looks like the shape of data required for component rendering, i.e., for the user experience.

I agree with this. GraphQL might seem like an interface to query the database, but I think it’s the reverse: an interface to populate the front end.

It is a constant struggle advocating for that when everyone seems to default to expect the GraphQL schema should just model the database tables. But I think it’s worth it. It gives you a fighting shot at heading off otherwise inevitable spaghetti UI code.

Re: State of JavaScript 2020

#185

Post by [deleted] »

amw-zero wrote: post #172
wildermuthn wrote: post #83

I’ve been doing web FE in various capacities for about a decade. First jQuery, then backbone, then Angular, then ClojureScript with React, now React and Apollo. While I get the criticism about what might seem like an anarchic state of JavaScript, at each transition point there have been clear, demonstrable, and worthwhile changes. Backbone addressed jQuery spaghetti code. Angular addressed backbone boilerplate. React…

My personal criticism of the web FE community is not that the tools haven’t solved problems, it’s that these problems have been solved before and that is not acknowledged. For example, a single-page app is the exact same thing as a native frontend. It’s a stateful, long-running process that communicates with a backend. This is not a new paradigm, but it is treated as one in the web community. Another example is decla…

[deleted]

Re: State of JavaScript 2020

#186

Post by erikpukinskis »

amw-zero wrote: post #172
wildermuthn wrote: post #83

I’ve been doing web FE in various capacities for about a decade. First jQuery, then backbone, then Angular, then ClojureScript with React, now React and Apollo. While I get the criticism about what might seem like an anarchic state of JavaScript, at each transition point there have been clear, demonstrable, and worthwhile changes. Backbone addressed jQuery spaghetti code. Angular addressed backbone boilerplate. React…

My personal criticism of the web FE community is not that the tools haven’t solved problems, it’s that these problems have been solved before and that is not acknowledged. For example, a single-page app is the exact same thing as a native frontend. It’s a stateful, long-running process that communicates with a backend. This is not a new paradigm, but it is treated as one in the web community. Another example is decla…

Xaml was released two years before Backbone, and only five years before React. It’s a contemporary of those efforts not a predecessor.

And according to the ECIS, it was created in part as a poison pill for the web UI platform. Not sure if you were around in the early part of the web’s history but Microsoft had a demonstrated pattern of using pseudo-standards to destroy competitors.

But I guess, I am left unsure of what you’re suggesting. That Facebook should have ported XAML to the web instead of creating React? That would have been... faster? Better?

Re: State of JavaScript 2020

#187

Post by erikpukinskis »

turtlebits wrote: post #85

Every time Javascript is discussed, the discussion turns negative. Fact of life is that the browser is THE cross platform app, and people have differing opinions on how things should be done.

It’s because the majority of jobs are front end web jobs, which is annoying you don’t do that kind of work. And you kind of wish people on the FE would just do things that backend way so you could have access to that job pool.

Re: State of JavaScript 2020

#188

Post by erikpukinskis »

typeengineering wrote: post #36

1. Optional Chaining and Nullish Coalescing is everything that they could come up with in the last 5 years. Private fields in javascript. God please what is wrong with these people. 2. If you look at resources, you have css-tricks as n1. Clearly there's very little number of Software Engineers / Computer Scientists in the JS world which doesn't have to be because if you're skilled you can take massive advantage of th…

This seems unnecessarily mean and dismissive. I have a software engineering degree, have been doing professional software engineering for 20 years and I love JavaScript. There are lots of things I dislike that are written in JavaScript or for JavaScript developers but I like the language.

What are you trying to get out of insulting people like me? Are you trying to get us to come seek you out as a teacher? Do you want us to feel ashamed of out careers and realize we need to go back to school?

Re: State of JavaScript 2020

#189

Post by robin21 »

esperent wrote: post #140
robin21 wrote: post #60

Earlier quoted context omitted.

Yeh Babel and webpack blow out compile times to epic proportions. Any app that grows to a certain size will slow down to a crawl on incremental builds.

Try esbuild. I thought the following benchmarks must be fake until I tried it myself. https://raw.githubusercontent.com/evanw/esbuild/master/image...

I really can’t believe that.

But I will try!

Post reply on HN