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

171–180 of 189 posts

Re: State of JavaScript 2020

#171

Post by franklyt »

Silhouette wrote: post #170
franklyt wrote: post #166

Earlier quoted context omitted.

I agree with some of what you're saying. Points of contention: 1. It's not necessarily interesting to point out what JavaScript was as a rebuttal of what it is . This is a genetic fallacy. If you think that some mistakes are baked into the cake - you're probably right, though you'd need to expound on that point. However, if you compare JavaScript today to the original JavaScript spec, it's not even close: modern Java…

FWIW, everything I wrote before was intended to refer to JS and TS as they are today. I would certainly agree that today's JS is much better than the JS of the pre-ES6 era, but the JS of the pre-ES6 era was objectively one of the worst programming languages ever to gain significant adoption, so that's not exactly a high bar to clear. Unfortunately, even with the useful additions to the language, a lot of the historic…

Care to share what you think would constitute a “good” lingua franca for the web?

Re: State of JavaScript 2020

#172

Post by amw-zero »

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 declarative UI. Microsoft had XAML and data binding well before Backbone, Angular, and React.

I personally love where web UI is at today, but I get the sense that we think it’s full of these unique problems when it’s really not.

Re: State of JavaScript 2020

#173

Post by tjchear »

davidwparker wrote: post #157
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…

Looking to jump into Svelte and would appreciate your opinion.

What did Svelte do better than react and vue that you won't go back to them anytime soon?

Re: State of JavaScript 2020

#174

Post by Silhouette »

franklyt wrote: post #171
Silhouette wrote: post #170

Earlier quoted context omitted.

FWIW, everything I wrote before was intended to refer to JS and TS as they are today. I would certainly agree that today's JS is much better than the JS of the pre-ES6 era, but the JS of the pre-ES6 era was objectively one of the worst programming languages ever to gain significant adoption, so that's not exactly a high bar to clear. Unfortunately, even with the useful additions to the language, a lot of the historic…

Care to share what you think would constitute a “good” lingua franca for the web?

I think it is precisely the development of WASM as an alternative first class citizen to JS that has the potential to create a new lingua franca.

As for what we might one day build on top of it, I'm not sure the ideal language or languages exist yet. I do think there is the potential to have something that retains the relative ease of access that languages like JS, Python and Ruby have offered, but with a much better type system, and perhaps designed with the kind of API-heavy and event-driven programming we use on both the front and back end of many web apps in mind.

I suspect that to break into such a huge ecosystem, it would need to have almost transparent interop with JS so in the early days it could use the existing libraries, though I would also hope that many of those libraries would immediately be obsolete or would soon be replaced by native alternatives anyway given that most of them are relatively basic by general programming standards.

Re: State of JavaScript 2020

#175

Post by turtlebits »

preommr wrote: post #91
turtlebits wrote: post #86

Earlier quoted context omitted.

Svelte is a a breath of fresh air because of its simplicity, not because it's bundle size (which is a bonus). It's especially easy to get up and running and the documentation is great. React/Vue/Angular you have to learn the build system as well as the ins and outs of the framework, and there are too many opinionated ways of getting started.

How is this complicated: ``` " rel="nofollow">https://cdn.jsdelivr.net/npm/vue@2.6.12/dist/vue.js"> var app = new Vue({ el: '#app', template: "{{message}}" data: { message: 'Hello Vue!' } }) ``` A lot of the build problems with react/vue also exist with svelte. In fact it's even worst with svelte because it's compiled only (which is it's unique selling point) whereas vue can be used in a much more progressive manner.…

While that works, you won't get very far without having to switch over to a build system, then learn how to configure/use that.

Look at VueJS and React installation pages and it's easy to see the problem with modern frameworks.

https://v3.vuejs.org/guide/installation.html#release-notes https://reactjs.org/docs/add-react-to-a-website.html

Re: State of JavaScript 2020

#176

Post by franklyt »

tstrimple wrote: post #66
halfmatthalfcat wrote: post #19

Earlier quoted context omitted.

How is JS and it’s ecosystem any less mature than Go or Rust? There’s a plethora of mature frameworks, build tooling and patterns on the frontend as well as a lot of cutting edge competition that creates a lot of noise. The point is though that there’s just a lot going on in JS world. Doesn’t mean it’s any less than any other language and it’s ecosystem.

The bar for participation is dramatically lower for JS. I think that's unequivocally a good thing, but it does lead to explosions of libraries and toolchains of questionable quality which iterate rapidly. There is SO MUCH JS stuff out there that even just the bad stuff greatly outnumbers what you have in Rust or Go. It's the same reason why PHP has such a bad reputation. It was used and abused by non-developers just…

If you’re developing a library that people use, it’s not because the bar is “low”. An amateur engineer doesn’t develop popular or useful technology overnight.

Re: State of JavaScript 2020

#177

Post by franklyt »

AltruisticGapHN wrote: post #160
machiaweliczny wrote: post #149

Earlier quoted context omitted.

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 autocomple…

Your problem might be that VSC is not an “IDE”, so you’re only going to get the support you ask out of it.

Webstorm might suit you better.

Re: State of JavaScript 2020

#178

Post by franklyt »

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.

Ts-check + JSDoc feels great.

Re: State of JavaScript 2020

#179

Post by franklyt »

Silhouette wrote: post #174
franklyt wrote: post #171

Earlier quoted context omitted.

Care to share what you think would constitute a “good” lingua franca for the web?

I think it is precisely the development of WASM as an alternative first class citizen to JS that has the potential to create a new lingua franca. As for what we might one day build on top of it, I'm not sure the ideal language or languages exist yet. I do think there is the potential to have something that retains the relative ease of access that languages like JS, Python and Ruby have offered, but with a much better…

Thanks for your thoughts. The notion of there being no sufficient existing language for web development is an interesting one.

Re: State of JavaScript 2020

#180

Post by wildermuthn »

viraptor wrote: post #95
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…

> 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) often look like denormalized REST endpoints. This is particularly true in Relay (do people still use Relay?) In such a case, you’re right that FE-BE coordination doesn’t change much. Additionally, FE stores like Redux are still central to managing derived data necessary for component rendering.

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

Example: having top-level queries for “users” vs. “profiles”. The first has all the data about a user, the second has all the data required to render a user profile page, which almost always includes more data. Let’s say there is a profile photo. A denormalized scheme just defines a "user.profileImage" as an Image type and returns data from a DB relationship of a similar sort (knex and other tools make this easy). While this might seem fine, it is the start of the same old story — BE being blissfully unaware of the use of its data in the context of the user experience. Perhaps when a user has no profile photo a default one should be shown based on their “organization” profile photo. No problem, just pull “user.organization.profilePhoto”? Well, okay, but maybe that is missing too, and we... go down a FE rabbit hole when all we really want is a stupid URL to an image!

The alternative I’m suggesting, one that forces FE and BE (ideally one team) to talk about the user experience, is to have a “profile.photo” schema that is resolved on the server. The result of this pattern is a GraphQL schema that accurately describes the user experience.

I took the dumbest example possible, but in short, this pushes a lot of complexity to the server where it truly belongs. The FE should be as light, dumb, and functional as possible. The BE should understand comprehensively how their data is going to be used in order to design data models that are efficient.

Moving from a denormalized GraphQL schema to a UX GraphQL schema is a liberating experience for everyone involved. The BE cares about the product as much as the FE. This gets them that much closer to the user, where they ought to be. And to your point, this enables the BE to identify potential resolver bottlenecks (and to design for them rather than hacking around them) before such problems ever appear.

Post reply on HN