Now...that "little" it's-not-a-framework-it's-a-library whose scope is supposed to be confined to just the "view" part of MVC (by which I mean: "React") is inserting it's tentacles (along with a quirky architecture and proven to be error-prone coding patterns, cough, hooks) into the _model_. And it's already corrupted (at least partially) the "controller" part of MVC through React's synthetic events. But hey, at least React doesn't have one of those nasty DSLs, like those Web application libraries/frameworks that use a simple templating syntax on top of plain HTML. Oh wait, JSX is a . . . DSL, and a pretty nasty one at that, given that it's ever-confusing as where JavaScript syntax is legal vs. where HTML is legal; and, oh yeah, the bracketing rules fight each other all day long. But hey, what do you expect when you combine the careful syntax design of JavaScript with the terseness and simplicity of, umm, XML?
So now React's about to ship version 18, which provides functionality which is _roughly comparable_ to version, ummmm, _3_ of Vue.js??? Well, let's see, the React folks have _already, in just a few years_ deprecated (as best I remember): Class-based components, Mix-Ins, Higher-Order Components (HOCs) . . . what's next--let's deprecate hooks?, in favor of, oh I don't know, . . . .sheesh!
Please just STOP now. Wind up the company and give the money back to the investors. (Yes, I know that React is Meta-sponsored FOSS; that last comment was just pure snark...)
On a personal note, I'd like to rebut a comment made elsewhere on this page by '0des': "The JS ecosystem skews younger, not in age, but in years programming." As a counter point, I've been doing Web application development since the early 2000s. Yes, I've worked with Web app. libraries and frameworks that many Front End Developers have not used, or maybe even heard of. Backbone, sure. How about GWT? Or maybe ES4, by which I mean Adobe Flex? How about TIBCO General Interface?
Have you heard of Vitamin C? Trick question--it's not a Web view/app library or even a GUI library--it's a TUI library from the late 1980s/early 1990. Which is to say, I shipped my first front-end code in 1984. And even though I also do full-stack coding, and UX stuff, most of my career has been in front-end coding, both desktop applications AND web applications. Which is to say, at least anecdotally (and possibly egotistically), that I think that I have a pretty well-informed opinions on what makes a good front-end framework.
React impresses me not-at-all; except in a: look-at-me-I'm-so-clever way--now new-and-improved--with extra _functional_ goodness(TM). Conversely, I've scaled Vue.js and Flex applications with so little stress (but with tremendous productivity) that I could laser-focus on the feature set, and on delivering a top-notch user experience.
I need a Web application framework (or at least a View/Rendering mgmt. library) that has these things:
- Strong support for UI componentization
- CSS isolation
- Clean, orthogonal, basic abstractions for change handling and local state management
- Tractable to scale
- M, V, and logic aspects are (easy to) decouple
Also very useful:
- One-way data binding
- Robust, but low-ceremony approach to centralized state management
- Flexible, but type-safe way to marshall/un-marshall data going out/coming in
I'm open to assessing other/new libraries, but the last five years of my career have almost wholly involved coding with Vue.js or React. HOWEVER, I only learned React because I thought that the job market demanded it--not because I ever thought that it was a great library! I'm open to learning other/newer libraries, if they are promising enough, AND if if looks like there is job market demand for them. But the previous version of Vue.js already gave me all five of the needs that I mentioned, above; plus one-way and pseudo two-way data binding. So all I need is Vuex5/Pinia for state management (but I'd be willing to also look at something like a Vue-specific alternative to Tanner's React Query), and there is an increasing wealth of solutions for data marshalling with or without GraphQL.
So, bottom line, in my current job search I am taking a hard line: if React is required, then I'm out. And if you're already using Vue, or are at least open to modernizing your current front-end coding approeach, then I'm interested.
> Now...that "little" it's-not-a-framework-it's-a-library whose scope is supposed to be confined to just the "view" part of MVC (by which I mean: "React") is inserting it's tentacles [...] into the _model_.
useSyncExternalStore doesn't care about what you do in your model. it's for connecting your view to your model in a way that doesn't give you inconsistent states when concurrent-rendering-funkiness happens.
you could even say that useSyncExternalStore exists because React maintainers want people to be able to use whatever state-manager they want (instead of useState/useReducer/whatever) -- uSES was necessary to enable that in 18.
React went from v0.14 to v15. The rationale was the library was stable at that point so they could switch to major versions. Why they went directly to version 15 rather than 1.0 is admittedly a bit odd. I guess it was marketing in the same vein of Java 1.4 to Java 5.
We didn't want a big hubbub around a "1.0" release, since we realized React was effectively already stable at that point and the changes from 14 to 15 were no more dramatic than from 13 to 14 or 12 to 13.
Not to be harsh, or dis-respectful, but there's an unfortunate amount of incorrect, or obsolete, information in the comments on this article. Let me see if I can do better...
-- Full disclosure: I used to (relatively recently) work for a vendor of 3D-printing technology.
It is important to consider the full 'volume' range of manufacturing, when evaluating a particular process or technology. Some will be good for making ONE part; and some for a million+ parts, and some in the middle. It's also important to consider the intended usage: for example, prototypes and military and medical parts may not be cost-sensitive, but, say toys, or consumer electronics are the opposite. Speed of manufacture is a key cost driver, especially in high labor-cost countries. Raw material wastage, and cost of energy can also be key cost drivers in manufacturing.
With regards to 3D-printing (more formally known as: additive manufacturing), I have to admit that I _used to_ be a skeptic, too. I can't tell you the number of: toys, action figures, souveniers, etc. that I saw printed from low-end, plastic 3D printers--and they just struck me as 'junk'. And even a lot of the industrial parts that I saw from middle-tier, plastic 3D printers were...unimpressive. I few years ago, I even thought that I was detecting a 'backlash' against 3D printing, at least at the hobbyiest level. And it is true that there has been some consolidation of vendors of low-end/hobbiest 3D printers.
But, there's also been a gradual, and now accelerating maturity in AM, and also an increasing diversity in approaches, and in uses. In particular, most people only think about 3D printing in plastic. But metal AM, and also directional-composite (e.g., oriented carbon-fiber) printing is really coming along.
In particular, AM lets us create parts that have voids (of controlled size/shape) throughout the part. That may not sound like a big deal, until you think about weight-sensitive transportation usage. If you can get 20-30% of the normal weight out of a part, that's huge for cars; and game-changing for aerospace. Here's one case-study, where they're claiming a savings of 3,180 kg of fuel, per-year, PER-PLANE: https://www.autodesk.com/customer-stories/airbus
I noticed that lots of commentors are discussing how much 'better' injection molding is than 3D printing in plastic. Sure, for anything above prototyping quantities, that's probably true. But, also think about the manufacture of the _molds_ for those machines. What if you could cut your mold production time by 30%, and your mold production cost by 90%? Here's a case study on that: https://www.desktopmetal.com/resources/builtrite-3d-printed-...
What if 3D printing--including in METAL--wasn't a S-L-O-W process. Here's some folks that can do metal AM at very high speed: https://www.digitalalloys.com/
The caveat there is that the resulting part has pretty crude tolerances, so a finish pass (with conventional CNC machining) may be needed. But there's some higher-quality, and pretty high-volume, metal AM processes coming along, for example: https://www.desktopmetal.com/products/production and: https://www.exone.com/
Lastly, AM opens up some design space possibilities, that previously were either wickedly cost-prohibite, or were completely impossible to do. For example, the previously mentioned _molds_ for injection molding machines. Being able to carefully control the mold temperature is a key process parameter. With 3D printing, 'conformable' cooling channels can be designed-in to the mold. And these channels can basically be any geometry that is needed--looking like animal veins, for example, to give optimal cooling.
It's probably going to take a new generation of designers and mechanical engineers, before the full--and I use this word deliberately: disruptive--effects of AM are 'internalized', and used to their best potential. For example, here's a (software) CAD tool that produces 'organic' designs, and ones that would only be practical to manufacture with 3D printing: https://www.desktopmetal.com/products/software/live-parts/
AM seems great and all, but ABS still seems like a trash material to make a boat out of. Picking ABS sends strong "when all you have is a hammer..." vibes.
Now...that "little" it's-not-a-framework-it's-a-library whose scope is supposed to be confined to just the "view" part of MVC (by which I mean: "React") is inserting it's tentacles (along with a quirky architecture and proven to be error-prone coding patterns, cough, hooks) into the _model_. And it's already corrupted (at least partially) the "controller" part of MVC through React's synthetic events. But hey, at least React doesn't have one of those nasty DSLs, like those Web application libraries/frameworks that use a simple templating syntax on top of plain HTML. Oh wait, JSX is a . . . DSL, and a pretty nasty one at that, given that it's ever-confusing as where JavaScript syntax is legal vs. where HTML is legal; and, oh yeah, the bracketing rules fight each other all day long. But hey, what do you expect when you combine the careful syntax design of JavaScript with the terseness and simplicity of, umm, XML?
So now React's about to ship version 18, which provides functionality which is _roughly comparable_ to version, ummmm, _3_ of Vue.js??? Well, let's see, the React folks have _already, in just a few years_ deprecated (as best I remember): Class-based components, Mix-Ins, Higher-Order Components (HOCs) . . . what's next--let's deprecate hooks?, in favor of, oh I don't know, . . . .sheesh!
Please just STOP now. Wind up the company and give the money back to the investors. (Yes, I know that React is Meta-sponsored FOSS; that last comment was just pure snark...)
On a personal note, I'd like to rebut a comment made elsewhere on this page by '0des': "The JS ecosystem skews younger, not in age, but in years programming." As a counter point, I've been doing Web application development since the early 2000s. Yes, I've worked with Web app. libraries and frameworks that many Front End Developers have not used, or maybe even heard of. Backbone, sure. How about GWT? Or maybe ES4, by which I mean Adobe Flex? How about TIBCO General Interface?
Have you heard of Vitamin C? Trick question--it's not a Web view/app library or even a GUI library--it's a TUI library from the late 1980s/early 1990. Which is to say, I shipped my first front-end code in 1984. And even though I also do full-stack coding, and UX stuff, most of my career has been in front-end coding, both desktop applications AND web applications. Which is to say, at least anecdotally (and possibly egotistically), that I think that I have a pretty well-informed opinions on what makes a good front-end framework.
React impresses me not-at-all; except in a: look-at-me-I'm-so-clever way--now new-and-improved--with extra _functional_ goodness(TM). Conversely, I've scaled Vue.js and Flex applications with so little stress (but with tremendous productivity) that I could laser-focus on the feature set, and on delivering a top-notch user experience.
I need a Web application framework (or at least a View/Rendering mgmt. library) that has these things: - Strong support for UI componentization - CSS isolation - Clean, orthogonal, basic abstractions for change handling and local state management - Tractable to scale - M, V, and logic aspects are (easy to) decouple
Also very useful: - One-way data binding - Robust, but low-ceremony approach to centralized state management - Flexible, but type-safe way to marshall/un-marshall data going out/coming in
I'm open to assessing other/new libraries, but the last five years of my career have almost wholly involved coding with Vue.js or React. HOWEVER, I only learned React because I thought that the job market demanded it--not because I ever thought that it was a great library! I'm open to learning other/newer libraries, if they are promising enough, AND if if looks like there is job market demand for them. But the previous version of Vue.js already gave me all five of the needs that I mentioned, above; plus one-way and pseudo two-way data binding. So all I need is Vuex5/Pinia for state management (but I'd be willing to also look at something like a Vue-specific alternative to Tanner's React Query), and there is an increasing wealth of solutions for data marshalling with or without GraphQL.
So, bottom line, in my current job search I am taking a hard line: if React is required, then I'm out. And if you're already using Vue, or are at least open to modernizing your current front-end coding approeach, then I'm interested.