DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for Getting ready for my first website: Choosing the right platform
Anna Baker
Anna Baker

Posted on

Getting ready for my first website: Choosing the right platform

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 sounds. Some people just drop a WordPress installation and paste a theme on it, but I'm looking for something more interesting and advanced.
Building a site involves a lot of planning in choosing the right framework for the task. So with that thought, I'm writing this article about choosing the right framework. Should it be react, Vue, Next JS, or even something I'm not familiar with?

Define Your Purpose

When it comes to building your first website, it's important to take some time to figure out what your purpose is. Why do you want to build a website? What are you hoping to accomplish? Once you have a clear understanding of your purpose, you can start to research and plan accordingly.
For me, I wanted to build a website for learning purposes, I wanted to be able to share my knowledge with others and help them learn new things, I also wanted to be able to connect with other like-minded individuals.
Take the time to figure out what your purpose is for building a website, Once you have a clear understanding of your purpose, you can start to research and plan accordingly.

Researching The Right Framework

React

When I first decided that I wanted to build a website, I had no idea where to start. Finally I decided to start with React, because I had heard good things about it, but I didn't know much about website building. So, I started doing some research. I read articles, watched videos, and talked to people who knew more about React than I did.
Through my research, I learned that React is a JavaScript library for building user interfaces. It is declarative, meaning that it makes code more predictable and easier to debug. React is also component-based, which means that it is easy to reuse code and create modular applications. And finally React is a great choice for beginners because it is easy to learn and there is a lot of documentation available.

Next JS

Then I had the opportunity to learn about Next JS, a React framework for building server-side rendered and static web applications. I was really impressed with how easy it was to get started and how powerful the framework is.
Next JS is a React framework that allows you to easily build server-side rendered and static web applications. It is very easy to get started with and has a lot of powerful features. Some of the features that I found to be most useful were the ability to easily create dynamic pages and the fact that it makes deployment very easy. I also really liked how Next JS makes it easy to code splitting and to lazy load components, which can help to improve the performance of your application. Overall, I think Next JS is a great framework and I would definitely recommend it to anyone looking to build a server-side rendered or static web application.

Vue JS

Finally I took some time to learn about Vue JS, and I have to say that I was impressed with what I found. Vue JS is a JavaScript framework that is designed to be lightweight and easy to use. It offers a great way to build web applications using a component-based approach.
One of the things that I really liked about Vue JS is that it offers a great way to manage state. State management can be a challenge in large web applications, but Vue JS makes it easy to keep track of your data and components. In addition, Vue JS provides a number of features that make it easy to build interactive applications.
Overall, I was really impressed with Vue JS. It is a great framework for building web applications. It is easy to use and offers a great way to manage state. If you are looking for a way to build interactive applications, then I would definitely recommend checking out Vue JS.

There are a number of great frameworks available for building websites, and each has its own strengths and weaknesses. React is a great choice for beginners because it is easy to learn and there is a lot of documentation available. Next JS is a great choice for those looking to build server-side rendered or static web applications. And finally, Vue JS is a great choice for those looking to build interactive applications.

Do you have any suggestions for an easy to work with, interesting and engaging framework that I can use to build my website? I would like to learn as much as I can from the process while working on it πŸ₯°

Top comments (48)

Collapse
joelbonetr profile image
JoelBonetR • Edited on

IMHO... My advice is to use React or Next JS straight away.

Reasons:

  • React is a lib, not a framework hence to reach most of the things you'll need either to find a solution on your own or a lib that covers that specific need.
  • Vue, Angular and Svelte, to mention some, are frameworks. Well, svelte is a compiler if we're more strict choosing words but by all means, all of them apply their own syntax, separating you from JavaScript.
  • Jumping from framework to framework does not improve overall knowledge of the main language core API nor about the environment or anything else.
  • Next JS also implements React and you should use Next whenever you need SSR or SSG. Or just a monorepo with Node and React in the same place with a pre-defined structure and built-in features ready to use.

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

Collapse
annabaker profile image
Anna Baker Author

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 :)

Collapse
joelbonetr profile image
JoelBonetR

You're welcome! We have a big community here around JS, share your steps anytime you need feedback 😁

Thread Thread
annabaker profile image
Anna Baker Author

Great to know 😁

Collapse
tealover418 profile image
Stijn de Ligt

Would advice using NextJS since it's built on React and is much less work to set up.

Thread Thread
joelbonetr profile image
JoelBonetR • Edited on

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).

Collapse
peerreynders profile image
peerreynders • Edited on

If you want to become a senior with JavaScript it is better to fight and learn the platform to understand the nuances of it.

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.

Collapse
joelbonetr profile image
JoelBonetR

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 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).

Thread Thread
peerreynders profile image
peerreynders • Edited on

Now

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.

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.

in Svelte you'll use {#each items as item, index} which of course is not valid in JS nor in HTML.

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/.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.

  1. Content is the foundation
  2. Markup is an enhancement
  3. Visual Design is an enhancement
  4. 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.

