Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
On the other hand React is an open source Javascript library designed to create user interfaces with the goal of facilitating the development of single page applications.
More detailed; it binds to a frontend architecture model named SPA (Single Page Application) and provides an opinionated way to to speed up the development of UI components.
Anything else that you may need is developed in "plain JavaScript" (or using any other lib that you like).
Inside React components (that are in fact JS functions) you'll probably use map to iterate through elements. Instead, in Angular you'll use ngFor or v-for in Vue which are out of the JavaScript spec, neither they are valid HTML attributes.
in Svelte you'll use {#each items as item, index} which of course is not valid in JS nor in HTML.
Everything that stands out of the platform boundaries is opinionated and the past proved that they will eventually fade out into the CS history.
When this happen you've two options:
Quick-jump when this process starts, if you've knowledge of the core API it will be easy.
Refresh yourself with a new mainstream framework.
Keep maintaining old projects till there are no more projects with this tech to maintain.
Moreover, anything you need to solve that's not provided by the framework or lib you use will need more or less proficiency and a deeper understanding of the environment, platform and core API of the language.
If you do not develop this skills your problem solving capabilities will remain average and the given project you work in will still need a more senior dev with those capabilities be by inherit needs of the project or just in case.
To clarify the last point, I (as TL) can get the best React Dev in the world but, if he/she doesn't built up the knowledge on the rest of concepts named before, I won't let him/her act as TL. Why? Because when a client asks if something is possible, the answer is YES the 99% of the time.
The question is not if it can be done but how much it will cost (in time or money). In my experience, devs that stick to a framework say "It's not possible to reach that" just because there is no way to workaround that provided by the framework (or they don't know about it) so it leads to a situation where another company can offer this feature while you don't, just because the person driving the project hasn't enough skills.
Last but not least, the hackernoon post also has issues when understanding concepts:
When does a website become sufficiently complicated enough to be considered a web application?
A website contains static content.
A web application is designed for interaction with end users.
And I just did a quick overview into it (I'm reading it later on, promise).
it binds to a frontend architecture model named SPA (Single Page Application) and provides an opinionated way to to speed up the development of UI components.
and
if we're more strict choosing words but by all means, all of them apply their own syntax, separating you from JavaScript.
In what way is learning to use the React ecosystem different from the frameworks that you so summarily dismissed?
Focusing on any one of them doesn't actually teach you about the web or web development in general. They all exist in their own epistemic bubbles which gloss over the importance of understanding "the platform".
If your goal is to find employment as a "React developer" (if there are opportunities in your local area) then by all means learn React and Next.js.
However in my experience Svelte is the best option for a "first framework" for somebody new to web development.
In many ways it simply extends many concepts that already exist in the HTML/CSS space so it extends foundational (rather than product) knowledge. And its performance profile is such that it can serve a wide range of web-based solutions; and SvelteKit looks promising.
Svelte gets to those hard-to-reach places other frameworks can't.
18:15 PM - 24 Jan 2019
More importantly Svelte doesn't get in the way when you need to use "the platform" for functionality it doesn't cover. The same can't be said for React.
React's big advantage is the size of its ecosystem but consequently adoption requires aquisition of a lot of product-specific rather than foundational skills.
Cory House
@housecor
3 technologies that are βbetterβ than React: 1. Preact 2. Svelte 3. Solidjs
These options offer better performance, smaller bundles, and more elegant APIs.
But, Iβm not using them.
Why? Ecosystem.
Reactβs rich ecosystem makes it more compelling to me.
Chatted with someone whoβs been working at a company as a front-end developer for 3 years. Their friend asked them to help build a website, but they had to decline. They didnβt know how.
The resistance to look at your tools with critical eyes. A dogmatic faith in an approach because it's popular, not because of actual analysis. Reluctance to dig deeper to find out how something works. We're engineers, we should take things apart to understand them!
20:02 PM - 12 Jun 2022
in Svelte you'll use {#each items as item, index} which of course is not valid in JS nor in HTML.
JSX is just as contrived; the only difference being that Babel started transpiling it together with the rest of ESNext for .jsx/.tsx files; but it isn't part of ECMAScript nor is it part of "the platform".
And more to the point JavaScript is only one part of the HTML/CSS/JavaScript triad.
Content is the foundation
Markup is an enhancement
Visual Design is an enhancement
Interaction is an enhancement
Everything that stands out of the platform boundaries is opinionated and the past proved that they will eventually fade out into the CS history.
And that includes React and its entire ecosystem.
best React Dev in the world but, if he/she doesn't built up the knowledge on the rest of concepts named before, I won't let him/her act as TL.
And yet, you recommend React as an entry point into web development.π
React is the centre of its own universe.
A website contains static content.
A web application is designed for interaction with end users.
Rich Harris
@rich_harris
Tom is a must-read as ever: twitter.com/tmcw/status/12β¦ Much to agree with, but I can't get on board with the idea that there's a strict dichotomy between docs and apps. (Case in point: my day job is building apps that sit inside news articles.) 1/3
15:10 PM - 24 Aug 2020
Tom MacWright
@tmcw
okay, here's my pitch: let's redo the web https://t.co/x1shlb43LC
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Look, it doesn't matter how many links to random posts or screenshots/embeds of external platforms you add in your comments.
All I can agree is on that React will die at any point of the future and that JSX is not part of "the platform".
Even that, JSX is almost HTML and following the same reasoning around that Svelte uses a "standard templating convention (Mozilla Nunjucks) to operate in that manner", JSX is also a standard.
Just to clarify no, Nunjucks is yet another templating language, nothing more, nothing less.
Now back into React. There are several reasons for using it as I explained before.
When you use React you use JavaScript the entire time.
Do you want to use a hook? Do it. Do you plan to code a vanilla JS component? Do it. It doesn't matter if it's wrapped inside a React component or not, or if it uses JSX or not or... and it doesn't matter because React are a bunch of functions, nothing else.
I used Angular and Preact on projects that are still in production.
Also tried Svelte when in december 2016 and Svelte 2 short after it's release and haven't even bothered to try Vue. The list can grow with a big bunch of libraries and frameworks if we start talking about the past but to make it short every time you get a -mostly- opinionated framework you end up having to learn a whole new syntax and a whole new logic.
What React offers?
Two things.
1- The first one is a clear FP approach to render UI components, straightforward, easy to understand (from my PoV). The most complicated thing may be to use className instead class in HTML tags π or understanding the lifecycle and what those hooks do if you're new to FP.
2- It does what it does. As it's description states "A JavaScript library for building user interfaces" it does just this and nothing else. You can handle the rest as you wish (or as your project needs).
Also, seems that the major part of devs across the world think the same.
Is React the fastest? Nope. Is it the easiest to learn? I don't know if the easiest but one of them for sure.
Content is the foundation
Markup is an enhancement
Visual Design is an enhancement
Interaction is an enhancement
Disagree completely. You need interaction to get an application by definition, you enrich the UI with a great visual design to increase the interaction time and markup is something needed to make the content readable.
I don't really know where all that mixed unrelated concepts came from and why is it all together in the same comment, honestly. HTML Islands? The post you linked was written in Aug 11 2020 and HTML islands is an old concept before HTML 5 came up (like 12-14 years ago?) it's still a great conceptual way to integrate frontend apps together but I can't find out the reason to bring it up on this topic π€·ββοΈ
The final smash on that is the current state of the art. If you want to work, you'll learn things that people uses. More users, more opportunities.
If it's any consolation, I also think svelte is cool but not enough to be considered for production, because someone will need to maintain it and.... good luck finding someone for the job.
Moreover if a new learner starts with svelte he/she will learn it's specific syntax that nothing has to do with "the platform" in it's standards, which is not the case with React.
it doesn't matter how many links to random posts or screenshots/embeds of external platforms you add in your comments.
There is nothing random about those links. Granted they are going to reflect my own bias but I also regularly post links to content I don't agree with inviting the reader to make up their own mind; to carefully scrutinize the information they are presented with, regardless of source and that includes everything that I state.
JSX is almost HTML
"JSX is an XML-like syntax extension to ECMAScript without any defined semantics."
It transforms to JavaScript.
In React that JavaScript creates ReactNodes, in SolidJS it creates DOM elements.
The only time HTML is the result is during SSR.
JSX elements represent components in the component tree which relates to but isn't identical to the DOM tree.
And in React Native there isn't even a DOM much less HTML.
JSX is also a standard.
Neither is a W3C standard. The point was that Svelte's approach to templating is just as "legitimate" as JSX.
When you use React you use JavaScript the entire time.
Again what is the point of this statement?
On the one hand you accept JSX as a useful DSL but on the other hand you want "just JavaScript". From that perspective a Vue SFC is as much "just JavaScript" as a React component with JSX.
and it doesn't matter because React are a bunch of functions, nothing else.
Ultimately that is true for all the other frameworks as well. And Meta is continuing to experiment with compilers.
tried Svelte when in december 2016 and Svelte 2
It has changed a lot since then.
The first one is a clear FP approach to render UI components.
Again that's a fallacy. The React community calls them Function-al components. Even the React documentation calls them Function components. React leverages immutability to it's own ends and function components, render functions, that access hooks are impure from the FP perspective.
What React gives you is "declarative UI", i.e. you don't have to constantly, imperatively fiddle with DOM elements.
easy to understand (from my PoV).
People always find matters they are familiar with easy to understand.
i.e. it's fairly easy to find testimonies that React is anything but straightforward; so it's not as cut-and-dried as you portray it.
You can handle the rest as you wish (or as your project needs).
As long as it aligns with the React community consensus; React dictates a certain architecture therefore it has a distinct opinion which in itself isn't necessarily a bad thing until such time that the particular constraints it sets actually get in the way.
"What is clear: right now, if youβre using a framework to build your site, youβre making a trade-off in terms of initial performanceβeven in the best of scenarios."
So I guess you'll be getting on that PHP gravy train, right? It's the most prevalent β¦
HTML Islands?
You really need to read things more carefully and not just see what you want to see.
"HTML Islands" doesn't occur anywhere in that article. It's Islands Architecture and a counter point to your claim of the false "site vs. app" dichotomy. There's a whole range of options in between. In fact enterprise consultancies are now starting to warn their clients about the SPA by default approach:
"the sheer prevalence of teams choosing a single-page application (SPA) by default when they need a website has us concerned that people aren't even recognizing SPAs as an architectural style to begin with, instead immediately jumping into framework selection. SPAs incur complexity that simply doesn't exist with traditional server-based websites"
If you want to work, you'll learn things that people uses.
Sure but it doesn't mean you have to settle.
good luck finding someone for the job.
The title for this article is "Getting ready for my first website: Choosing the right platform".
Web site, not app.
Nothing about being constrained to job requirements; maximum freedom of choice. People will often change the platform for their own site like for example Jekyll, to 11ty, to Astro, etc. If all you want is some pages use Github pages; something a bit more fancy Wix, Webflow, SquareSpace etc., whatever.
Moreover if a new learner starts with svelte he/she will learn it's specific syntax that nothing has to do with "the platform" in it's standards, which is not the case with React.
The extensions you need to adopt when working with Svelte are minor compared to the concepts that you have to assimilate with React. React introduced hooks in early 2019 and people are still complaining about them (and lets not forget the continued moaning about React 18; for example useEffect and useEvent).
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
There are of course a big bunch of different opinions, specially on a tech that has >15million daily downloads.
Either way and just because it has >15million daily downloads it's the go-to unless learning has not the purpose of finding a job afterwards.
In fact enterprise consultancies are now starting to warn their clients about the SPA by default approach
The question is simple. Do you need SEO?
NO -> SPA (mostly)
YES -> SSR/SSG, being SPA or not.
Is it a website? You'll be fine witj just HTML and CSS with few grains of JS.
This is applicable to the major part of cases currently.
Both SPA and classic SSR have its nuances and complexities. It was easier to develop with good Ol'SSR but it's also much harder to maintain.
Maintenance being a top cost for companies and us providing solutions come first to find "best practices", "rulesets" like SOLID and DRY, leading the industry to code separate backends. Guides arose to transform a monolithic application into services then into microservices where it suits.
Having the front-end attached to a backend leads you to few maneuver ability. i.e. you're using Smarty template engine inside a PHP backend and you see the need of complex computational tasks on new features that business needs. You may want to code this "service" in Java, Go or any other language that's capable of it efficiently. But Smarty works on PHP. So you've a problem and the cost of solving that problem is undesirable.
Options:
Stick with PHP, raising in costs (infrastructure resources) and lowering your computational capabilities; lower performance, longer response time spans, worse UX, servers can freeze if not capable of handling enough requests, you may need a Node gateway, a queue service and/or a load balancer much earlier because you're not using the right tool for the job (more costs).
Use the "Islands architecture" and create a whole new application for the purpose, embed it on a given place and start praying you don't need much interaction between the wrapper and the new one, because it can quickly become another costly problem).
Rewrite the entire frontend and backend with the main reason being a backend (only) need.
As I'm always saying there's no tech to rule them all, but if anything goes mainstream there are technical reasons behind that choice.
There are hundreds of thousands of template engines, frameworks, libraries and so on out there, a good number of which are mostly useless, others have its niche and others have a general purpose.
Understanding the target of each and the differences against the rest of the options as well as acknowledging the context you're dealing with is key to make the right choice.
Either way and just because it has >15million daily downloads it's the go-to
So you're advocating tool selection based on popularity, not whether it's the right tool to solve the problem.
Do you need SEO?
So people who access services behind a login screen don't deserve the UX that contemporary SEO is attempting to foster? The prediction is that Interaction to Next Paint (INP) is going to heavily penalize many React-based apps.
It was easier to develop with good Ol'SSR but it's also much harder to maintain.
Hard to maintain perhaps but harder than an SPA?
The reports that I've come across suggest that SPA projects require more staffing than more conventional sites, compounding the negatives.
"best practices", "rulesets" like SOLID and DRY
Best practices are valid within a specific context outside of which they are no longer best practices. That's why DRY has to be balanced with Beware of the Share and SOLID is being challenged by CUPID; there are no universally applicable rule sets.
Guides arose to transform a monolithic application into services then into microservices where it suits.
Actually there is a perspective that properly bounded microservices are valuable because of they're (quickly) replaceable:
That has more to do with boundaries exerting just the right amount of cohesion on the inside combined with the right level and kind of coupling on the outside.
That maintenance cost could be lower when things are easier to replace isn't too great a stretch.
But just because you are using microservices or components doesn't mean that you'll be able to find the optimal boundaries right away. So there is no guarantee of "lower cost maintenance"; using more complex tooling makes it easier to miss the target. And at times components are not the right boundary:
Meet eBay's Marko. It has supported out of order streaming even back in 2016 (Marko 3). It will start to stream the page even before "the calculation service" has finished.
but if anything goes mainstream there are technical reasons behind that choice.
Popularity doesn't necessarily correlate to quality and popularity isn't necessarily based on technical characteristics. Many have argued that PHP's popularity was primarily due to the availability of cheap shared hosting, so the driver would have been an economic one.
React's popular feature is "declarative UI", translation: "You don't have to fiddle with DOM elements/objects". And while React Native was released 22 months later, VDOM could have been adopted with that end goal in mind. So "declarative UI" could have been a happy accident. And as the Elm community keeps pointing out components are objects (even with function components). So there's the theme of the promise of reuse in terms of components and across platforms. However that kind reuse comes with trade offs:
The rule of three: Reuse makes components harder to write and more complex.
Cross platform reuse tends to block platform specific optimizations. By extension if you don't use the cross platform capability then you are paying for trade offs that you never cash in on.
Again the motivation behind reuse seems to be largely economic, not technical, since this kind of reuse introduces undesirable coupling.
Now lets say "declarative UI", components and promise of reuse is enough to let React hit critical mass in terms of developer availability; i.e. it becomes easy to hire for. At that point the "popularity" becomes self perpetuating; React is chosen because it is easy to hire for, people learn React because it's in demand. Again this kind of popularity is non-technical.
So I think it is entirely possible for something to get popular without "technical reasons" contributing to it.
as well as acknowledging the context you're dealing with is key to make the right choice.
But that is the core of the problem; SPA/React predominantly being chosen without any consideration of context; that's essentially the Thoughtworks radar assessment:
"Too often, though, we don't see teams making that trade-off analysis, blindly accepting the complexity of SPAs by default even when the business needs don't justify it. Indeed, we've started to notice that many newer developers aren't even aware of an alternative approach, as they've spent their entire career in a framework like React."
I'm working on a new mental model and could use some feedback: Do all websites fall on this spectrum?
22:01 PM - 12 Apr 2022
Lots of services don't need to be either stateful nor apps but go SPA just for the native-like perception and aesthetics, not any real usability benefits.
React was only created for stateful and apps (taking on additional trade offs to accommodate React Native). Creating ecommerce apps with React can be risky:
amazon.com is server side rendered and has no client side rendering framework. The potential latency hit didn't justify it.
We were stuck with jQuery 1.6.4 π¬
SSR React wasn't fast enough for us. This blew my mind.
19:26 PM - 22 Jan 2022
Now Shopify's Hydrogen is React based but they are pushing hard to get React Server Components going to make up for lost ground (and as it so happens Jason Miller is now at Shopify (Platform DX) as well).
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
So people who access services behind a login screen don't deserve the UX that contemporary SEO is attempting to foster?
The only reason for using SSR for SEO purposes is the inhability of the crawlers to properly crawl an entire SPA site.
Don't you remember why we jumped from SSR to SPA? Just because you don't need to reload the entire site each time a click is made.
Yes, AJAX as popular just before SPAs, do you remember?
Many have argued that PHP's popularity was primarily due to the availability of cheap shared hosting, so the driver would have been an economic one.
Isn't that the most important?
Reuse makes components harder to write and more complex.
Yes. And finding what you need if you don't use reusable components is just a matter to find your button inside the rest of 93810 buttons. Sure it will make things easier π
The Amazon being SSR is changing btw, the contact part of the web app is now reactive (I noticed the upgrade on Sunday), we could dicuss why amazon is so slow changing its web app but that's another story that doesn't compete here. Oh and, know what? Amazon used React for the job :)
"Too often, though, we don't see teams making that trade-off analysis, blindly accepting the complexity of SPAs by default even when the business needs don't justify it. Indeed, we've started to notice that many newer developers aren't even aware of an alternative approach, as they've spent their entire career in a framework like React."
React is a framework now? How come?
The only devs I met who don't know other approaches came from a codecamp (3 month, stack rush learning approach) or self-taught (you learn what you like or what you feel necessary) and from both groups together only 3 of those I met fall in this description.
On the rest, let me state a sort of a rule:
For the same features and behavior, the complexity is always the same and every time you add more features you add more complexity as well.
The question is not if it's complex or not, the question is where do you want the complexity to be.
Poor page experience signals tank your search rank. SSR has been about good "user experience criteria" for a while now which meant that SSR needed to be fast and in the general it wasn't.
While revisiting SSR benchmarks for the next @solid_js release I went ahead and updated all the libraries and witness some big performance improvements from Svelte, React, and Vue.
React 18 is 48% React 17 Vue 3 is 61% over Vue 2 Svelte 3.49 is 97% over Svelte 3.44
Being able to pay the bills is important. But if you can only make a profit by negatively impacting everything else then you need to stop and find something else.
"But also, by choosing the framework that is dominant today, we maximize our chances to find volunteers, contractors and consulting shops to help us when we need it."
React appearing everywhere just illustrates the current human resourcing situation, it's not an indication that React is the best-of-breed solution for the problems it is being applied to.
What the Amazon tweet was about is that React isn't used in parts of Amazon's software that are critical to the business.
React is a framework now? How come?
I'm not going down that rabbit hole again. In software engineering terms React is a framework; it doesn't matter that the React docs call it a library and that React is nothing like Angular.
The question is not if it's complex or not, the question is where do you want the complexity to be.
"A fundamental point the article makes is that there are two types of complexity feeding the software crisis; accidental complexity and essential complexity. Accidental complexity occurs due to mismatch of paradigms, methodologies, and/or tools in our application. This type of complexity can be eliminated given sufficient resources to build or buy tools that complement one another. [β¦] The real culprit of the software crisis is essential complexity. Essential complexity revolves around the fact that software is intrinsically complex, and no methodology or tool is going to eliminate this complexity. There are several reasons why software possesses essential complexity:
Software applications, for their size, are the most complex entities that humans build.
Software is intangible and, for the most part, invisible.
Software does not wear out in the traditional sense of machinery with moving parts wearing out. However, software is constantly being used in ways its authors never expected (often uncovering errors), and end users are constantly demanding extensions to their software."
Riel, Arthur J. (1996). Object-Oriented Design Heuristics. Addison-Wesley. (pp.3-4)
Over the years React hasn't been eliminating accidental complexity but accreting it.
Ultimately that is why SolidJS is becoming more compelling to developers who use React despite its much smaller ecosystem; it helps them eliminate accidental complexity.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Pointing the mdn github thingy but just mentioning the statement that suits you wasn't right, let me take care of it:
For the record, though, let's be clear that React is open-source and that React is a tool for producing websites that are built from the web standards of HTML, CSS and JavaScript. Yes, there are intermediate steps (jsx) that are not web standards, but the end productβthe MDN websiteβis still based on standards. Its not like we're using Flash for our drop-down menus and an ActiveX plugin to display documentation in MS Word format!
I love web components. I had the opportunity to use them just a little bit as the FirefoxOS project was wrapping up years ago. And I look forward to using them again some day. But: I spent 18 months using React at Khan Academy and found it to be a huge productivity boost. There is a reason that so many developers use React: it, and the mature ecosystem of tools around it, works really, really well for rapid frontend development. This may sound harsh, but if you haven't used React on a midsize (like MDN) or larger website, I don't believe that you are qualified to judge our decision. And if you haven't worked as a frontend developer in an environment where you've got product managers and user researchers and marketing teams asking you weekly to add features and A/B tests and banners to the website, then you're also not qualified to judge this decision, either.
Actually David Flanagan did so good speech that I don't even need to go further with this.
Oh and by the way, your comment here is completely wrong.
You call ReactDOM.render(<App />, document.getElementById("root")); and YOU pass the components you want inside App component, it's not React calling you, it's you sending functions (components) to React. And those other things exists to fill some needs few have on this topic as IoC is not applied nor provided by React.
Sure you'll find people buying your nonsense but to anyone reading this, just go to React's homepage and you'll read "A JavaScript library for building user interfaces" right in the hero. I don't think this needs further absurd discussion.
I barely can hear that far cry that says "Punk's not dead!" but the stubbornness to go against the current is reaching unsuspected limits in this topic and the last stand should be taken in a different place, not on a science related field IMHO.
Actually David Flanagan did so good speech that I don't even need to go further with this.
"and found it to be a huge productivity boost."
Out of context this sounds great.
However whenever I dig into it, it always comes across as the "productivity boost" from moving something from an "artisan craft" to an "assembly line". And while that was responsible for industrialization, today's car assembly lines are serviced by robots, i.e. those areas will be automated into oblivion at which point one better be the plant owner or have moved into robot maintenance or bespoke car assembly.
YOU pass the components you want inside App component, it's not React calling you.
If React is going to do the framework thing of calling user code then you have to inject the user code somewhere β¦ π€¦
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
The context seems to matter just when it cames convenient to your message, Isn't that the Appeal to Convenience fallacy?
Bringing the Argumentum ad populum has lots of sense on ideology, thoughts and likenesses but here is claiming that the entire industry is wrong and that the reasons behind are not valid; technical profiles, architects, business...
You've work to do pal. Overall you bringed an argumentum ad lapidem and that's a bit sad because no knowledge can be extrapolated, just references.
If React is going to do the framework thing of calling user code then you have to inject the user code somewhere
?? You injecting the code is just the opposite of inverting the control, that's why it's called inversion of control π π€·π»ββοΈ
I heartly recommend you to try to understand why React has the lead instead pushing against it.
I tried some of the frameworks and libs (Angular, Svelte, Preact, React, Next...) and have a formed opinion on every one of them. I do like more than one and I use more than one in a regular basis (when they suit). Solid JS (that seems to be your favourite one) is on my list for future check after Polymer and a couple of things that are more urgent to me (I do not work only in frontend).
You can like more than one at the same time, is not that difficult.
Is like buying a car, you like some different models, you may test them, see the equipment each bring, the optionals, the pros and cons and end up picking one because at the end you only have one ass and a limited budget, hence you just need one of them and it needs to be convenient. That doesn't mean that you don't like the rest from now on.
At the current State of the Art, React is usually more convienent for different reasons, not necessarily technical and it is what it is like it or not.
That doesn't mean that the rest are shit. While Angular has some bad vibes, svelte seems to be pushing step by step and I don't know if solid will ever be a market option, will see.
Disregarding my arguments (ease to use, web standards, market share, ecosystem, ease to find devs with previous experience, less decoupled of the language core API...) just because you don't like them or they are against what you would like the world to be won't make'em falsy.
Gosh You even disapproved the arguments of David Flanagan, -which you linked by the way- and which is a reputed engineer in the industry.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think some clarification is needed here.
What do you perceive to be "the platform"?
Because from where I'm sitting the React ecosystem is doing its very best to render the platform [
alt] irrelevant.In my experience recommending focusing on the React ecosystem and learning "the platform" is recommending extreme, polar opposites.
I mean -by context- the Web Platform.
On the other hand React is an open source Javascript library designed to create user interfaces with the goal of facilitating the development of single page applications.
More detailed; it binds to a frontend architecture model named SPA (Single Page Application) and provides an opinionated way to to speed up the development of UI components.
Anything else that you may need is developed in "plain JavaScript" (or using any other lib that you like).
Inside React components (that are in fact JS functions) you'll probably use
mapto iterate through elements. Instead, in Angular you'll usengFororv-forin Vue which are out of the JavaScript spec, neither they are valid HTML attributes.in Svelte you'll use
{#each items as item, index}which of course is not valid in JS nor in HTML.Everything that stands out of the platform boundaries is opinionated and the past proved that they will eventually fade out into the CS history.
When this happen you've two options:
Moreover, anything you need to solve that's not provided by the framework or lib you use will need more or less proficiency and a deeper understanding of the environment, platform and core API of the language.
If you do not develop this skills your problem solving capabilities will remain average and the given project you work in will still need a more senior dev with those capabilities be by inherit needs of the project or just in case.
To clarify the last point, I (as TL) can get the best React Dev in the world but, if he/she doesn't built up the knowledge on the rest of concepts named before, I won't let him/her act as TL. Why? Because when a client asks if something is possible, the answer is YES the 99% of the time.
The question is not if it can be done but how much it will cost (in time or money). In my experience, devs that stick to a framework say "It's not possible to reach that" just because there is no way to workaround that provided by the framework (or they don't know about it) so it leads to a situation where another company can offer this feature while you don't, just because the person driving the project hasn't enough skills.
Last but not least, the hackernoon post also has issues when understanding concepts:
A website contains static content.
A web application is designed for interaction with end users.
And I just did a quick overview into it (I'm reading it later on, promise).
Now
and
In what way is learning to use the React ecosystem different from the frameworks that you so summarily dismissed?
Focusing on any one of them doesn't actually teach you about the web or web development in general. They all exist in their own epistemic bubbles which gloss over the importance of understanding "the platform".
If your goal is to find employment as a "React developer" (if there are opportunities in your local area) then by all means learn React and Next.js.
However in my experience Svelte is the best option for a "first framework" for somebody new to web development.
In many ways it simply extends many concepts that already exist in the HTML/CSS space so it extends foundational (rather than product) knowledge. And its performance profile is such that it can serve a wide range of web-based solutions; and SvelteKit looks promising.
Svelte for Sites, React for Apps
swyx γ» Oct 18 '20 γ» 14 min read
More importantly Svelte doesn't get in the way when you need to use "the platform" for functionality it doesn't cover. The same can't be said for React.
Now my personal preference is SolidJS (Marko for sites, Solid for Apps) for some technical reasons that may not be relevant for all use cases.
React's big advantage is the size of its ecosystem but consequently adoption requires aquisition of a lot of product-specific rather than foundational skills.
It's a standard templating convention (Mozilla Nunjucks) to operate in that manner.
JSX is just as contrived; the only difference being that Babel started transpiling it together with the rest of ESNext for
.jsx/.tsxfiles; but it isn't part of ECMAScript nor is it part of "the platform".And more to the point JavaScript is only one part of the HTML/CSS/JavaScript triad.
And that includes React and its entire ecosystem.
And yet, you recommend React as an entry point into web development.π
React is the centre of its own universe.
Islands Architecture
Look, it doesn't matter how many links to random posts or screenshots/embeds of external platforms you add in your comments.
All I can agree is on that React will die at any point of the future and that JSX is not part of "the platform".
Even that, JSX is almost HTML and following the same reasoning around that Svelte uses a "standard templating convention (Mozilla Nunjucks) to operate in that manner", JSX is also a standard.
Just to clarify no, Nunjucks is yet another templating language, nothing more, nothing less.
Now back into React. There are several reasons for using it as I explained before.
When you use React you use JavaScript the entire time.
Do you want to use a hook? Do it. Do you plan to code a vanilla JS component? Do it. It doesn't matter if it's wrapped inside a React component or not, or if it uses JSX or not or... and it doesn't matter because React are a bunch of functions, nothing else.
I used Angular and Preact on projects that are still in production.
Also tried Svelte when in december 2016 and Svelte 2 short after it's release and haven't even bothered to try Vue. The list can grow with a big bunch of libraries and frameworks if we start talking about the past but to make it short every time you get a -mostly- opinionated framework you end up having to learn a whole new syntax and a whole new logic.
What React offers?
Two things.
1- The first one is a clear FP approach to render UI components, straightforward, easy to understand (from my PoV). The most complicated thing may be to use className instead class in HTML tags π or understanding the lifecycle and what those hooks do if you're new to FP.
2- It does what it does. As it's description states "A JavaScript library for building user interfaces" it does just this and nothing else. You can handle the rest as you wish (or as your project needs).
Also, seems that the major part of devs across the world think the same.
Is React the fastest? Nope. Is it the easiest to learn? I don't know if the easiest but one of them for sure.
Disagree completely. You need interaction to get an application by definition, you enrich the UI with a great visual design to increase the interaction time and markup is something needed to make the content readable.
I don't really know where all that mixed unrelated concepts came from and why is it all together in the same comment, honestly. HTML Islands? The post you linked was written in Aug 11 2020 and HTML islands is an old concept before HTML 5 came up (like 12-14 years ago?) it's still a great conceptual way to integrate frontend apps together but I can't find out the reason to bring it up on this topic π€·ββοΈ
The final smash on that is the current state of the art. If you want to work, you'll learn things that people uses. More users, more opportunities.
If it's any consolation, I also think svelte is cool but not enough to be considered for production, because someone will need to maintain it and.... good luck finding someone for the job.
Moreover if a new learner starts with svelte he/she will learn it's specific syntax that nothing has to do with "the platform" in it's standards, which is not the case with React.
There is nothing random about those links. Granted they are going to reflect my own bias but I also regularly post links to content I don't agree with inviting the reader to make up their own mind; to carefully scrutinize the information they are presented with, regardless of source and that includes everything that I state.
"JSX is an XML-like syntax extension to ECMAScript without any defined semantics."
ReactNodes, in SolidJS it creates DOM elements.JSX elements represent components in the component tree which relates to but isn't identical to the DOM tree.
And in React Native there isn't even a DOM much less HTML.
Neither is a W3C standard. The point was that Svelte's approach to templating is just as "legitimate" as JSX.
Again what is the point of this statement?
On the one hand you accept JSX as a useful DSL but on the other hand you want "just JavaScript". From that perspective a Vue SFC is as much "just JavaScript" as a React component with JSX.
Ultimately that is true for all the other frameworks as well. And Meta is continuing to experiment with compilers.
It has changed a lot since then.
Again that's a fallacy. The React community calls them Function-al components. Even the React documentation calls them Function components. React leverages immutability to it's own ends and function components, render functions, that access hooks are impure from the FP perspective.
What React gives you is "declarative UI", i.e. you don't have to constantly, imperatively fiddle with DOM elements.
People always find matters they are familiar with easy to understand.
Solid.js feels like what I always wanted React to be
i.e. it's fairly easy to find testimonies that React is anything but straightforward; so it's not as cut-and-dried as you portray it.
As long as it aligns with the React community consensus; React dictates a certain architecture therefore it has a distinct opinion which in itself isn't necessarily a bad thing until such time that the particular constraints it sets actually get in the way.
"What is clear: right now, if youβre using a framework to build your site, youβre making a trade-off in terms of initial performanceβeven in the best of scenarios."
[ref,
alt]Framework Usage Distribution in the Top 1 Million Sites
So I guess you'll be getting on that PHP gravy train, right? It's the most prevalent β¦
You really need to read things more carefully and not just see what you want to see.
"HTML Islands" doesn't occur anywhere in that article. It's Islands Architecture and a counter point to your claim of the false "site vs. app" dichotomy. There's a whole range of options in between. In fact enterprise consultancies are now starting to warn their clients about the SPA by default approach:
"the sheer prevalence of teams choosing a single-page application (SPA) by default when they need a website has us concerned that people aren't even recognizing SPAs as an architectural style to begin with, instead immediately jumping into framework selection. SPAs incur complexity that simply doesn't exist with traditional server-based websites"
Sure but it doesn't mean you have to settle.
The title for this article is "Getting ready for my first website: Choosing the right platform".
The extensions you need to adopt when working with Svelte are minor compared to the concepts that you have to assimilate with React. React introduced hooks in early 2019 and people are still complaining about them (and lets not forget the continued moaning about React 18; for example useEffect and useEvent).
There are of course a big bunch of different opinions, specially on a tech that has >15million daily downloads.
Either way and just because it has >15million daily downloads it's the go-to unless learning has not the purpose of finding a job afterwards.
The question is simple. Do you need SEO?
Is it a website? You'll be fine witj just HTML and CSS with few grains of JS.
This is applicable to the major part of cases currently.
Both SPA and classic SSR have its nuances and complexities. It was easier to develop with good Ol'SSR but it's also much harder to maintain.
Maintenance being a top cost for companies and us providing solutions come first to find "best practices", "rulesets" like SOLID and DRY, leading the industry to code separate backends. Guides arose to transform a monolithic application into services then into microservices where it suits.
Having the front-end attached to a backend leads you to few maneuver ability. i.e. you're using Smarty template engine inside a PHP backend and you see the need of complex computational tasks on new features that business needs. You may want to code this "service" in Java, Go or any other language that's capable of it efficiently. But Smarty works on PHP. So you've a problem and the cost of solving that problem is undesirable.
Options:
As I'm always saying there's no tech to rule them all, but if anything goes mainstream there are technical reasons behind that choice.
There are hundreds of thousands of template engines, frameworks, libraries and so on out there, a good number of which are mostly useless, others have its niche and others have a general purpose.
Understanding the target of each and the differences against the rest of the options as well as acknowledging the context you're dealing with is key to make the right choice.
So you're advocating tool selection based on popularity, not whether it's the right tool to solve the problem.
So people who access services behind a login screen don't deserve the UX that contemporary SEO is attempting to foster? The prediction is that Interaction to Next Paint (INP) is going to heavily penalize many React-based apps.
Hard to maintain perhaps but harder than an SPA?
The reports that I've come across suggest that SPA projects require more staffing than more conventional sites, compounding the negatives.
Best practices are valid within a specific context outside of which they are no longer best practices. That's why DRY has to be balanced with Beware of the Share and SOLID is being challenged by CUPID; there are no universally applicable rule sets.
Actually there is a perspective that properly bounded microservices are valuable because of they're (quickly) replaceable:
That has more to do with boundaries exerting just the right amount of cohesion on the inside combined with the right level and kind of coupling on the outside.
That maintenance cost could be lower when things are easier to replace isn't too great a stretch.
But just because you are using microservices or components doesn't mean that you'll be able to find the optimal boundaries right away. So there is no guarantee of "lower cost maintenance"; using more complex tooling makes it easier to miss the target. And at times components are not the right boundary:
Components are Pure Overhead
Ryan Carniato for This is Learning γ» May 10 '21 γ» 6 min read
Meet eBay's Marko. It has supported out of order streaming even back in 2016 (Marko 3). It will start to stream the page even before "the calculation service" has finished.
Popularity doesn't necessarily correlate to quality and popularity isn't necessarily based on technical characteristics. Many have argued that PHP's popularity was primarily due to the availability of cheap shared hosting, so the driver would have been an economic one.
React's popular feature is "declarative UI", translation: "You don't have to fiddle with DOM elements/objects". And while React Native was released 22 months later, VDOM could have been adopted with that end goal in mind. So "declarative UI" could have been a happy accident. And as the Elm community keeps pointing out components are objects (even with function components). So there's the theme of the promise of reuse in terms of components and across platforms. However that kind reuse comes with trade offs:
Again the motivation behind reuse seems to be largely economic, not technical, since this kind of reuse introduces undesirable coupling.
Now lets say "declarative UI", components and promise of reuse is enough to let React hit critical mass in terms of developer availability; i.e. it becomes easy to hire for. At that point the "popularity" becomes self perpetuating; React is chosen because it is easy to hire for, people learn React because it's in demand. Again this kind of popularity is non-technical.
So I think it is entirely possible for something to get popular without "technical reasons" contributing to it.
But that is the core of the problem; SPA/React predominantly being chosen without any consideration of context; that's essentially the Thoughtworks radar assessment:
"Too often, though, we don't see teams making that trade-off analysis, blindly accepting the complexity of SPAs by default even when the business needs don't justify it. Indeed, we've started to notice that many newer developers aren't even aware of an alternative approach, as they've spent their entire career in a framework like React."
SPA/React is the current industry's Golden Hammer.
Lots of services don't need to be either stateful nor apps but go SPA just for the native-like perception and aesthetics, not any real usability benefits.
React was only created for stateful and apps (taking on additional trade offs to accommodate React Native). Creating ecommerce apps with React can be risky:
Now Shopify's Hydrogen is React based but they are pushing hard to get React Server Components going to make up for lost ground (and as it so happens Jason Miller is now at Shopify (Platform DX) as well).
The only reason for using SSR for SEO purposes is the inhability of the crawlers to properly crawl an entire SPA site.
Don't you remember why we jumped from SSR to SPA? Just because you don't need to reload the entire site each time a click is made.
Yes, AJAX as popular just before SPAs, do you remember?
Isn't that the most important?
Yes. And finding what you need if you don't use reusable components is just a matter to find your button inside the rest of 93810 buttons. Sure it will make things easier π
The Amazon being SSR is changing btw, the contact part of the web app is now reactive (I noticed the upgrade on Sunday), we could dicuss why amazon is so slow changing its web app but that's another story that doesn't compete here. Oh and, know what? Amazon used React for the job :)
React is a framework now? How come?
The only devs I met who don't know other approaches came from a codecamp (3 month, stack rush learning approach) or self-taught (you learn what you like or what you feel necessary) and from both groups together only 3 of those I met fall in this description.
On the rest, let me state a sort of a rule:
For the same features and behavior, the complexity is always the same and every time you add more features you add more complexity as well.
The question is not if it's complex or not, the question is where do you want the complexity to be.
May 2020: Page Experience Signals
Poor page experience signals tank your search rank. SSR has been about good "user experience criteria" for a while now which meant that SSR needed to be fast and in the general it wasn't.
And we're going back again, doing it differently this time.
The point was that it's not a technical reason.
Being able to pay the bills is important. But if you can only make a profit by negatively impacting everything else then you need to stop and find something else.
π
David Flanagan @Mozilla 2019-02-15:
"But also, by choosing the framework that is dominant today, we maximize our chances to find volunteers, contractors and consulting shops to help us when we need it."
React appearing everywhere just illustrates the current human resourcing situation, it's not an indication that React is the best-of-breed solution for the problems it is being applied to.
What the Amazon tweet was about is that React isn't used in parts of Amazon's software that are critical to the business.
I'm not going down that rabbit hole again. In software engineering terms React is a framework; it doesn't matter that the React docs call it a library and that React is nothing like Angular.
No Silver Bullet (1986)
"A fundamental point the article makes is that there are two types of complexity feeding the software crisis; accidental complexity and essential complexity. Accidental complexity occurs due to mismatch of paradigms, methodologies, and/or tools in our application. This type of complexity can be eliminated given sufficient resources to build or buy tools that complement one another. [β¦] The real culprit of the software crisis is essential complexity. Essential complexity revolves around the fact that software is intrinsically complex, and no methodology or tool is going to eliminate this complexity. There are several reasons why software possesses essential complexity:
Riel, Arthur J. (1996). Object-Oriented Design Heuristics. Addison-Wesley. (pp.3-4)
Over the years React hasn't been eliminating accidental complexity but accreting it.
Ultimately that is why SolidJS is becoming more compelling to developers who use React despite its much smaller ecosystem; it helps them eliminate accidental complexity.
Pointing the mdn github thingy but just mentioning the statement that suits you wasn't right, let me take care of it:
Actually David Flanagan did so good speech that I don't even need to go further with this.
Oh and by the way, your comment here is completely wrong.
You call
ReactDOM.render(<App />, document.getElementById("root"));and YOU pass the components you want inside App component, it's not React calling you, it's you sending functions (components) to React. And those other things exists to fill some needs few have on this topic as IoC is not applied nor provided by React.Sure you'll find people buying your nonsense but to anyone reading this, just go to React's homepage and you'll read "A JavaScript library for building user interfaces" right in the hero. I don't think this needs further absurd discussion.
I barely can hear that far cry that says "Punk's not dead!" but the stubbornness to go against the current is reaching unsuspected limits in this topic and the last stand should be taken in a different place, not on a science related field IMHO.
"and found it to be a huge productivity boost."
Out of context this sounds great.
However whenever I dig into it, it always comes across as the "productivity boost" from moving something from an "artisan craft" to an "assembly line". And while that was responsible for industrialization, today's car assembly lines are serviced by robots, i.e. those areas will be automated into oblivion at which point one better be the plant owner or have moved into robot maintenance or bespoke car assembly.
If React is going to do the framework thing of calling user code then you have to inject the user code somewhere β¦ π€¦
50 billion flies can not be wrong. β¦
bandwagon fallacy
"If imho can mean humble or honest, then the internet is full of noise and empty of soul: little more than a broadband Tower of Babel."
[source]
Look, I can be wrong but you continue to fail at producing convincing arguments.
I'm sure you'll have some last words to get in edgewise.
Oh sure!
The context seems to matter just when it cames convenient to your message, Isn't that the Appeal to Convenience fallacy?
Bringing the Argumentum ad populum has lots of sense on ideology, thoughts and likenesses but here is claiming that the entire industry is wrong and that the reasons behind are not valid; technical profiles, architects, business...
You've work to do pal. Overall you bringed an argumentum ad lapidem and that's a bit sad because no knowledge can be extrapolated, just references.
?? You injecting the code is just the opposite of inverting the control, that's why it's called inversion of control π π€·π»ββοΈ
I heartly recommend you to try to understand why React has the lead instead pushing against it.
I tried some of the frameworks and libs (Angular, Svelte, Preact, React, Next...) and have a formed opinion on every one of them. I do like more than one and I use more than one in a regular basis (when they suit). Solid JS (that seems to be your favourite one) is on my list for future check after Polymer and a couple of things that are more urgent to me (I do not work only in frontend).
You can like more than one at the same time, is not that difficult.
Is like buying a car, you like some different models, you may test them, see the equipment each bring, the optionals, the pros and cons and end up picking one because at the end you only have one ass and a limited budget, hence you just need one of them and it needs to be convenient. That doesn't mean that you don't like the rest from now on.
At the current State of the Art, React is usually more convienent for different reasons, not necessarily technical and it is what it is like it or not.
That doesn't mean that the rest are shit. While Angular has some bad vibes, svelte seems to be pushing step by step and I don't know if solid will ever be a market option, will see.
Disregarding my arguments (ease to use, web standards, market share, ecosystem, ease to find devs with previous experience, less decoupled of the language core API...) just because you don't like them or they are against what you would like the world to be won't make'em falsy.
Gosh You even disapproved the arguments of David Flanagan, -which you linked by the way- and which is a reputed engineer in the industry.