After my last article about Typescript, I've decided to move forward and start building a website.
Building a website isn't as simple a task as it ...
For further actions, you may consider blocking this person and/or reporting abuse
IMHO... My advice is to use React or Next JS straight away.
Reasons:
If you want to become a senior with JavaScript it is better to fight and learn the platform to understand the nuances of it. That bunch of libs, frameworks, compilers and so on are live now. But like any other they will eventually disappear as it happened before. (i.e. JQuery mobile was deprecated and JQuery UI is dead with a single version upgrade in like 8 years).
On the other hand, you can choose to use TS or not. But the thing doesn't stop here.
You can also use Flow, maybe a less invasive approach as we discussed before (reference) or, if you're using React maybe the straightforward way to handle that is to use proptypes or even none of them.
Whatever you end up with I recommend you to follow a TDD approach because no other thing can give you confidence in your code.
You may find this book useful.
Best regards
Thank you for your advice! I will definitely consider using React or Next JS. I appreciate your thoughts on frameworks vs. libraries and the importance of understanding the JavaScript language core. I will also keep in mind your suggestion to follow a TDD approach.
I started learning JS and TS from advice that I got from a friend, but I always looking for new things to learn :)
You're welcome! We have a big community here around JS, share your steps anytime you need feedback 😁
Great to know 😁
Would advice using NextJS since it's built on React and is much less work to set up.
Well yes but it serves a different purpose.
I do usually use Next JS on sideprojects because I have Node and React in the same place and I already know how Next JS works due to both side projects, PoCs and projects that are in production made at work. It's pretty convenient to build a monolithic application quickly but if you just need a frontend it would be inefficient.
Also some practices you probably use in frontend of Next apps are not aligned with what you'll find in React-only projects as it includes opinionated components for different purposes (i.e. Next/Image).
So like always it just depends on the project needs 😁
On the other hand, setting up a React project is just...
npm i react react-dom, creating an index, an App main component and you're done mostly, plus you can use whatever bundler you like (i.e. Parcel which, once you understand how to properly use it's zero config or mostly).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.
I've recently been looking at other ways I can get sites up and running. On that investigation I've tried .... Eleventy, Astro and Svelte
The first 2 excel at static content, the third does a good job of not straying to far from the Web conventions we're used to
Thank you for your comment!
Looking forward to seeing what you build
This can be used to justify about everything so it doesn't really narrow things down.
This sounds like a blog with perhaps a comment section.
From my perspective your research was fairly narrow.
There are two articles that may be helpful
Patterns for Building JavaScript Websites in 2022
Ryan Carniato for This is Learning ・ Jun 8 ・ 9 min read
and experiences. Web. frameworks. future. me.
This should give you the wide 20,000 foot view of what is going on right now.
So my inclination would be to give Astro a very good look.
So you could start with SSG functionality for content with markdown and MDX then perhaps add social networking related client side functionality with webmention, Staticman, utterances, or some other way novel way.
Thank you for the suggestions! I will check them out.
You all should read this
After using both Vue and React I can 100% assure you that Vue easly Stomps React in everything. The thing is that Vue is not built by the holy saviour Facebook so it's not that popular although how amazing it is.
I'm glad to hear that you've had a good experience with Vue. I'm definitely considering using it for my website
Definitely support that 100%, you won't regret it....good luck.
Thank you!
Hello Anna Baker,
Thank you for your article.
It gave me an overview of React, NextJS and VueJS.
Unfortunately I can't recommend you which framework is the best because when I wrote my first and last personal website I used Notepad++ and a browser to implement it. The same applies to my internship as a web developer. The difference was that in addition to the tools mentioned, I also used WordPress.
The most important thing at that time was always feedback because it helped me eliminate some features that I thought would be cool :D.
Hello there,
Thank you so much for your kind words on my article! I'm glad it was helpful in giving you an overview of some of the most popular frameworks out there.
I totally agree with you, feedback is a great thing :)
I liked your article! I can suggest to try angular, We can collaborate together if you want :)
Thank you so much for enjoying my article! I may give angular a try in the future, and I would love to collaborate with you if the opportunity ever arises :)
Send me a message on my Twitter/LinkedIn, then we will could discuss about it.
Sure will do :)
VUE, your welcome.
Thanks!
What kind of site are you building? Iam making my first site right now as well .
Hello,
I am building a simple website for learning purposes :)
It's great to hear that you are also building your first website! What kind of website are you looking to create?
I am doing a tech blog with JAMstack approach using 11ty. I am writing articles about its creation process on here then I have some articles to start the site with when it goes live
That's really cool! I'm excited to see what you have in store for when it goes live
Astro.build
Also, you may consider Redwood JS which is promising or gatsby.
Thank you for the suggestion!
Smaller scale - Vue.js all the way. SSR wise - Svelte Kit or Nuxt.js.
TypeScript should be now used by default on both ends if you write them in JavaScript.
Thank you for your advice! I appreciate you taking the time to help me out. :)
Ok, so what struck me here is that you said
And then you went straight into what 99% of newbies are using today. React/Vue Javascript frameworks that require a few npm installs and button presses and your site is done.
WordPress can actually be quite challenging if you were to build a custom theme, add custom plugins, use shortcodes and ajax calls to load dynamic data and apply caching, and so on and so on.
PHP in itself, building a site from scratch in PHP is relatively easy, but i'd say still more complex than any JS framework since again you'd actually be writing the url handling logic yourself. Try managing sessions and cookies and building a custom CMS in PHP versus any JS frameworks and you'll find it much more challenging and a greater learning experience.
I dare say Python would be a bigger challenge, mostly because i find it a tedious but simple language that likes things done in very specific ways so building anything with it would be more work than necessary.
Going back to JavaScript, why not build a dynamic site with nothing but vanilla JS?
That would also be far more of a challenge than using any framework. Note for PHP i skipped Laravel which is also a few commands away from having a done site without understanding how it all really works.
You want to learn and share things in your journey? then look at building things from scratch and you will learn a heck of a lot more than just installing premade code, writing some basic interactions on top and calling it a day.
Learning how things work from the ground up is the best thing a dev can do for their long term career. Once you do, all the tools and languages don't matter, you can work with any of them because you understand what's happening under the hood so to speak.
At most, I agree with your post up to:
Nowadays, building things from scratch is time-consuming and, overall, a waste of time. IMHO, an efficient way of building a website is to take advantage of the right technology and frameworks for the job.
I think that looking at the end product when starting, for example, if you want to build a web course site and that's the goal, I'd choose the most efficient way to do so. Also, the industry today is focused on frameworks and less on building by writing HTML, CSS, and JS from scratch.
However, if you want to become an expert in this field, you should start from scratch, but holy shit you're in for a long journey.
That's the thing, you're really not. The majority of websites lack features that take long to build from scratch.
Sure, if you're going to build a custom ecommerce site, or a calendar /task management application, inventory management tools, and such, using prebuilt stuff of course saves time.
But 10-20 page websites, meh, the tools hardly save you time if you know how to write custom html/css/js.
And i'm not saying this to be petulant. I'm honestly saying, you can build a full website just as fast from scratch once you understand those three languages well enough. This of course takes some years of web dev to achieve.
In the mean time tools do speed things up, but leave you stuck with bugs you don't understand since you didn't write the tools.
In the long run knowing the languages speeds up your entire process, including when you choose to use tools to speed certain aspects up, but you'll also know better how to debug problems with those tools since perfect tools do not exist.