Islands Architecture

Thread Thread
joelbonetr profile image
JoelBonetR • Edited on

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.

Thread Thread
peerreynders profile image
peerreynders

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.

  1. 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.

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.

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."

[ref, alt]

seems that the major part of devs across the world think the same.

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 …

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).

Thread Thread
joelbonetr profile image
JoelBonetR • Edited on

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.

Thread Thread
peerreynders profile image
peerreynders • Edited on

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:

Options:

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."

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).

Thread Thread
joelbonetr profile image
JoelBonetR • Edited on
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.

Thread Thread
peerreynders profile image
peerreynders

The only reason for using SSR for SEO purposes is the inability of the crawlers to properly crawl an entire SPA site.

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.

Don't you remember why we jumped from SSR to SPA?

And we're going back again, doing it differently this time.

Isn't that the most important?

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.

πŸ˜‚

πŸ™„

Amazon used React for the job :)

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.

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.

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:

  1. Software applications, for their size, are the most complex entities that humans build.
  2. Software is intangible and, for the most part, invisible.
  3. 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.

Thread Thread
joelbonetr profile image
JoelBonetR • Edited on

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.

Thread Thread
peerreynders profile image
peerreynders

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 … 🀦

but the stubbornness to go against the current

50 billion flies can not be wrong. …

bandwagon fallacy

IMHO

"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.

Anyways, thanks for the debate.

I'm sure you'll have some last words to get in edgewise.

Thread Thread
joelbonetr profile image
JoelBonetR • Edited on

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.

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.

Collapse
psypher1 profile image
James 'Dante' Midzi

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

Collapse
annabaker profile image
Anna Baker Author

Thank you for your comment!

Collapse
psypher1 profile image
James 'Dante' Midzi

Looking forward to seeing what you build

Collapse
peerreynders profile image
peerreynders

For me, I wanted to build a website for learning purposes

This can be used to justify about everything so it doesn't really narrow things down.

I wanted to be able to share my knowledge with others and help them learn new things, I also wanted to be able to connect with other like-minded individuals.

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

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.

  • It's a good foundation to build something fairly simply but supported by a good set of tooling that is improving all the time.
  • There is plenty of flexibility to add more functionality to pages with framework components (React, Preact, Svelte, Vue, SolidJS, AlpineJS, Lit).

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.

Collapse
annabaker profile image
Anna Baker Author

Thank you for the suggestions! I will check them out.

Collapse
ecyrbe profile image
ecyrbe

You all should read this

Collapse
sem1colons profile image
Youssef Abdulaziz

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.

Collapse
annabaker profile image
Anna Baker Author

I'm glad to hear that you've had a good experience with Vue. I'm definitely considering using it for my website

Collapse
sem1colons profile image
Youssef Abdulaziz

Definitely support that 100%, you won't regret it....good luck.

Thread Thread
annabaker profile image
Anna Baker Author

Thank you!

Collapse
incrementis profile image
Akin C. • Edited on

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.

Collapse
annabaker profile image
Anna Baker Author

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 :)

Collapse
nathan20 profile image
Nathan

I liked your article! I can suggest to try angular, We can collaborate together if you want :)

Collapse
annabaker profile image
Anna Baker Author

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 :)

Collapse
nathan20 profile image
Nathan

Send me a message on my Twitter/LinkedIn, then we will could discuss about it.

Thread Thread
annabaker profile image
Anna Baker Author

Sure will do :)

Collapse
yigblst profile image
yigblst

VUE, your welcome.

Collapse
annabaker profile image
Anna Baker Author

Thanks!

Collapse
techthatconnect profile image
TechThatConnect

What kind of site are you building? Iam making my first site right now as well .

Collapse
annabaker profile image
Anna Baker Author

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?

Collapse
techthatconnect profile image
TechThatConnect

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

Thread Thread
annabaker profile image
Anna Baker Author

That's really cool! I'm excited to see what you have in store for when it goes live

Collapse
eshimischi profile image
eshimischi

Astro.build

Collapse
youssefmic profile image
Youssef-mic

Also, you may consider Redwood JS which is promising or gatsby.

Collapse
annabaker profile image
Anna Baker Author

Thank you for the suggestion!

Collapse
richardevcom profile image
richardevcom • Edited on

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.

Collapse
annabaker profile image
Anna Baker Author

Thank you for your advice! I appreciate you taking the time to help me out. :)

Collapse
ravavyr profile image
Ravavyr

Ok, so what struck me here is that you said

Some people just drop a WordPress installation and paste a theme on it, but I'm looking for something more interesting and advanced

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.

Collapse
apimike profile image
Mike Rozner

At most, I agree with your post up to:

You want to learn and share things on 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.

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.

Collapse
ravavyr profile image
Ravavyr

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.

🌚 Life is too short to browse without dark mode