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

151–160 of 189 posts

Re: State of JavaScript 2020

#151

Post by judofyr »

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

Exactly! Updating a user's role on the BE is actually a really difficult task: You need to persist the data in a safe way and ensure that it's consistent with other concurrent actions that happens. These hard problems have been worked on for 50 years and what we've ended up with is a set of solid tools (SQL databases that provides transactions). It's thanks to these tools that BE becomes easy. These tools have also been built on top of each other. A new tool often "extends" an older tool instead of "replacing" it.

It comparison, look at some of the "progress" in the tooling in the front-end world: One of the biggest recent change in state management is React Hooks. This is a concept which has zero precedence in any language or literature. It's something they invented out of thin air and behaves like nothing else out there. The documentation has a big list of gotchas you need to watch out for. Does it has its advantages? Sure, it's nice for many things. But of course there's going to be rough edges when introducing such novel concepts.

Cocoa has been successfully using view controllers for state management for 20 years (or more?). They've made some tweaks over the years (e.g. segues), but it's mainly stayed the same. Is state management perfect in Cocoa? No. Do you hear Cocoa developers complain about state management? Yes. Do they spend every year talking about the "new best way to handle state"? Nope.

I understand that it's not completely comparable (different platforms etc), but of course state management becomes a recurring problem when you end up switching out the state management library every second year (Redux anyone?).

Re: State of JavaScript 2020

#152

Post by ballenf »

bartread wrote: post #100
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…

> People don’t switch tooling and frameworks for fun (well, not primarily), but because the pain of learning something new is worth the benefit of reducing unnecessary complexity. This is sometimes true, but not always. For example, it's also sometimes true that teams switch to technology X because X has become popular, and without necessarily understanding the benefits and drawbacks. In some cases a choice is made t…

I think the switches are driven by recruiting just as much as the old thing being “dead” in itself.

There’s a sweet spot in the middle of a tech’s popularity where people are cheaper. Very late or early expertise is more expensive.

You also are getting people who might be more inclined to learn new things. And that may be a proxy for a good hire.

Re: State of JavaScript 2020

#153

Post by ballenf »

habosa wrote: post #94

It's pretty clear that we're in a period of relative stability. React and TypeScript have been the tools of choice for 2-3 years now. Webpack is the clear choice in bundler. Most people seem to be using the modern language features. You can see that the number of extremely satisfied or dissatisfied people has gone down, people have moved towards the middle as the big tools have matured. It's nice. I feel like I actua…

Maybe it’s my bubble but I’ve seen a slight retraction from typescript in the past year.

Re: State of JavaScript 2020

#154

Post by nojvek »

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 are right about JS fragmentation. After doing 10+ years of frontend, my theory is that frontend welcomes a lot of new self learnt programmers mostly because the browser is the runtime and almost every device has it. This means it’s pretty easy to stitch a few things and get something useful in the hands of customers. Npm makes it very easy to create new packages and libraries. All though not a significant % of community has computer science background and deeply understand what goes under the hood.

StateOfJS contains stats of new programmers : old ones. Things that stay the same after a long period of time and stay successful have been reasoned from first principles to satisfy its constraints in the most efficient way possible.

E.g svelte was built up this way, to track changes and propagate dom mutations in a very efficient way while still keeping the invariant of view= state of function.

My point is that many things in JS are made without such fundamental analysis, so you see churn.

I’m a fan of esbuild since it’s built from fundamentals (parse the AST from source only once and utilize all cores while doing it, it saturates available disk bandwidth since go is amazingly efficient at it)

Those ideas are here to stay for a long time.

Re: State of JavaScript 2020

#155

Post by moron4hire »

esperent wrote: post #142
moron4hire wrote: post #121

Earlier quoted context omitted.

C# doesn't have non-LTS versions. Java doesn't. C, C++, Haskell, OCaml don't. In OSes, Windows and Mac OS don't. I'm actually struggling to think of anything outside of Linux and Node that has this concept of "here's a major version that is marked LTS and here is a beta, but we're not going to call it beta, we're just going to call it an odd-numbered major version".

Windows does do LTS. So do Java, Django, Unity, and many others. That said, node versioning has caused me a lot of stress over the last few years. Not sure if that's to do with the use of LTS specifically though.

When Microsoft calls a version of Windows "LTS", it means "this is an old version of Windows for which we're going to keep releasing security updates for the next 10 years", not "all more recent versions of Windows should be considered beta quality software".

I forgot about Unity. Yes, Unity is another offender here. One of the many reasons I quit working with it.

Re: State of JavaScript 2020

#156

Post by _nalply »

jtdev wrote: post #129
milkers wrote: post #5

Some takeaways of mine; - Typescript keeps strengthening its position as industry standard. - Svelte is hyped, but is it battle tested enough? - Testing Library is quite new in the town but already the runner up testing tool. - In terms of data management, GraphQL holds its position on the top while good-ol Redux kept losing interest. What are yours?

