State of JavaScript 2020
2020.stateofjs.com
2020.stateofjs.com
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 addressed state complexity, and GraphQL finally forced backend engineering to coordinate with frontend engineering (i.e., making full-stack engineering efficient).
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.
What I don’t think non-FE engineers often appreciate is just how essentially complex user-dictated mutable state is. Even with immutable data structures (which I love), you can’t get around the fact that a web-app is, by its very nature, a canvas that changes according to human activity. The difference between FE and BE is the difference between painting with fingers and flipping a switch with fingers. Updating a user’s role on the BE is a single SQL operation, but for the FE, it might mean countless changes to the user experience. It’s the difference between storing data and using data. And if there’s anything to conclude from the overwhelming amount of work done on FE tooling, it’s not that people love to try new things (although we do), it’s that the struggle is real.
Side-note: BE gets a taste of FE complexity when dealing with syncing live mutable data among multiple clients. That’s a beast, and the point where everyone realizes that full-stack is the only sensible way to work.
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!)
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.
I agree with this. GraphQL might seem like an interface to query the database, but I think it’s the reverse: an interface to populate the front end.
It is a constant struggle advocating for that when everyone seems to default to expect the GraphQL schema should just model the database tables. But I think it’s worth it. It gives you a fighting shot at heading off otherwise inevitable spaghetti UI code.
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 to switch to X because whatever the team is currently using is "dead"/has gone unsupported.
I think these reasons, along with others such as significant breaking changes between major versions that we've seen with some frameworks and libraries, better hint at sources of frustration over "churn" in JavaScript.
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.
> 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?).
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.
Having said that, Apollo Client’s local field type definitions (akin to GraphQL resolvers for FE state) are as close as a solution as I’ve ever seen.
To add to your point, I do think that most complexity should be delegated to the BE, because the BE is almost always better equipped to handle it.
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.
And according to the ECIS, it was created in part as a poison pill for the web UI platform. Not sure if you were around in the early part of the web’s history but Microsoft had a demonstrated pattern of using pseudo-standards to destroy competitors.
But I guess, I am left unsure of what you’re suggesting. That Facebook should have ported XAML to the web instead of creating React? That would have been... faster? Better?
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 transactions.
It’s liberating to get to a place where I can just update models in the frontend and have that reflected everywhere because, as you point out, there’s enough to coordinate in all the bits you have to mutate.
Edit: we borrowed the idea from how linear.app does it
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.
"Next.js is amongst the top backend framework" - Anybody can tell its popular for frontend!
That is so incredibly frustrating. As a paid professional you would hope your people know how to write code (do their jobs) and churn out original solutions to new problems. Instead it feels like being in a preschool learning to read and being ecstatic that anything gets released.
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 actually get the JS landscape right now (I'm a Vue person but still).
I'm sure in 2 more years everything will blow up again though!
Momentum is a huge factor in programming language popularity, which unfortunately tends to hold back real progress, sometimes for decades. That's why we still write front end code in JS, and why we still write systems code in C. But with the progress of WASM, I think there is a genuine opportunity to create something so much better than JS (or anything that compiles to JS) that it might eventually take over, even if it takes more like 2 decades than 2 years to achieve success.
JavaScript has a quirky and highly dynamic type system, with lots of edge cases that can cause surprises. See the famous "WAT?" presentation for some examples, though that was only a few minutes long and so could only scratch the surface.
JavaScript has awkward syntax, which makes it unnecessarily difficult to write tools and libraries to support it, as well as creating unusual complications like ASI.
Modern JavaScript is trying to be half-imperative, half-OO and half-functional programming, and there isn't enough sensible grammar to go around. This makes various idioms you'd often use in each style in other programming languages awkward in JS, while at the same time not providing some of the best features found in languages more specialised for each style.
JavaScript has a tiny standard library, and what it does have has plenty of inconsistencies and quirks. This, more than anything else, has led to a catastrophically complicated landscape of large JS programs importing on hundreds of relatively small libraries via transitive dependencies, in a tangled mess that probably no-one has ever even looked through on most projects. That's how you get the left-pad fiasco, but more generally, it's a staggering hit on productivity because everyone has to jump through hoops to do even quite simple tasks and often people choose to jump through slightly different sets of hoops that get a similar end result, so now you have multiple ways of doing the same things in your code and extra bloat in your build. It's also a legal and security nightmare just waiting to happen.
TypeScript inherits almost all of the above. It does improve on the type checking, obviously, but even there its type system is actually unsound because its developers made the choice to prefer JS compatibility rather than a completely foolproof type checker. I think that was a reasonable choice, but it doesn't change the fact that the one big feature TS brings to the table is actually flawed because of its JS legacy.
None of this should be surprising to anyone who programs JS/TS regularly, but since my previous comment got heavily downvoted I feel the need to defend it with more concrete and objective criticisms.
Given the importance of web development in the modern software landscape, I truly believe that adopting much better languages -- languages designed carefully, built on solid theoretical foundations, learning the lessons from decades with JS and other programming experience since JS was created, equipped with a good standard library and essential tools -- could bring a qualitative improvement in many important respects, particularly productivity and reliability, across what is now a vast part of the software industry.
I'm not crazy and have no illusions that this will just magically happen tomorrow, but with the advent of WASM, there is at least a chance that with a big backer or two behind it, something new might have a shot at becoming established and, in time, attracting enough support to take over.
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 JavaScript is profoundly more suitable as a language for the web.
2. I appreciate the hybrid style of JavaScript.
3. The small JS std-lib problem is only partially true nowadays, and it is a problem easily fleshed out with tried, tested utility libraries, like lodash.
4. TypeScript/jsdoc do not change JavaScript into the language you want it to be, but simple type hints, in my experience, give it some of that expressiveness of a strict type system with most of the power of a dynamic, loosely typed language.
5. I feel profoundly productive in JS. That is, as opposed to other, more "robust" languages, and many developers feel the same way. In fact, I probably feel most productive in node, though I probably could be close in golang with more practice. As a productive tool, it fits the bill, not just for me, but for many programmers. For this reason alone, I don't see any kind of paradigm shift forthcoming, especially if your alternative is something like Rust, which is a strawman position that I won't knock down.
Unfortunately, even with the useful additions to the language, a lot of the historical baggage is here to stay. The dynamic nature of the language means everything is nullable by default, except with JS there are two distinct null-like values. The type coercion rules have all kinds of strange consequences. It can't make up its mind whether to make standard library tools standalone functions or methods called on something and the two don't compose well with JS syntax, which is never great but particularly annoying if you're trying to write code in more of a FP style. Everything is mutable by default and side effects are totally uncontrolled, with the same observation. Idiomatic JS relies on magical global variables, which differ depending on the platform it's running on. It has exceptions but limited tools for using them systematically, particularly in larger programs.
Obviously vanilla JS is also missing all the benefits of a more expressive and static type system, which is where TS comes in and why TS has rapidly become the preferred option for many front-end developers as they have more code to work on. However, the TS type system is still ultimately dealing with the underlying JS types and the tools JS provides for working with them, which means it's not entirely sound. Even with the TS additions, you still don't get the kinds of algebraic data types and pattern matching that are entry-level features for languages with good static type systems these days.
The standard library is still weak. Yes, it's true that there are many utility libraries you can readily include in your project dependencies to help with that, but that is part of the problem. The benefit of a comprehensive standard library is that everyone has the same version of that functionality available with no extra code required. No need for maybe dozens of extra indirect dependencies in your project because each library you depend on directly has its own preferences for which utilities to use. No need to worry about whether the utility library you picked plays nicely with optimisations like tree-shaking or you've just added extra bloat to your bundle. No need to worry about whether different utility libraries have compatible representations for structured data or follow the same conventions for parameter orders. Lodash and friends are great and they do reduce the problem, but they shouldn't need to exist in the first place.
And all of this has consequences for the whole ecosystem, from the capabilities and performance of the tools we use to work with JS/TS code every day to the dependency hell problem, and also for the general programming knowledge and skill of developers who have primarily or only worked in JS and TS. I don't know your own background, so I don't know how to interpret your feeling that you are highly productive in JS. All I can tell you is that as someone who has also programmed in many other languages and in many contexts away from web development, much of the JS ecosystem is very far behind the state of the art.
I am hopeful that this will improve in time, even if we do get stuck with JS and derivatives compiled down to it. TS is at least trying to improve one aspect, with a better type system overlaid on top. There are build tools now that Just Work for everyday tasks instead of requiring endless tweaking of configuration files and installation of plugins. There is at least one build tool in development that isn't several orders of magnitude slower than it needs to be, unlike every major bundler/optimiser currently in widespread use within the JS ecosystem.
But these incremental improvements, welcome as they are, can only go far as long as the JS heritage underpins everything. The one thing that could improve the performance of the web development community dramatically and across the board, far more than any single new tool or library, is a language designed to do the job properly and taking advantage of everything we've now learned about programming, programming languages and programming for web development.
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.
- 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?
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.
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.
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.
What did Svelte do better than react and vue that you won't go back to them anytime soon?
We've been using Enzyme for a few years at my company. Very recently a new guy introduced testing-library, and oh my god it is so much better.
For one thing, it actually allows to render component on react-native (Enzyme's `mount` doesn't work for some reason) and that's reason enough for me to switch.
Not sure what you mean by “data management” here, but fetch/REST seem like to most predominant, simple, ubiquitous means of handling external data.
Try asking the NYTimes how it's working out for them
`The creator of Svelte, Rich Harris, actually works there!`
`I think it was a passion project from a web dev at NYT`
I would still like to hear more about it, will dig further, thanks.
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: rendered content as HTML, API responses as JSON or other forms, etc.
And then there are what I would call back-ported front-end frameworks, or semi-static site hosts. These are Next.js and Nuxt. As far as I can tell, these can be used to build traditional server-side application logic but they seem intended to host "pages." For example, in looking over Next, I see it does have the ability to expose API routes, but this seems very much a second-class citizen. The Next documentation [1] says "Next.js has support for API Routes, which let you easily create an API endpoint as a Node.js serverless function." This seems to be provided as an escape hatch, but it doesn't appear to be the core focus of the framework.
Is this distinction real or am I sadly misinformed of the, ahem, state of JavaScript?
SSR means that it runs on a server (of course), so it's not too hard to expose basic server functionalities for when you just need a basic endpoint, but you wouldn't want to build a backend on that. It's more akin to dropping a PHP file on a server because you just need a bit of code to run server-side (ie to do some auth with a 3rd party without exposing an API key to the frontend).
And your summary of Next.js API Routes is correct as well. As an example, I have a site built in Next that needs to be able to query data off of a SQLite database. Back in the old days I would have set up a simple PHP server of some kind… today I might have knocked something crappy together in Node… but in Next, you just point at a route, grab the SQLite database out of the filesystem, and look over your query parameters. It's really neat.
I am comfortable with c/c++/python/sql/java in an enterprise context. Might some folks help me get back into the JS world? Do I need to sit down with a JavaScript 1.0 book and go from there?
Honestly just play around and try not to let the size of the landscape get to you. Unlike some JS devs seem to believe, you don't need to know everything about everything to get going.
"Testing Library" is the top testing library apparently? Had to check that this was an actual library, I'm sure many people just left it as a 'whatever' choice.
Someones data is dirty dirty dirty
Personally I'm not surprised that testing-library came out so high in satisfaction; its an incredibly useful layer over Jest and and incredibly popular in React-land.
Par for the JavaScript community course.
The jump from "whatever js was in 2014" -> angularjs junk -> react/vue/angular was pretty big.
But now the glamour is gone and we're moving into the phase of actually having to maintain some of the things we built and the wear from bad decisions is starting to show.
-----
Svelte also seems like the cool new kid on the block. Svelte surprises me in how much people fawn over it. I really don't understand the hype since I don't think it's a huge jump forward, and there's also a lot of "misunderstandings" about it in comparison to other frameworks.
Like one thing I've seen a lot is people mention how it requires less code, but it's not that much smaller. It just looks smaller for small test cases where there are like 8 lines of code or because svelte makes stylistic choices that have tradeoffs that aren't immediately obvious. If you take a loot at react/vue, they're not that much bigger for realistic component size.
Anyways, front-end framework discussion is long and muddled and confusing. I wanted to make a point of how svelte people often confuse the engineering/implementation vs the philosophical approach in frameworks. Things like svelte's bundle size being smaller is because other frameworks don't put as much emphasis on it. I was going to say that react is bloated and that preact is much smaller, but looking it up it seems like somehow react is 2.6kb, preact is 4kb, and svelte is 1.5kb. Angular is 62kb. Which proves two points, react/vue can be smaller if it wants, the approach it takes doesn't limit it and that things move so fast that somehow preact makes bigger bundles than react.
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.
```
<script src="https://cdn.jsdelivr.net/npm/vue@2.6.12/dist/vue.js"></scrip...
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. React is a little bit harder because of jsx, but it's still not that much more complicated.
Build-wise, parcel supports jsx/vue files out of the box. Plus React/vue both have cli tools that I don't like and wouldn't recommend, but are super easy to get started with.
And this all comes with the giant caveat that react/vue make progress which can lead to confusing versions. Svelte is a lot younger (kind of, it came out a few years back, so idk) so it hasn't had to cross that bridge yet. And even then, there was the confusion with Sapper. I highly doubt that svelte is going to be immune from the fast-paced nature of these frameworks.
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
So a lot of the abstractions that make life pleasant simply go away.
The in-browser dev tools (svelte tools) lag far behind vue dev tools but it's newer.
react is used with react-dom [1] which is a 121kb minified[2]
[1] https://www.npmjs.com/package/react-dom [2] https://unpkg.com/browse/react-dom@17.0.1/cjs/
I can see how that'll turn around to bite me once the code base gets more complicated though
React can’t get any smaller because of the approach, not because they don’t want to. That’s why it doesn’t include so much out of the box (eg styling, animation, state management).
TLDR:
- it comes with batteries included
- mutable syntax is the simplest possible mental model
- sugar syntax for very common tasks is a norm, including for state management
- docs are fast and good
- internals are simple to understand (i can genuinely fork it if i ever disagree with decisions - good luck doing that for react)
- and other smaller items.
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?
Well, first reaction for most people would be I am offended by this. But, I am speaking from the heart. This is exactly how I bloody feel, change my mind. The entire frontend ecosystem including browsers and the horrible mess that html/css/js is needs to be redone properly from scratch. Unfortunately, we can't because we've dug ourselves deep into this hole. How do we get out of this?
/rant
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 important thing to remember is that engineers are doing complex engineering at every layer of the stack. And that because of environment and targets they are building for, they've made some tradeoffs around their development.
This is funny because waiting for typescript to build is probably double or even triple waiting for my .NET project to compile at this point. I swear it gets slower every update.
Any app that grows to a certain size will slow down to a crawl on incremental builds.
https://raw.githubusercontent.com/evanw/esbuild/master/image...
But I will try!
Naturally I am not doing SPAs in this case, just vanilla JS and web components.
The FE/BE split builds are only in SPA projects, with BE being mostly about WebAPIs.
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 much wrong with this argument and haven't scratched the surface.
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.
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 mess of bad practices everywhere.
Now if you take a look at development outside of front-end and go to some large non-tech, mid-sized, or small business you'll probably also find poor practices (from my experience), but nothing like the mess I see in these same organizations trying front-end development now.
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.
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 now. There’s certainly a lot more fun to be had remaking everything in React though.
I'm mainly a backend developer so can't comment on how this tradeoff works out when you have the resources for artistic UI/UX folks and reduced development pace.
A good example is React Native which is less about React but more about a js interop layer with Cocoa that happens to use React for the rendering.
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.
Certainly, as I am finding out. Can you suggest some solid, robust frontend framework that doesn't break in 3 months when I update the dependencies?
Give Svelte a try online, their tutorial page is pretty slick: https://svelte.dev/tutorial/basics
But JS is outstanding on this mess: https://httparchive.org/reports/state-of-javascript
Please note that this is transfer size. So if some script like jQuery 1.X is 90kb minified, but compressed is like 30k.
That's why we shouldn't asking ourselves why some users using a 3rd party tools to disable trackers, ads (like PiHole) or even disable JS using browser extensions.
And now good news... this time Google. Google are making Core Web Vitals: https://web.dev/vitals/ trying to evaluate sites using CrUX RUM. And soon they will this will be included in ranking algorithm: https://developers.google.com/search/blog/2020/11/timing-for...
This announce make most of webmasters freaking out about web speed finally.
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.
This is precisely my fear [1]. I need something robust and will continue to work for a good foreseeable future.
Do you recommend Angular for frontend? I've just tried React and Svelte, but I am told to stay away from Angular as a giant beast.
It's fantastic for large applications. I've used it in a large product with hundreds of pages and forms and dialogs, and it would have been a nightmare without the sort of structure that Angular provides. It reminds me of Rails a little bit, in that it's opinionated about how things should work and you might feel some friction if you try to do something unusual.
I honestly don't agree for Ember at least. Enterprise development is prone to having apps untouched for years and once an Ember application gets that out of date, the route to getting it in date again is... difficult. Have seen with with applications on 1betaX versions, 1.13, 2.14 and no route forward without significant rework, which means they're largely incompatible with the ecosystem now.
The package-lock.json file and the `npm ci` command should take care of any issues like that nowadays. Yarn has also always had its lock file. I wonder what was the root cause here? Did your repo have some deps coming from some other registry than npmjs.com?
I’ve never even considered going to YouTube, of all places, for JavaScript documentation. What’s next, people reacting to JavaScript programming?
> 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.
Took me 2 hours to just to find out that some module wasn't compatible with Node version 15.
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.
I forgot about Unity. Yes, Unity is another offender here. One of the many reasons I quit working with it.
> "another offender"
Be careful, it's a nasty fall off that high horse.
and re. these earlier remarks:
> Windows and Mac OS
Windows and Mac OS most definitely have experimental/preview releases and standard releases. Microsoft offer extended support options, and ultra-marathon ESU contract support for products as far back as Windows Server 2008.
Same goes for most commercial RDBMS. Heck, even Oracle has a preview release.
> anything outside of Linux or Node
Linux stopped using alternating version numbers in 2004, so I'm afraid your information there has passed even Microsoft's extended support period. For the curious, though, GNOME still uses the even/odd versioning as a lifecycle indicator, but has plans to abandon it this year. I hope Node will do the same, because of all the numbering styles this is certainly the most confusing.
As for Java, only a dyed-in-the-wool government bureaucrat could possibly love Java's approach to ecosystem engagement. "Let's have seven years of committee meetings and experimental feature flags for the new GC". Ugh.
Standing back, this just sounds like a grumble about terminology, because almost _everyone_ has some kind of leading-edge release and some kind of stable release, the only difference is the naming, and that doesn't seem to me the basis of a substantial complaint. If the core issue is inconsistencies about which one is installed by default, then that is a complaint I'd suggest best leveled at package managers, because there is no universe available in which every software project is going to somehow magically converge on a single lifecycle policy.
It's exactly the lack of label on non-LTS versions I'm talking about. It has a real impact on people, looking at which version to install, and having no guidance that "this version not labeled in any special way, yeah, probably don't use that". And no, digging into the developer mailing list to figure out what the versioning malarkey a particular project is using is not a documentation of it.
What's more, this gripe alone won't solve anything, since no-one is going to conform to anyone's expectations but their own in regards to release policy.
There is some hope though, recent standards like web components and ES imports help a bit.
I admit I feel I share some of your frustrations. In the past I have written production frontends in Angular and experimented with Vue and React. Out of all of them I found React to be the most enjoyable, but even then I still struggled with project setup and found the tooling confusing. I even quite like TS as a language, but I feel it's still quite limited by the fact it transpiles to JS.
Recently, I discovered yew [0]. It is a Rust framework for building frontends using wasm. I really appreciate the robustness that Rust brings such as ownership checks and ADTs. I don't think it's for everyone, but it may be worth looking at if you perhaps find modern frontend development confusing frustrating. I've found it to be quite the breath of fresh air.
If you do decide to have a look I found the examples [1] and getting started guide [2] very informative.
[0] https://github.com/yewstack/yew
Next time I build a team, I might consciously choose a mix of stable experienced senior devs, and perhaps a couple of young ignorant-but-brave junior devs. Horses for courses.
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 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 don't even need jQuery these days. All the important functionality is now in the DOM by default.
React reference documentation?
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, but then what is the practical outcome?
Problem is there seems to be no middle point? I can’t write vanilla js now on new project, typing structures like json messages is bare minimum.
The problem with Ts is even if you don’t want to use it "like an expert" there is no beginner use, you will very quickly run into complicated abstractions and all kind of typescript errors due to fluidity of js language.
So I think native js typings is our only hope but when you see how crappy some vanilla js syntax is, what they did with classes, I’m not holding my hopes up.
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 [] }
Then you need to figure all kind of shenanigans with Vetur/eslint... just wasn't worth the hassle, may as well use TS.
Webstorm might suit you better.
This meme needs to die. You can argue that it's painful and clumsy, but not that it's "like a global variable". The _whole_ point of redux is to offer global state without the problems of global variables. Interacting with the global state through actions, selectors and subscribers prevents the problems of global variables.
Is it clumsy/verbose/confusing/whatever? There's definitely arguments for it. But people stop thinking when they see the word "global" and make terrible arguments against Redux.
Front-end is an absolute shit show with all the html/css/js mixture.
Do not forget Web is delivering to a lot of platforms. Try the same with desktop apps or mobile apps. Good luck.
the survey didn't reach all of the js programmers for sure.
methinks the 95% others are too busy writing ada95
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.
What are you trying to get out of insulting people like me? Are you trying to get us to come seek you out as a teacher? Do you want us to feel ashamed of out careers and realize we need to go back to school?