State of JavaScript 2020(2020.stateofjs.com)
2020.stateofjs.com
State of JavaScript 2020
https://2020.stateofjs.com/en-US/
188 comments
> 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!)
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.
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.
> a well-designed GraphQL schema looks like the shape of data required for component rendering, i.e., for the user experience.
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.
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.
> 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.
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.
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.
I think the switches are driven by recruiting just as much as the old thing being “dead” in itself.
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.
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.
While I think it's important to fight against the "FE is easy; BE is real programming" stigma, I think you're going bit too much in the other direction. You're painting FE almost as the most difficult thing that exists. However, it's not like GUI applications is a new thing. GUI applications which talks to the Internet is not exactly groundbreaking either.
> 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?).
> 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?).
You are right about JS fragmentation. After doing 10+ years of frontend, my theory is that frontend welcomes a lot of new self learnt programmers mostly because the browser is the runtime and almost every device has it. This means it’s pretty easy to stitch a few things and get something useful in the hands of customers. Npm makes it very easy to create new packages and libraries. All though not a significant % of community has computer science background and deeply understand what goes under the hood.
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.
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.
You’re right, I did go overboard. The hardest thing I did last year was battling race-conditions for concurrent BE operations. By far. But your point about some BE problems being solved and Cocoa state management still receiving complaints, suggests that browser state management still remains an unsolved problem.
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.
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.
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.
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.
Xaml was released two years before Backbone, and only
five years before React. It’s a contemporary of those efforts not a predecessor.
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?
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?
[deleted]
Agreed. It becomes really messy moving all that state around.
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
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
Where and how does conflict resolution happen?
The clients are all up to date on changes fairly much instantaneously. And then updates from a client are synchronous in terms of setting all data and having that bundled and sent as a single request which is executed as a single dB transaction (we only send the specific fields that were updated).
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.
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.
This post from stateofjs has to be taken with a spoon of salt!
"Next.js is amongst the top backend framework" - Anybody can tell its popular for frontend!
"Next.js is amongst the top backend framework" - Anybody can tell its popular for frontend!
I’m sure they’re well aware and had to draw the classification line somewhere. Next definitely fits in both but IMO really differentiates itself on the backend with SSR.
This is the biggest problem I have with being paid for front end development. In the corporate world the only focus is on the tools and how to write code. Thoughts of product development and product quality are almost exclusively absent.
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.
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.
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 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!
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!
Maybe it’s my bubble but I’ve seen a slight retraction from typescript in the past year.
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 clumsy syntax because of the JS legacy, and an illusion of being safer than it actually is again because the decision to favour JS compatibility means you can break the type system.
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.
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.
JS isn’t going anywhere.
Not any time soon, certainly. But it really should do. It's a language that was designed hastily and without a solid foundation. That was no big deal at the time, but it causes a horrible loss of quality and productivity now that it has become one of the most-used programming languages in the world.
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.
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.
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 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.
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.
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 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.
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.
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.
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.
Thanks for your thoughts. The notion of there being no sufficient existing language for web development is an interesting one.
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?
- 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.
I’m also working with Svelte for my (non-AAA) game, and enjoying it thoroughly. The only problem I find is that complex animations/transitions can get a little messy (compared to say GSAP timelines), and it tends to create a lot of garbage out of the box so some tuning is necessary to avoid GC thrashing.
Do you have any info on that AAA game? I would be curious to read up on how/why they used svelte.
> 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.
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.
A lot of games have storefronts for DLC. I've seen these used as webviews, especially payment forms.
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.
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.
It doesn't surprise me. 5 years ago the standard solution was Scaleform, which is pretty much the same thing but with Flash.
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 games update their UI less than once a frame, or run it in a separate thread altogether.
Possibly. It's not just the loadouts though. Reticles and health bars need to animate at least 30 fps if not 60.
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.
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.
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.
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?
What did Svelte do better than react and vue that you won't go back to them anytime soon?
> Testing Library is quite new in the town but already the runner up testing tool
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.
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.
> “In terms of data management, GraphQL holds its position on the top while good-ol Redux kept losing interest.”
Not sure what you mean by “data management” here, but fetch/REST seem like to most predominant, simple, ubiquitous means of handling external data.
Not sure what you mean by “data management” here, but fetch/REST seem like to most predominant, simple, ubiquitous means of handling external data.
When I read that I immediately thought about GraphQL subscriptions. I don't know whether this will a bottleneck, but perhaps it makes sense to route everything through GraphQL, this means: someone updates via GraphQL and everybody listening gets an event by subscriptions.
> - Svelte is hyped, but is it battle tested enough?
Try asking the NYTimes how it's working out for them
Try asking the NYTimes how it's working out for them
First, I hate paywalled news sites. Second it sounds more like inbreed than a battle thanks to reddit friends.
`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.
`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.
Every time Javascript is discussed, the discussion turns negative. Fact of life is that the browser is THE cross platform app, and people have differing opinions on how things should be done.
It’s because the majority of jobs are front end web jobs, which is annoying you don’t do that kind of work. And you kind of wish people on the FE would just do things that backend way so you could have access to that job pool.
Many are just exhausted with WordPress turned React devs writing piles of spaghetti code rife with unnecessary (and often poorly maintained) dependencies.
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: 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?
[1] https://nextjs.org/learn/basics/api-routes
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?
[1] https://nextjs.org/learn/basics/api-routes
That's about right. I wouldn't call Next a "backend framework", it's an SSR framework.
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).
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).
Yeah, that's about right. I was also surprised to see Gatsby and Next.js listed in backend, but it makes a weird kind of sense. I think "static site generators" would be a better umbrella, but it's a shady distinction for sure.
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.
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.
Next.js is mostly about server side rendering. If you look at something like nest.js it offers a more familiar backend with more structure. Because you can write your backend these days as serverless functions which just make api calls to other hosted services - the traditional backend framework (orm + routing) becomes less relevant.
I wouldn’t call express a framework though. It’s just a web server with some middleware ecosystem.
I’ve heard some people refer to Next-like frameworks as “middle-end” to highlight their specific intersection of concerns.
Every year I see these reports come out and every year I'm more jealous of JavaScript/front end developers. I know the landscape is complicated and hard to keep up with, but damn it's just so cool the possibilities you guys have.
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?
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?
JS is now old enough to have evolved significantly from its origins. So just like you should be cautious with learning c++ "from scratch", so should you be with JS. Other than that, given your skillset it should be fairly trivial to get the language basics down. Diving into the libraries and frameworks will probably be where you will spend your time :-)
There's a lot out there for sure but a lot of it is also fairly established. I agree with Kristian here that with your set of languages it shouldn't be hard to get into, personally I found "You (still) don't know JS" a great introduction, even if you read just the first few volumes and if typed JS is your thing the TS docs should get you going. I you're keen to stay server-side, NestJS could be interesting, its picking up a lot of steam, otherwise the ReactJS docs are as good as anything to get going in the front-end.
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.
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.
Vue is the 3rd in framework ranks... and like the 16th ranked?
"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
"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
Testing Library is an excellent library from Kent Dodds, it's also one of the testing tools recommended by the React team
https://reactjs.org/docs/testing.html
https://reactjs.org/docs/testing.html
I don't think it would be a "whatever" choice personally. I didn't take the survey this year, but other years you had to explicitly specify what your level of interest/satisfaction with a particular technology was.
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.
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.
I mean, if you don't know it's a library, you may think this is the 'other' choice.
> “Someones data is dirty dirty dirty”
Par for the JavaScript community course.
Par for the JavaScript community course.
It seems like the overall trend is that people are getting more and more unsatisfied with the current landscape now that a little bit of the sugar high from first wave of shiny new tech is starting to fade away.
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.
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.
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.
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:
```
<script src="https://cdn.jsdelivr.net/npm/[email protected]/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.
```
<script src="https://cdn.jsdelivr.net/npm/[email protected]/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.
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
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
Used vue for a few years then new place was svelte, I like it it but not because of the simplicity (or more because the simplicity that comes from it's killer feature), I like it because it's compiled.
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.
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 2.6kb
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/[email protected]/cjs/
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/[email protected]/cjs/
I jumped from Vue to Svelte when I recreated a site that took me a month to build in Vue in just over a weekend in Svelte. Svelte is FAST to build in, as a single dev, because it's so much less opinionated.
I can see how that'll turn around to bite me once the code base gets more complicated though
I can see how that'll turn around to bite me once the code base gets more complicated though
I think you’ve misunderstood Svelte’s bundle size. Its bundle size is technically zero since it’s a compiler.
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).
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).
if it helps, i wrote down my reasons for adopting Svelte, as a pretty heavily involved React user previously:
https://www.swyx.io/svelte-why/
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.
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.
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?
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?
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 something solid that is well praised). It's these 8 hour fucking Youtube videos that I need to watch and probably not remember anything. I watched one of those and its horrifying what kind of stuff these people are teaching. I am obviously generalizing, sure there are some really smart people involved in Frontend tech, but boy if you take a sweeping look from ten thousand feet, it ain't pretty.
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
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
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 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.
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.
>All the front end devs are like, "You have to wait how many minutes for compile times?" for instance.
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.
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.
Yeh Babel and webpack blow out compile times to epic proportions.
Any app that grows to a certain size will slow down to a crawl on incremental builds.
Any app that grows to a certain size will slow down to a crawl on incremental builds.
Try esbuild. I thought the following benchmarks must be fake until I tried it myself.
https://raw.githubusercontent.com/evanw/esbuild/master/image...
https://raw.githubusercontent.com/evanw/esbuild/master/image...
I really can’t believe that.
But I will try!
But I will try!
There has been some interesting tooling being written in Rust, swc[1] compiles very fast. Not quite production ready but getting there.
[1]https://swc.rs/
[1]https://swc.rs/
I'm not familiar with TS compile times, most of the engineers I know working on FE code use JS.
Thankfully on my projects FE and BE are separate builds, so I only do FE builds when needed, I save so much minutes.
Genuine question: in what sort of setup do you have a single build for your frontend and backend?
JEE and .NET, where the build takes care of handling JavaScript, CSS and HTML files, provided they are on the expected project layout structure.
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.
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.
> 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 much wrong with this argument and haven't scratched the surface.
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.
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.
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 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.
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.
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/
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/
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.
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 now. There’s certainly a lot more fun to be had remaking everything in React though.
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.
The main advantage of react in my opinion is the reusability of components. Most developers are not artists and can't design aesthetic and ergonomic interfaces from basic web elements, whereas with react you can install a component library (like material UI) and effectively just focus on business logic.
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.
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.
We had component libraries and reusability before React. I think a lot of FE best practices evolved at the same time as React.
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.
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.
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.
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.
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.
The reality is that most front-ends at most companies don't require that level of engineering. Sure if you work at Netflix or Facebook, there may be a lot of "real engineering" going on but most people don't work at those companies. But the guys at these small companies want to feel special, so they reach for whatever the big guys are doing and try to implement it, regardless of need. The same thing happens with (insert your domain here). Like, we have a single webstore with 10k customers, we need a Kubernetes cluster etc etc because Google does it.
> I think you have a fairly dated understanding of what front end is
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?
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?
Svelte and React would meet the criteria you described. So would Mithril.
Give Svelte a try online, their tutorial page is pretty slick: https://svelte.dev/tutorial/basics
Give Svelte a try online, their tutorial page is pretty slick: https://svelte.dev/tutorial/basics
I've gone through those. It looks clean. My biggest worry is the npm package manager and all the crud it brings into the repo.
It brings a package.json and a lockfile into your repo. There's arguments to be made against NPM but it doesn't bring any diffent "crud" into your repo than Composer, Maven, Pip/Pipenv/Poetry, or any other package manager.
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.
Well... things on browsers, html and css are technically most OK.
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.
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.
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.
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.
> 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.
[1] https://news.ycombinator.com/item?id=25798573
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.
[1] https://news.ycombinator.com/item?id=25798573
The Angular team at Google can make whatever changes they want, but they are required to update 1,000+ internal Angular applications if they make a breaking change, so it's a relatively stable framework. There's a new major release every six months, and upgrading is usually fairly painless.
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.
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've found Angular to be more effective than React at companies with a "developers are cogs" mentality. Angular has opinions about how things should be built and there is a lot of supporting material out there on how to do things the "Angular" way. It's much more heavy weight that React because it's a more comprehensive tool whereas React is just the rendering portion. If you're the type of developer who can push the boundaries of what's being done on the web, you'll be happier with React or other tools. If you want to just follow instructions and tutorials online for how to build a website use Angular or even a CMS.
I definitely second these comments. The app that I maintain at work started with Angular 5. We're now on Angular 11, but upgrades have never been an issue!
I also like how Angular can be quite easy to get started with when simply using two-way data binding without rxjs or some complicated state management library.
Not every company has access to devs who are proficient in reactive state management and functional programming. Angular work surprisingly well for the average developer.
> There are "boring" frameworks like Ember and Angular
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.
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.
> Something somewhere in the dependencies hadn't been screwed down tightly enough, and everything was broken.
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?
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?
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.
What’s wrong with MDN and the official React documentation?
I’ve never even considered going to YouTube, of all places, for JavaScript documentation. What’s next, people reacting to JavaScript programming?
I’ve never even considered going to YouTube, of all places, for JavaScript documentation. What’s next, people reacting to JavaScript programming?
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.
> 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.
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 some module wasn't compatible with Node version 15.
Took me 2 hours to just to find out that some module wasn't compatible with Node version 15.
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)
s/standard/started/
Because you'll just as easily stumble on other packages which are "bleeding edge", highly regarded, and require Node 15 features to run
Why are there "not-LTS" versions are all?
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.
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.
When Microsoft calls a version of Windows "LTS", it means "this is an old version of Windows for which we're going to keep releasing security updates for the next 10 years", not "all more recent versions of Windows should be considered beta quality software".
I forgot about Unity. Yes, Unity is another offender here. One of the many reasons I quit working with it.
I forgot about Unity. Yes, Unity is another offender here. One of the many reasons I quit working with it.
Debian Sid. Anything with a master, edge, or nightly release. Safari Tech Preview, Chrome Dev Edition, Firefox Developer Edition. FreeBSD-CURRENT vs FreeBSD-STABLE. And every network or storage operating system I ever installed on a switch or router or SAN head or other appliance came in a variety of release trains, from Experimental-Will-Crash to GA(T) and every shade in-between.
> "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.
> "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.
You are missing the point entirely. All of those examples you've listed are clearly marked in some notion of "prerelease". Even in the FreeBSD example, you're going to see that one version is labeled in such a way to make it sound safer. "Long-Term Support" labelling of one version says nothing openly about the unlabeled version.
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.
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.
Oh, no, I see the point, I just think it's an unproductive nitpick about an ultimately superficial complication. Labels aren't irrelevant, but they're pretty lacking in substance, and there are plenty of aphorisms about people who make assumptions based on surface details.
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.
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.
I had no idea there was LTS and non-LTS versions of node.
As a backend engineer who has worked on frontend recently, yes, that's how they do things.
There is some hope though, recent standards like web components and ES imports help a bit.
There is some hope though, recent standards like web components and ES imports help a bit.
I work front and back end, I've seen frontend done the "simple" way but not often. The syndrome I'm observing is that guys are chasing the next thing so they can bump up to a better paying job, and nobody is ever worried about maintaining their flaming pile of garbage long-term. When new guys come in to find someone else's trash code, they always need to rewrite it in the new thing. It's really no that hard to use modern tools tastefully and with restraint, but it's so rare to see.
I consider myself to traditionally be a backend engineer, though this has more been something I fell into rather than chose.
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
[1] https://github.com/yewstack/yew/tree/master/examples
[2] https://yew.rs/docs/en/getting-started/project-setup
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
[1] https://github.com/yewstack/yew/tree/master/examples
[2] https://yew.rs/docs/en/getting-started/project-setup
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.
I'm not blaming kids. And the constant churn is not a bad thing.
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.
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.
[deleted]
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 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 getting shit done for years that if you casually looked around the PHP world 10 years ago everything looked like crap. Quite frankly I'm over the elitism that so often accompanies these discussions where people ignorant about how other domains work make huge assumptions about the quality of said ecosystem. It's classic Dunning Kruger.
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.
Is that why as a security focussed bod I get to read this sort of thing: https://googleprojectzero.blogspot.com/2021/01/introducing-i...
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.
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.
You don't even need jQuery these days. All the important functionality is now in the DOM by default.
I can't make any promises, but many js engineers have found that clojurescript together with a framework like re-frame seems to offer a different mental model they find useful
https://day8.github.io/re-frame/
https://day8.github.io/re-frame/
I think at its core, the issue is that the code has to run in many different types of hostile environments. At least now we can sort of assume what features of the language are available, but you still have no control over the browser, OS, memory, or bandwidth available. There's no getting out of it :)
Moving fast and breaking stuff.
Sure, there are a lot of warts. But it feels less mature because it is less mature. Consider that you’re coming from a domain that’s three decades old into one that really only started gaining steam in the 2010s.
[deleted]
Sound’s like a pretty accurate description. It’s been like this for several years now I’m afraid.
Expecting Amazon search results to do your research for you, that was never going to work.
> no real good books
React reference documentation?
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?
[deleted]
I know right, I dug up a flex 3 book this new years it was so nice to actually read an actual quality book instead of some docs online.
[deleted]
Svelte is pretty cool. I‘ve only used it for a small app so far but it was very easy and quick to work with. I don‘t know how well it will scale for larger and more complex apps though.
So many date libraries.
Am I missing something about graphql being in the same metric as redux? They're not remotely in the same domain, are they?
It makes a little more sense when you consider the wider graphql ecosystem, like Apollo or Relay, which normalize all data received and keep your UI up to date automatically. In that light, graphql-the-ecosystem has solved a big part of frontend state management. With graphql and react hooks, I have found no need for redux anymore for typical CRUD needs.
That's what I was kind of thinking, but Apollo is also in the same graph. Seems a bit odd to me.
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, 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.
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.
For me it would make sense for it to be a plugin for your IDE, not a language, and now its something in-between. This trend also goes against the development and adoption of writing with languages that have actual types and their ecosystems.
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 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:
Then you need to figure all kind of shenanigans with Vetur/eslint... just wasn't worth the hassle, may as well use TS.
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.
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.
Webstorm might suit you better.
Ts-check + JSDoc feels great.
As BE, I was surprised how many FE developers use PWA. I need to take a look at this technology.
By the way, I am happy that the usage of typescript increases over time.
I really love the wrist friendliness of Svelte. Are there yet any good UI frameworks/libraries to use with it?
[deleted]
A large mistake in React's history is definitely it's history with redux and any API like it. You can see that it's very quickly being shed away from React in these charts which I'm very happy about. Redux is like a global variable and it's painful and clumsy.
> Redux is like a global variable
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.
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.
The big problem with traditional global variables is the way any code can change them arbitrarily, making it near impossible to understand the state management in a large program. I would argue that a library like Redux on the front end is more like a database, in that while it can be accessed from anywhere, in reality there is a structure to interacting with it and there has to be an explicit intention to modify the current state, which can been found via tools or even just a grep of the source code.
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.
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.
Do not forget Web is delivering to a lot of platforms. Try the same with desktop apps or mobile apps. Good luck.
I get it, there's mobile, desktop, even fridges,or doorbells that require front-end interfaces. I also understand it's not easy.im fact it's hard.very hard. But currently it's a shit show nonetheless, because everyone is going their own director with no plan to somehow unify or at least standardise the whole thing. And it's getting more and more absurd every day.
The trend seems to be using HTML/CSS/JS for "native" app frontends as well, see Electron an the countless apps that use it.
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.
Your opinion is unoriginal and unhelpful. Show me another platform with the reach and usability as the web.
Aldipower(2)
I thought it had been renamed Typescript?
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.
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.
This seems unnecessarily mean and dismissive. I have a software engineering degree, have been doing professional software engineering for 20 years and I love JavaScript. There are lots of things I dislike that are written in JavaScript or for JavaScript developers but I like the language.
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?
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?
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.