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

71–80 of 189 posts

Re: State of JavaScript 2020

#71

Post by tashoecraft »

erlich wrote: post #65
Pfhreak wrote: post #41

Earlier quoted context omitted.

I think you have a fairly dated understanding of what front end is, it's scale, and the complexity of delivering an experience that's fast and well optimized. These days front end engineering can be every bit as rigorous and complex as back end engineering. The constraints are a bit different, and the environments are very different, but the scale and complexity of engineering is not.

Do you ever wonder whether we cause the complexity ourselves. Did we need React? Flux? Graphql? Since we introduced these concepts we needed to rethink a huge amount of other stuff to keep it performant. Compare the simplicity of jQuery vs a modern tool chain. Like creating a form. It gets pretty insane with React. And jQuery would be dead simple. You have to stay on the bandwagon because it’s where the community is…

It’s pretty clear you haven’t worked on any modern front end site. Go and try and build any front end site demanded by most business owners in jquery. It’s not just bandwagon, it’s solving problems in the environment in which they are required with the tools that are present. It’s so incredibly naive to think the efforts of tens of thousands is all pointless if they just used this one tool.

Re: State of JavaScript 2020

#72

Post by jakelazaroff »

erlich wrote: post #65
Pfhreak wrote: post #41

Earlier quoted context omitted.

I think you have a fairly dated understanding of what front end is, it's scale, and the complexity of delivering an experience that's fast and well optimized. These days front end engineering can be every bit as rigorous and complex as back end engineering. The constraints are a bit different, and the environments are very different, but the scale and complexity of engineering is not.

Do you ever wonder whether we cause the complexity ourselves. Did we need React? Flux? Graphql? Since we introduced these concepts we needed to rethink a huge amount of other stuff to keep it performant. Compare the simplicity of jQuery vs a modern tool chain. Like creating a form. It gets pretty insane with React. And jQuery would be dead simple. You have to stay on the bandwagon because it’s where the community is…

If all you’re doing is submitting a form with Ajax, sure, jQuery would be fine. But I’ll venture that most frontend apps are at least somewhat more complicated than that.

My side project is a web app that lets you create music visualizer videos. There’s a ton of UI, state, complex interaction between parts, etc. If I weren’t using React, I’d be using something — but it would surely be another full-on framework, not a simple library like jQuery.

Re: State of JavaScript 2020

#73

Post by jakelazaroff »

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.

And yet, there’s no other platform where you can go from an idea to something easily accessible by anyone in the world — in a span of minutes.

Re: State of JavaScript 2020

#74

Post by jakelazaroff »

Frost1x wrote: post #62
Pfhreak wrote: post #41

Earlier quoted context omitted.

I think you have a fairly dated understanding of what front end is, it's scale, and the complexity of delivering an experience that's fast and well optimized. These days front end engineering can be every bit as rigorous and complex as back end engineering. The constraints are a bit different, and the environments are very different, but the scale and complexity of engineering is not.

I believe you might have a slightly biased view of what front-end development largely looks like. What you're describing is the type of front-end development that goes on at the organizations that actually develop these frameworks. The vast majority of front-end development outside of that world is misguidedly trying to mimic that complexity on their static business informational page they maintain with a duct taped…

If someone is making a static business informational page, it’s significantly more likely that they’re using WordPress and jQuery than e.g. React [1]. Like, significantly significantly — 20x more likely to be using jQuery (which is on a full 83% of all webpages) than React, and 30x more likely to be using WordPress than Gatsby or whatever.

People on HN talk about React and friends because they’re building client-side apps that deserve full frameworks. But it’s absolutely not representative of most web development.

[1] https://css-tricks.com/how-the-web-is-really-built/

Re: State of JavaScript 2020

#75

Post by Pfhreak »

Frost1x wrote: post #62
Pfhreak wrote: post #41

Earlier quoted context omitted.

I think you have a fairly dated understanding of what front end is, it's scale, and the complexity of delivering an experience that's fast and well optimized. These days front end engineering can be every bit as rigorous and complex as back end engineering. The constraints are a bit different, and the environments are very different, but the scale and complexity of engineering is not.

I believe you might have a slightly biased view of what front-end development largely looks like. What you're describing is the type of front-end development that goes on at the organizations that actually develop these frameworks. The vast majority of front-end development outside of that world is misguidedly trying to mimic that complexity on their static business informational page they maintain with a duct taped…

Perhaps, I've only seen front end projects at FAANG and personal projects. That said, my front projects have at least an eslint config and usually a CI/CD deployment strategy if not full on tests.

Re: State of JavaScript 2020

#76

Post by ricardobeat »

Pfhreak wrote: post #54
ricardobeat wrote: post #38

Earlier quoted context omitted.

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.

Not 'his', 'their', but yes, I agree that the projects being done on the web are hugely complex these days and have a rich set of building, linting, releasing, testing, etc. tools.

corrected, thanks.

Re: State of JavaScript 2020

#77

Post by preommr »

Pfhreak wrote: post #8
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?

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.

Re: State of JavaScript 2020

#78

Post by cozuya »

systemvoltage wrote: post #50
inopinatus wrote: post #35

Earlier quoted context omitted.

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…

I am struggling with this. I have made an Amazon storefront in React JS + npm package manager after watching this tutorial. I must have deleted the node_modules folder a dozen or more times and if you npm install again, it works! This is the kind of stuff that makes me wonder, how can I make a production worthy app without the fear of not being able to fix the dependencies!? Took me 2 hours to just to find out that s…

Why would you default to using the non long term support version? Would you do that for, say, ubuntu?

Re: State of JavaScript 2020

#79

Post by inopinatus »

cozuya wrote: post #78
systemvoltage wrote: post #50

Earlier quoted context omitted.

I am struggling with this. I have made an Amazon storefront in React JS + npm package manager after watching this tutorial. I must have deleted the node_modules folder a dozen or more times and if you npm install again, it works! This is the kind of stuff that makes me wonder, how can I make a production worthy app without the fear of not being able to fix the dependencies!? Took me 2 hours to just to find out that s…

Why would you default to using the non long term support version? Would you do that for, say, ubuntu?

It’s an easy blind alley to blunder down on some platforms. If one’s package manager defaults to edge versions and you’re just getting standard with a new language/framework via a tutorial, for example, this is how you learn there’s an LTS release the hard way. Homebrew users on Mac are common victims, but similarly Arch Linux or FreeBSD may trap the unwary (and for more besides than merely Node)

Re: State of JavaScript 2020

#80

Post by moron4hire »

cozuya wrote: post #78
systemvoltage wrote: post #50

Earlier quoted context omitted.

I am struggling with this. I have made an Amazon storefront in React JS + npm package manager after watching this tutorial. I must have deleted the node_modules folder a dozen or more times and if you npm install again, it works! This is the kind of stuff that makes me wonder, how can I make a production worthy app without the fear of not being able to fix the dependencies!? Took me 2 hours to just to find out that s…

Why would you default to using the non long term support version? Would you do that for, say, ubuntu?

Why are there "not-LTS" versions are all?
Post reply on HN