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

141–150 of 189 posts

Re: State of JavaScript 2020

#141

Post by literallycancer »

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…

Expecting Amazon search results to do your research for you, that was never going to work.

Re: State of JavaScript 2020

#142

Post by esperent »

moron4hire wrote: post #121
inopinatus wrote: post #81

Earlier quoted context omitted.

So we can develop for them. A new version of, say, a programming language needs the ecosystem to come along with it.

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.

Re: State of JavaScript 2020

#143

Post by merrywhether »

bhauer wrote: post #9

As someone who is relatively outside of the JavaScript ecosystem, I had the following realization yesterday when I was reviewing this: JavaScript has what I would consider two distinct flavors of "back-end" frameworks. It has frameworks like Express and Koa, which I would consider traditional back-end frameworks. These are designed around handling HTTP requests and providing dynamic responses in myriad forms: rendere…

I’ve heard some people refer to Next-like frameworks as “middle-end” to highlight their specific intersection of concerns.

Re: State of JavaScript 2020

#144

Post by esperent »

olingern wrote: post #24
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…

Do you remember when you could rent a physical machine somewhere and have something running in 5 minutes? We moved to something more verbose to support the new volume of the internet. The same has happened on the front-end. I consider some front-ends, like Twitter’s, applications just as I do iOS or Android. You can get out of this by using jQuery. It still works.

> You can get out of this by using jQuery.

You don't even need jQuery these days. All the important functionality is now in the DOM by default.

Re: State of JavaScript 2020

#145

Post by franklyt »

Silhouette wrote: post #118
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…

I would like to think that the next big change will be the slow but steady replacement of JS/TS by one or more much better languages. Even with the current relative calm in front end web development, JS is still a terrible language for almost everything that matters. TS is a noble effort to put lipstick on a pig that achieves some useful benefits, but only at the expense of adding even more complexity, a sometimes cl…

JS isn’t going anywhere.

Re: State of JavaScript 2020

#146

Post by Pfhreak »

preommr wrote: post #77
Pfhreak wrote: post #8

Earlier quoted context omitted.

I've seen Svelte used in a number of high impact tools, including in AAA videogame UI. In my experience, I've seen engineers very happy working with it, and it meets the performance needs for a videogame it should be good enough for the web.

> including in AAA videogame UI elaborate, please, because this sounds so bizarre. Are they bundling an entire web view and then interfacing it with their game engine? Not only is the tech conceptually weird, I can't think of too many AAA games that have very complex UIs other than maybe the CK series.

Yes, it was two Svelte apps. One for the menus and one for the in game ui/hud elements. Things like health bars, reticles, ability timers, etc.

The interface between the game engine was designed to be as decoupled as possible. The UI could run in a browser with a mocked game underneath it, which allowed the UI devs to iterate very quickly. This also has the advantage of allowing UI to be built before the game had a feature implemented.

Re: State of JavaScript 2020

#147

Post by Pfhreak »

vbezhenar wrote: post #124
preommr wrote: post #77

Earlier quoted context omitted.

> including in AAA videogame UI elaborate, please, because this sounds so bizarre. Are they bundling an entire web view and then interfacing it with their game engine? Not only is the tech conceptually weird, I can't think of too many AAA games that have very complex UIs other than maybe the CK series.

It might be for main menu. I think that WC3 reforged used webview for its menu.

Main menu but also in game UI. Ability timers, weapon reticles, health bars, etc.

Re: State of JavaScript 2020

#148

Post by Pfhreak »

Macha wrote: post #125
Pfhreak wrote: post #8

Earlier quoted context omitted.

I've seen Svelte used in a number of high impact tools, including in AAA videogame UI. In my experience, I've seen engineers very happy working with it, and it meets the performance needs for a videogame it should be good enough for the web.

I would wager that a middle of the road data-heavy web UI actually asks more of their framework performance wise than a video game UI. Compare the number of interactable elements in e.g. a Trello board to a FPS weapon loadout screen. Sure, the consequences of a sluggish UI in a video game can be worse than a sluggish UI in a web app if it's running on the main thread and blocking the game's execution, but plenty of g…

Possibly. It's not just the loadouts though. Reticles and health bars need to animate at least 30 fps if not 60.

Re: State of JavaScript 2020

#149

Post by machiaweliczny »

AltruisticGapHN wrote: post #107
nathias wrote: post #106

I hate TypeScript so much. It feels so antithetical to the web, produces so much redundant bloat to solve a problem that maybe appears for some of the apps with huge codebases, and fails horribly with its obscure error messages.

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.
Post reply on HN