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

31–40 of 189 posts

Re: State of JavaScript 2020

#31

Post by gerdesj »

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…

Is that why as a security focussed bod I get to read this sort of thing: https://googleprojectzero.blogspot.com/2021/01/introducing-i...

Re: State of JavaScript 2020

#32

Post by Aldipower »

cosmodisk wrote: post #27

If the healthcare sector would apply the same ideas and principles of the front-end industry, it'd look like this: oh,look, it's a pen! Why don't we combine it with a scalpel and an angle grinder for our next surgery? Front-end is an absolute shit show with all the html/css/js mixture.

You mean _Web_ Front-End.

Do not forget Web is delivering to a lot of platforms. Try the same with desktop apps or mobile apps. Good luck.

Re: State of JavaScript 2020

#33

Post by systemvoltage »

fctorial wrote: post #30
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…

> no real good books React reference documentation?

Yep, I've resorted to that. But, there is more to docs that's needed to get wisdom from others who've built large apps and getting that in a concise book format would be nice. Otherwise, we can all throw away all books written about any programming topic, right?

Re: State of JavaScript 2020

#34

Post by cosmodisk »

factorialboy wrote: post #12
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 think it's about individual maturity than tech-stack. Frontenders are likely to be younger than backenders, and some of the traits you observed are a result of that.

Maybe,but it's not the kids who sit at the top of the food chain in places like language committees, standard agencies, or even the CTOs of this world ( the real ones,not those of 5 person startups) where things get decided for years or even decades ahead.

Re: State of JavaScript 2020

#35

Post by inopinatus »

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…

Unfortunately yes. In all my four decades in tech, code bitrots in the the web front-end environment faster than any other I've yet seen. The Javascript language in particular (and its ecosystem) remains a baroque Gormenghast of curiosities built on an ancient sewer where nightmare beasts still roam, and everyone's holed up in the throne room hoping a few trusted paladins will somehow decontaminate the rest.

> How do we get out of this?

Personally, I try to use as little JS as possible. CSS is in better shape and handles a ton of page-level behaviours, HTTP/2 has done wonders for round-trip responsiveness, such that server-rendered HTML still holds the productivity crown for building out MVPs and SaaS application interfaces and the like.

When I absolutely must write JS, I'll tend towards typescript these days, and minimise dependencies to the point where I hopefully have no node_modules/ or bundler at all.

Re: State of JavaScript 2020

#36

Post by typeengineering »

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 the cool prototypal programming language like JS. yet I bet 95% of the JS "community" hasn't even got a clue what a prototype is. 3. Additionally, you can see how the tools are skewed towards react/webpack but server-side JS can be just as powerful, yet there isn't much innovation in there. So that confirms the previous 2 points that the "state" of javascript, is just a homogeneous webpack/typescript bunch of people who think the exactly same.

There are so many real engineers who work with proper programming languages, and they get terrified when they see the "state" of javascript and curse it. I've worked with JS for the past 5 years and I don't blame them. There hasn't been a professional approach to software development in the JS world, everyone's obsessed with their tools instead of applying skill. But I'll change it this year. If you're a back-end engineer looking for a simple, yet very powerful solution to build your js/widgets, you'll get it soon. not free thank you.

Re: State of JavaScript 2020

#37

Post by jamesgeck0 »

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…

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 your dependencies in your repo as zip files, just in case), but a lot of libraries are still the wild west.

There are "boring" frameworks like Ember and Angular that move slowly and limit breakage, but they're pretty unpopular with many developers, despite being great for building products in an enterprise setting.

I disagree strongly about browsers; 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.

Re: State of JavaScript 2020

#38

Post by ricardobeat »

systemvoltage wrote: post #28
Pfhreak wrote: post #14

Earlier quoted context omitted.

I've worked in front end and backend systems. I've worked with extremely high scale web services at FAANG. I've made videogames, and done data processing pipelines. In general, I find that people will look at the domain outside of their area of expertise and say, "Holy shit, how do you work like this?" All the front end devs are like, "You have to wait how many minutes for compile times?" for instance. I think the im…

> All the front end devs are like, "You have to wait how many minutes for compile times?" for instance. This is a shocking argument coming from any front end dev. Since when is static type checking, working on serious big repositories that take time to compile, have proper architecture with hundreds if not thousands of programmers working on it comparable to 3 frontend folks working on a web application? There is so…

That's an odd comment to make, you just inadvertently proved their point. Most large web products are serious (?), have 'proper architecture' and hundreds of frontend developers working on them. Google products, Spotify, AirBnB, JIRA/Atlassian, Booking.com, Trello, GitHub.. you name it. You may also notice TypeScript in the first paragraph of the report, which is a type checker and has been enjoying massive adoption.

Re: State of JavaScript 2020

#39

Post by somehnrdr14726 »

If I were trying to compare technologies I might focus on metrics like release strategy, documentation quality, scale of existing products using it, and maintainer activity.

This survey comes out every year and tells me who is winning the social media popularity contest. Technologies labeled as "Avoid" have over 50% respondents saying they don't even use the technology. Avoid it why? Because I won't be trendy at the javascript meetup? Does anyone actually use this data to drive decisions?

Re: State of JavaScript 2020

#40

Post by john-shaffer »

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…

The situation with Clojure/ClojureScript is a lot more stable. Most libraries are pretty rigorous about backwards-compatibility. When someone comes up with a better approach, they release it as a new library under a different name instead of making breaking changes to the old one. You will probably still need to pull in some npm packages, but you can cherry pick those and keep it to a manageable number.
Post reply on HN