> “In terms of data management, GraphQL holds its position on the top while good-ol Redux kept losing interest.” Not sure what you mean by “data management” here, but fetch/REST seem like to most predominant, simple, ubiquitous means of handling external data.

When I read that I immediately thought about GraphQL subscriptions. I don't know whether this will a bottleneck, but perhaps it makes sense to route everything through GraphQL, this means: someone updates via GraphQL and everybody listening gets an event by subscriptions.

Re: State of JavaScript 2020

#157

Post by davidwparker »

milkers wrote: post #5

Some takeaways of mine; - Typescript keeps strengthening its position as industry standard. - Svelte is hyped, but is it battle tested enough? - Testing Library is quite new in the town but already the runner up testing tool. - In terms of data management, GraphQL holds its position on the top while good-ol Redux kept losing interest. What are yours?

Svelte is hard to get passed the hype until you build a reasonable size project with it.

Personal anecdote/plug: I built https://www.listenaddict.com/ last year with Svelte. It's medium-ish sized (majority of the app is the moderator and administrator pages). It's extremely fast to develop (and will only be faster with SvelteKit+Snowpack). It's trivial to implement components and stores make state management a breeze.

Having done React for ~4 years, and some Vue projects, I won't be going back to those anytime soon.

That said, it's not without its own issues, but anything I've had issues with I've been able to solve relatively quickly or have someone within the community help.

Re: State of JavaScript 2020

#158

Post by ghufran_syed »

systemvoltage wrote: post #6

Cliche rant coming up: as a backend engineer, recently started working on frontend. Is this how yall do things? Everything so far feels less mature, thinly pieced together, barely holding up, fast moving, unnecessarily bloated, and no care for longevity, robustness and discipline. Seems like every thing is on Youtube, no real good books (yeah, go ahead and search for "React JS" books on Amazon and see if you find som…

I can't make any promises, but many js engineers have found that clojurescript together with a framework like re-frame seems to offer a different mental model they find useful

https://day8.github.io/re-frame/

Re: State of JavaScript 2020

#159

Post by aidos »

paulryanrogers wrote: post #122
aidos wrote: post #98

Earlier quoted context omitted.

Agreed. It becomes really messy moving all that state around. Still in its infancy but we’ve settled on a model where we use Hasura to sync the whole datastore to the frontend as a mobx graph. It’s relatively easy to then drive the frontend off layers of computations on that graph. We’ve also put a transaction layer on mutations of the models so they’re automatically batched and sent as a single request / dB transact…

Where and how does conflict resolution happen?

The clients are all up to date on changes fairly much instantaneously. And then updates from a client are synchronous in terms of setting all data and having that bundled and sent as a single request which is executed as a single dB transaction (we only send the specific fields that were updated).

If two people do something at the same moment, then it’s last request wins. We have dB constraints to keep the data consistent.

It’s not a perfect model, but it’s pragmatic and works well for our use.

Re: State of JavaScript 2020

#160

Post by AltruisticGapHN »

machiaweliczny wrote: post #149
AltruisticGapHN wrote: post #107

Earlier quoted context omitted.

Many many moons ago I wrote C and C++, typed languages right? I don’t remember typing my code being so abstract and complicated. Take php 7+, has good typing features and is way, way easier to understand. All I want is native js interfaces, namespaces and basic types, then F### typescript :) Seriously somtimes as nerds we like something because its complicated and presses our dopamine buttons when we figure it out, b…

There's middle ground with TS. Just allow implicit any and use JSDoc.

I tried JSDoc. I liked it at first but soon it became unusable.

Even putting aside how verbose it is, the problem is the IDE support was not working. Trying to document eg. Vue props with JSDoc, there was no completion.

Seems to me JSDoc in VSCode was working great for vanilla JS, but as soon as you use Vue, there are so many completions that were not recognised that it defeats the purpose. I mean, the IDE autocomplete where the IDE knows what members are in a given object, makes the work of typing the code all worth it. If it works only half the time, then it becomes pointless.

TypeScript is ok, but as soon as you have to do like DOM manipulation, then you get into the rabbit hole :) Figuring out all the ways those DOM apis are dclared, why they have many signatures sometimes for the same function...

Then again I suppose that's how you really learn TS.

Like if you wanted to declare an array with a default value in a Vue prop with JSDoc:

    props: {
      items: {
        /\* @type {{ new(): string[] }} \*/
        type: Array,
        default: function() { return [] }
It took some time to figure out how to do it with JSDoc (eg. above you can't use arrow function to declare the default value.

Then you need to figure all kind of shenanigans with Vetur/eslint... just wasn't worth the hassle, may as well use TS.

Post reply on HN