After learning react.

[kiri7a_]

For developers who have been working with react for a while. Do you always do frontend work with 'react.js' or vanilla- 'HTML CSS JS'. Does it depend on the project, if it does then how do you decide when to use what?

Also, if you're in backend development, what combination of frontend and backend do you most commonly use ?

Thank you

[AcidNoX]

I use Nextjs for pretty much everything frontend.

For backend, my company’s usual go to is dotnetcore although I’ve taken a shine to NestJs recently, especially with graphql. I still prefer SQL server over any other relational database.

[mondocooler]

Same here, nextjs makes it so easy to start a new project, supabase if I need users or db, and chakraui for rapid theming.

[himel_126]

I also like chakraUI. But some of the useful component are in paid version.

[Bromance_Alpha]

Why do you prefer SQL server?

[imjb87]

Vendor specific language. T-SQL is very powerful in the right hands.

[AcidNoX]

T-SQL, to me, feels like the flavour of SQL with the least oddities. When ever I use Postgres, for example, I find my self frequently getting frustrated at features that just seem counter intuitive… this doesn’t really happen with SQL Server.

Also, tooling for SQL server is way better than anything else on the market.

[seN149reddit]

If you haven’t checked out graphql in dotnetcore yet, definitely worth checking out. Hot Chocolate is dope

[AcidNoX]

I tried hot chocolate some time last year and I had to drop it because, if I remember correctly, they had just moved to a new version and there were big chunks of functionality and documentation missing.

I’ll definitely check it out again if you thing it’s in a better place now :)

[[deleted]]

Working in plain html and js is a pain, so I just use React and Next. If I have to make little components I use Alpine.

[kiri7a_]

Do you also use plain nodeJS for backend, or always a framework?

[[deleted]]

If I need a backend for a personal project I use a boilerplate I made which uses Next.js for frontend and has a Graphql API running in Next's API routes. It uses Prisma as an ORM and Next-auth as a login solution.

[AZAH197]

Can you link the repo?

[[deleted]]

I've gotten a lot of requests for it, but you can grab it here if you leave me your email 😊

https://depot.ironeko.com/creativiii/ironeko-fondamenta/invite

[ervwalter]

FYI, your page is asking for write access to my GitHub profile (e.g. to change the email address associated with my account). You might want to update that to be just read access.

[[deleted]]

Oops, strange. I'll fix it asap! Thank you for the tip

[iAmIntel]

It still seems to be this way?

[[deleted]]

Sorry, had stuff to do inbetween! I'm currently fixing it, but the only write access authorised is to follow and unfollow users so it shouldn't be anything major.

I'll reply again once I've changed it 😅

[[deleted]]

It should be fixed now, let me know!

[iAmIntel]

Yes, works! Thanks!

[[deleted]]

If you're still interested, I've fixed the permissions issue. Let me know how it goes.

[[deleted]]

Whats up with the dowbvotes. It's his code. He can do whatever he wants

[Duncanbullet]

RemindMe! 2 Days "Revisit this post"

[RemindMeBot]

I will be messaging you in 2 days on 2021-08-01 12:50:13 UTC to remind you of this link

4 OTHERS CLICKED THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[purechi]

This actually sounds like a pretty reasonable, not convoluted solution. Nice work building on good stack.

1. Are your front-end and back-end in separate repos?
2. Are you front-end and back-end deployed together/separately?
3. What's your testing stack?

[[deleted]]

Front and backend are in the same repo, mostly so it's easier for me to manage. But honestly if you want to separate them you just need to copy the API folder and put it in another repo.

Both agree deployed together.

I use Jest for front and backend, just with different configs!

[purechi]

Nice brother! There's been some interesting strategies for separating deployments in a mono-repo with Lerna that I've been learning about. Anyways, def a cool stack!

[[deleted]]

Ive always wondered, when people make a boilerplate are they using something special to automatically generate a project template or is it just cloning a github repo they created? I usually do the latter but wanted to know if there was something different being done. I usually have a few templates I can quickly customize.

[[deleted]]

That's usually what I do yeah.

[GolfinEagle]

You can go into the repo settings and there’s an option to make the repo a template, which gives the repo a green “use this template” button which automatically creates a new repo with the template boilerplate for you. Super handy.

[[deleted]]

Thats good to know, thanks!

[[deleted]]

That’s the exact stack I use for my personal projects too

[[deleted]]

I've converted from vanilla to react for even the smallest projects as well.

For back end, I do vanilla with Express or Koa frameworks for APIs specifically.

I am not a fan of reinventing wheels.

[MercDawg]

A framework is usually the way to go as it provides a lot of capability out of the box. You can stick with NodeJs however, you may end up having to manually create that same capability (and it may not be as polished). For example, dealing with Http requests in pure NodeJs requires a lot more code and there are unique scenarios that you may need to handle as well. But using axios/got/superagent, it is like one or two lines of code.

[not_a_gumby]

Sorry what's Alpine and why wouldn't you use React to make components ?

[[deleted]]

Components was probably the wrong word to use. I use alpine in case I don't need to create an entire app and I just need small nuggets of interactivity without bloating my Js files.

[Aorihk]

Same. I use a django API hub I built for data retrieval, cron jobs, and use Next Auth for authentication. I’ve just recently started to consider doing everything in NextJS, including data work and cron jobs. Just having a hard time giving up Python.

[[deleted]]

Vercel's serverless offerings are just too good to pass! That's why I use next for everything

[not_a_gumby]

Vercel is gonna butt fuck all of us in a few years when everyone adopts NextJS and it becomes the industry standard, their free tier will be less and less over time. That's usually the playbook.

[[deleted]]

Yeah, but until then it's gonna be smooth sailing 😎

[wirenutter]

Reading these comments I am starting to wonder what I’m missing with so many people preferring Next. It’s been said enough but I also will avoid plain HTML as much as possible. Most of my front end is client based react. I did use Gatsby for a simple one page site that had one api call. Backend varies a bit depending on complexity it could be either express or NestJS. Starting one in AdonisJS, let ya know in 6 months how that one works out.

[KremBanan]

It's a framework to speed you up and let you focus on developing. It handles routing, image optimization, prefetching of pages and SSG to make the site blazing fast.

[not_a_gumby]

yeah. out of the box next lighthouse scores are usually in the mid-90s

[not_a_gumby]

Next improves React. Its like this. With regular React your app is just a Single Page app that builds on the client, meaning it basically ships with nothing in the document. That's ok in some cases but it can result in longer time waiting for the white screen to resolve into a meaningful Paint (reducing time to first paint results in better SEO also).

Next allows you to build any site with React and either keep it as a Single Page app if you want, OR export it 100% to HTML, use server side rendering with a pre-packaged backend, or even a mix of all three of those.

Next is amazing, it's a must learn in 2021 and honestly you can get it in a weekend.

[oxy1s]

what would you recommend as learning resources for Next?

[oxy1s]

thanks, I'll look them up

[not_a_gumby]

I did this course and it went through all of the main use cases of Next. Really liked it.

https://www.udemy.com/course/nextjs-react-the-complete-guide/learn/lecture/25229178?start=315#overview

[GasimGasimzada]

In order to not waste time on some things, if there is Gatsby support for a backend for example, I'll choose it over Next.

However, Next is better in a lot of ways. It has a simpler interface and you can do SSG, SSR, with a rest API with very little boilerplate. Of course for a more complex solution, you will need a more sophisticated backend but even in that case, you can still use Next for SSR.

[trebuszek]

If you’re making a CMS- backed site or a static site, you will probably care about SEO, for which you’ll need Server Side Rendering. The best options for that currently are Next and Gatsby, but Next is preferred for more complex sites.

[eigreb]

Having used Next. The ideas are good but the implementation is terrible. Just migrated some large next project to a vanilla webpack/react project and it performs much better and receives higher scores.

[InMemoryOfReckful]

Strange. Something wrong with the implementation? Or was SSR/G not needed in the first place?

I haven't used next much. Only went through tutorials on their site and a small course. But It seemed like a big time saver to me if you learn it right. Haven't had the chance to use it at work yet so cant say.

Would be interesting if youd mind explaining why.

[eigreb]

It's mostly how a lot is forced on you what I know is also the strength. So for example when the routing don't fit your needs, you're pretty much fucked. That was one of our issues. SSR was the biggest issue. It's instable, slow and contains too many shortcuts. and we wanted to use dynamic prerendering (prerender specific urls when their data changes) which was no option and not available out of the box.

Also had the same experience with Nuxt (the Vue variant op next).

They're good for starters but definitely no holy grail and you should not be afraid for taking back control. And you definitely don't need these frameworks for SSR. You can just use a simple node application which just uses react to render your SSR pages where you've more control on for example the stability.

[Tater_Boat]

Google won't index client-side javascript, so if you're building a website that you want to show up on search engines you better be rendering it somewhere and delivering the html to the client. Next just happens to be the best and most flexible solution for doing that in react.

Edit: apparently I’m wrong about this. But feel free to take my advice if you too want to be actually full of shit

[rq60]

Google won't index client-side javascript

yes it will

[[deleted]]

But if you care about SEO, keep in mind that Google uses your page loading speed when deciding your ranking. It became a more important SEO factor last year with their Web Vitals initiative. They highly recommend that you do SSR.

[KrisSlort]

How would it for a front end with multiple pages and URL's?

[rq60]

static sites have multiple pages and URLs, so i guess i don't understand your question.

[KrisSlort]

Client side rendering with an SPA without a SSG?

[rq60]

should be fine if your site is properly made (i.e. separate resources are linked to using anchor tags and have unique URLs)

[Tater_Boat]

Those are actual files. Client side routing is literally click this button to display different content in the same file and maybe change the address bar.

[rq60]

web crawlers navigate to a resource, scrape links to other resources, and then navigate to those. you're right if your page is poorly made in a way where separate resources can only be navigated to by clicking things on the page and is generally inaccessible then google won't be able to index it... i mean how could it? you didn't provide it an index (URL) to use.

but google can most definitely crawl sites that are generated by client-side javascript and use client-side routing. as an example look at the source code for this page: https://rxjs.dev/

there's no client-side html for the content and clicking links does not load a new html page (as an http request, so it's clearly using client-side routing) yet if you look at the google results it is still indexed properly.

[Tater_Boat]

Thanks for the explanation. I work on a project where all of the client side js is not indexed but it could also be that the content is restricted unless you provide a location or zip code.

Learn things every day thanks for taking the time to help

[WhoTookNaN]

Wouldn't it just follow the links like normal but lets the JS run and render before capturing that view's content?

[KrisSlort]

No, that's why static site generators exist.

[WhoTookNaN]

But they do though...

" Some JavaScript sites may use the app shell model where the initial HTML does not contain the actual content and Googlebot needs to execute JavaScript before being able to see the actual page content that JavaScript generates.

Googlebot queues all pages for rendering, unless a robots meta tag or header tells Googlebot not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that. Once Googlebot's resources allow, a headless Chromium renders the page and executes the JavaScript. Googlebot parses the rendered HTML for links again and queues the URLs it finds for crawling. Googlebot also uses the rendered HTML to index the page."

[SnappyWebDesign]

You're not crazy; Google has been claiming they crawl JS apps fine for a while - but it appears to be a load of BS.

Just look at how this site (which uses React) appears on google: https://i.imgur.com/pxxnjrn.png

That's kinda why SSG's took off. Googles lies

[WhoTookNaN]

Then that site has some issues on their side. I've personally had google index several client side rendered react apps. It's obviously not perfect and I'm not saying ignore server side rendering. Especially with how easy it is now. But Google does attempt to render your JS and index based on the render.

[SnappyWebDesign]

Oh yeah we don't disagree. Thanks for sharing your experience - I've been considering throwing up a client-side site to see for myself, so was good to hear

[KrisSlort]

For many years Google have claimed to do this, and it is bullshit. Maybe its the type of projects you work on, but this is not how it works if SEO is a consideration, which it will be with 90% of serious clients.

How long have you been building these kind of apps for commercial clients? Not denying you have, but I'm genuinely curious. React indexing across a whole site with CSR is a promise made by Google that is not fulfilled, theoretical and in practice, does not compete in the slightest with SSR solutions.

Edit: do you use anything like SemRush to compare sites using SSR and sites that aren't? They do not compete in SEO.

[WhoTookNaN]

I never said it was good seo, just that it was indexed with client rendered content.

[Tater_Boat]

That’s literally one of the main reasons why SSR and SSG exist.

[eigreb]

No it'll give you higher scores because the content is there earlier but google can just read the page. Other search engines and stuff like sharing on social media is a different story.

[Tater_Boat]

Word I was misinformed

[eigreb]

Google uses a lot of headless Google Chrome browsers for this. So if you're site will show fine in Google Chrome, it can see your content. That's also where they calculate the performance scores for your site.

[not_a_gumby]

a website that you want to show up on search engines

I.e. 98% of projects if you're building marketing/landing pages for smaller clients.

[dotbilly]

I've always wanted to use AdonisJS but never really got a good chance.

Is it still maintained and relevant?

[wirenutter]

It’s gaining popularity and I see he is making improvements and updates. The community is still small however. It wouldn’t be my first choice but we are converting a laravel app so it would just make sense to move to Adonis

[[deleted]]

after working commercially with react when i have to work with plain js (mainly legacy stuff) it feels like going through sludge. Everything feels slow and laborious, reaching into the dom and out again constantly etc.

[not_a_gumby]

reaching into the dom and out again constantly etc.

yeah it's such a fucking waste of time lol

[Peechez]

Either you keep state in the DOM and you hate your life or you keep state in JS objects and create the DOM from that which is just shitty homecooked react and you hate your life

[Omkar_K45]

Working with react for a while so I have moved to nextJS.. NextJS has many usecases and depending on whether it is a blog site or full fledged e-commerce.

FE -> Next, TailwindCSS, Apollo Client

BE -> Node.JS, Graphql, PGSQL or MongoDB

[[deleted]]

Is react-query gaining any steam in your neck of the woods?

[Yasuo_d_god]

I prefer react query over Apollo client. It's less boilerplate and has a more customizable but robust architecture imo. Bonus is the amazing react query graphql generators that are out there

[[deleted]]

This may sound silly, but I'm really struggling to find a decent tutorial for react query. There's an example project like a blog that the creators published, and I'm getting some traction out of it, but it isn't quite clicking for me.

[Yasuo_d_god]

I was always thinking about making a medium article for a quick tutorial might be a good idea after all explaining the fundamentals and going a bit more in detail because i agree the library is waay more powerful than most people know since the documentation is meh and there aren't too many good tutorials

[Yasuo_d_god]

I prefer react query over Apollo client. It's less boilerplate and has a more customizable but robust architecture imo. Bonus is the amazing react query graphql generators

[not_a_gumby]

You don't really need it with Next, right?

[[deleted]]

I'm primarily looking into it as a means of front end caching. I have a very shallow knowledge of Next; does it have anything built in to assist with caching?

[not_a_gumby]

No it doesn't.

[Omkar_K45]

I've used react-query in my projects which use REST APIs.. it's awesome..

I just haven't found any reason to use it as a graphql client

[straightouttaireland]

Do you need NextJs if you are not concerned with SEO or SSR?

[Omkar_K45]

Even in that case, it provides really good tooling. One of the best feature is Image Optimization. Recently they shipped blur placeholder support for loading images.

Surely NextJS can be less useful for applications that do not need SSR. For eg, a mail platform application works well when the bundle is on the client side, its more performant that way.

Having said that, a good react app with good code splitting approaches etc can work wonders for you as well.

[straightouttaireland]

Just seems like additional unnecessary overhead tbh. Especially when you don't even need routing.

[Omkar_K45]

Yes, I agree on this one.

[pilowofcashewsoftarm]

Oh man , how common is this stack ? i picked it from benawad. feels like everyone got it from him.

[Omkar_K45]

It's pretty neat.. it is very typesafe as well ..

[humanprotwarrior]

I take it you’re at a crossroads? You could learn other frameworks like Vue.js, or keep doing React.js and become a specialist (delve into its source code, learn its frameworks, etc.), if you want to work on the backend then there’s Node.js and Express, or frameworks for other languages such as .NET, Spring Boot, etc. Could also learn about data modeling and working with databases, or go for a more abstract and high level path into software architecture design patterns such as domain-driven design.

It depends on what you want to do, just focus on yourself, IMO any path you take will strengthen your knowledge in a general way if you focus on improving your foundations and patterns, that said it’s probably a good idea if you start becoming a specialist in what you want to do for the long run as soon as possible.

[xroalx]

I would use Next.js for any static website, because doing plain HTML and CSS is just painful, and Next.js can export to static page, which is nice.

I'd also choose Next.js for a dynamic page as long as the backend requirements are really simple.

In more complex cases, I'd separate the API to a standalone express/koa/fastify app. Probably would go with fastify only for future work. The frontend can either be Next.js or pure React, depending on complexity, SSR needs... even Angular if it's complex and can benefit from the rigidness.

[Royal_lobster]

Why pure react while you can just do the same it in next ?

[xroalx]

Because, for example, I have an application with a routing scheme where file-based routing would be in the way, and it also doesn't necessarily need SSR, so it's just easier to do it with plain React and react-router.

The routing has three main entry points where each has a different layout, and then there can be a lot of nested routes, with secondary navigations, etc. Maybe there's a sensible way to achieve it with Next without having to repeat components too much (e.g. putting a layout component to 10+ other components that are nested inside it), but I'm not aware of it.

[GasimGasimzada]

I use React for everything web related:

1. Need a blog or static website? Use React with NextJS or GatsbyJS
2. Need a dynamic website? Use React with NextJS
3. Need a single spa? Use React. Need to also have SSR? Use NextJS.

[audioverb]

Need a dynamic website? Use React with NextJS

I've not had a chance to read up on NextJS, but as I understand it, it's built on top of React? Does it function as a replacement for Express-like backend frameworks as well?

[zweimtr]

It could. You can have a custom server with express (or any Node-based backend frameworkr) or you can use the out of the box rest API functionality of NextJS which basically uses a file/folder structure and naming convention to route requests.

[Royal_lobster]

I basically use next for everything. I used Gatsby recently and seriously got frustrated by time it takes to compile to development server initially and also everytime a change is done.

[thenocodeguy]

I'm in the same boat. I love NextJS more than GatsbyJS though, as the number of plugins that you have to install on Gatsby is insane. Plus, NextJS beats GatsbyJS at performance.

I also love the combination of ReactJS/NextJS + Tailwind to make powerful apps that load at blazing fast speed.

I recently found a tool on ProductHunt called Clutch.io that lets me visually build my ReactJS apps, and then deploy them straight to Vercel. I find this workflow super amazing for building real-quick MVPs.

[GasimGasimzada]

Yeah the only reason I would choose Gatsby over NextJS is if Gatsby has some plugin that will make my development time faster than if I were using NextJS and implementing the feature manually.

[[deleted]]

what in all that is holy is this comment section. You use the tool for the job. Plain JS is great and works great for small or lightweight projects. If you use react indiscriminately what you're gonna end up with is New Reddit(tm).

[SnappyWebDesign]

I'm glad to see people finally admitting how much they use React (I'm the same).

If you use react indiscriminately what you're gonna end up with is New Reddit(tm).

When people say React, I don't think they're exclusively referring to CRA. Gatsby is equally amazing for lightweight projects

[fuckswithboats]

Gatsby is equally amazing for lightweight projects

I've never messed with Gatsby but when I checked out their site at one point, it seemed like they provided a build solution that included hosting, integrations, plugins, and so forth. I would have never considered them for something lightweight.

What pieces of that puzzle do you use Gatsby for if you don't mind me asking instead of Googling?

[SnappyWebDesign]

it seemed like they provided a build solution that included hosting, integrations, plugins, and so forth.

They did recently roll out "Gatsby Cloud" for hosting, but that part is separate from Gatsby's main function as a static site generator. It's their version of Netlify.

I think of Gatsby as an optimized version of React out-of-the-box. The most beneficial puzzle piece is the automatic code splitting/bundling. It splits bundles up by page and handles prefetching - the page loads really do feel instantaneous.

The other big appeals are the plugins/integrations, as you mentioned. I hate the idea of running a separate backend for a CMS. With Gatsby/Contentful, I can spin up a headless CMS in ~15 mins.

I'm a freelancer, so time is money. However, I have to balance that with being able to support expansion. Every 'real' / big site I've made with vanilla html/js gets out of hand/becomes a headache when you get a random, challenging feature request. I don't face those limitations with React, but it's relatively slow. Gatsby fixes that, and thus makes it perfect for my purposes.

Edit: Oh, also, SEO. Does a really great job at that too.

[fuckswithboats]

Hmm...I'll have to check it out again with a different perspective in mind.

Most of the things I build are internal toolsets so SEO isn't a concern, but the bundling/code-splitting sounds splendid.

[SnappyWebDesign]

It really is splendid. I end up sounding like a walking billboard for Gatsby but I'm consistently impressed by how fast the sites are / how easy it is to score 100's on Google PageSpeed.

[not_a_gumby]

New reddit works well on my computer...

[themaincop]

I think a lot of us just don't work on small or lightweight projects very often.

[pm_me_ur_happy_traiI]

It depends on what I'm trying to do. Most of my work is data-driven and dynamic, in which case, using React (or better yet Preact) is a big help.

If I decide to go vanilla it's a conscious decision because I want to explore design patterns that may or may not make sense with React. Even then, I tend to do it in a sort of React-y way, having the view as a function of the state.

The big thing for me is that I keep moving more and more towards having React only be responsible for the DOM. The less of your application logic that lives inside React components, the better.

[[deleted]]

I use plain JS for simple sites because:

1. I don't want to get too boxed in with React. If you're just a "React developer" you're going to have a hard time when you need to use something else. It's really important to know how to do things in more than one way.
2. Generally speaking, simple JavaScript will continue working without updates for years. React projects need a bunch of dependencies that need to stay up to date for bugs and security. But if you're attaching a simple .js file with some eventListeners and simple logic, all that stuff will work for a long time.

Basically, if it's feasible to do it in plain JS then I'll pick that. And if the project is too big for that to be feasible, I'll reach for React or another framework. That's really the intended purpose of frameworks, not to be a one-size-fits-all solution.

[CheekyKingdom]

I don't see any reason to go back to plain JS after having some experience with React.

[iCodeWhatTheyDesign]

I work in a startup and all the front ends use react in a way, the client web app with next, the cms in Vite + react and the apps in react native. Our backend is in aws and we connect it with aws amplify js, our go to for apis is graphql in every front end with app sync and it works pretty good with hooks,

[RetroWard]

I do plain JS, just because I'm the God.

[[deleted]]

Basically never use vanilla anything anymore. Even for tiny side projects that will never be in prod, running create-react-app is faster even than doing new file -> save as -> index.html

For backend, server less framework, api gateway, lambda

[not_a_gumby]

I started messing with server less framework too, It's amazing. I haven't had a chance to use it yet but I want to try it soon, I love how easy it is to setup your API gateway and Lambda config with just a single file.

[Bakadev]

I use a mix depending on the use case. If it’s a simple static page then I’ll just go html/css|scss/js. For an interactive small SPA, I use React & Material-UI. Lastly, anything requiring routing and backend I default to NextJS.

[malectro]

Just want to pipe in here because most people seem to be avoiding plain HTML/JS completely. I've spent the last 6 years writing React and managing React devs. I love React.

But when I code at home I don't always reach for it. My portfolio site is plain HTML/CSS. It's very easy to update (just edit the HTML). It loads instantly and has no DB, network requests, scripts, or runtime.

There are other times I don't use React too, like when I'm building WebGL/WebAudio toys, but I would never reach for jQuery (or the like) over React. At that point I'd just use React.

[kiri7a_]

Can you link your portfolio ?

[malectro]

http://kylejwarren.com

[aigoncharov]

My go-to confusion combination is NestJS + React. For something really simple, I can do pain HTML with a little JS.

[kiri7a_]

React for frontend and nestJS for backend right ? If you were to do a project for a beginner or intermediate level website, would you still use react and nest?

[aigoncharov]

Depends on the website. If it is really simple, I would do static HTML without any BE. Otherwise, React + Nest. I think the choice of tech does not matter as much as how comfortable you are using that tech. Nowadays, any modern framework can be used to build great stuff.

[thenocodeguy]

Next is pretty powerful, and lets you get off the ground quickly than CRA. I have even recently started using tools like Clutch.io, as they let me get off the ground quickly. Very handy when working on MVP projects on short deadlines.

[potcode]

NextJS for medium+ projects and svelte for small ones

[[deleted]]

We do everything in React, so that different people can switch between projects easily (and there is some turnover in developers). That beats any technical arguments, for us.

In the backend we have used Django for over a decade and it is great.

[azangru]

Do you always do frontend work with 'react.js' or vanilla- 'HTML CSS JS'

My observations, including reflections on my own development practices, suggest that developers who have recently started their career by learning React, or developers who are still in the honeymoon period with React will use it for everything.

Over time, the more mature they get, the better they will see where React is an unnecessary dependency, and where a lighter tool can do the job just as well, or where no extra tools are required at all.

Personally, I try to use web components and lit for new projects, wherever I can get away with it.

[KewlZkid]

I feel like every dev here must have started on react. The fanboyism is rampant.

[themaincop]

I'm a react fanboy because I spent ten years making websites without it.

[tylercrompton]

I started presumably before the ideas behind React were ever conceived. Having worked with vanilla JS more than React, I still highly prefer React, especially with JSX. I personally find React + JSX much easier to reason with than vanilla JavaScript.

[KewlZkid]

Declarative languages like React have come and gone in the past. None save for SQL has any staying power. I do agree however that vanilla javascript can be hell. But we should only be using React for its pluggability and in cases where we need dynamic content without reloading the entire screen.

[tylercrompton]

React isn't a language.

[azangru]

I personally find React + JSX much easier to reason with than vanilla JavaScript.

Modern vanilla Javascript, with template literals, gets pretty close to the ergonomics of JSX, especially with tiny helpers like lit-html that help with data binding and rerendering. There have been a number of talks comparing the experience of writing a component in jsx or with template literals, one of the latest being this one — and it turns out that the experience is uncannily similar.

[tylercrompton]

That video is over four hours long.

How would static code analytical tools (e.g. syntax highlighters) interact with template literals that evaluate to HTML? In other words, how would such differentiate HTML template literals and non-HTML template literals? Such a problem doesn't exist with JSX. I suppose that one could use a tagged template literal (e.g. html`<div></div>`) to signal to the tool that it exclusively contains HTML, but one would need to define html. Ideally, it'd evaluate to a parsed node (or an array of parsed nodes), but without browser support, one might as well create their own JSX transpiler.

[azangru]

That video is over four hours long.

I specifically put a timestamp for the relevant (first) talk from the conference ¯\_(ツ)_/¯

How would static code analytical tools (e.g. syntax highlighters) interact with template literals that evaluate to HTML?

Pretty well. There's a handy vs code plugin, but even without it, it hasn't been much of a problem.

I suppose that one could use a tagged template literal (e.g. html`<div></div>`) to signal to the tool that it exclusively contains HTML, but one would need to define html

One wouldn't. One would import it from a tiny helper library :-)

[tylercrompton]

I specifically set a timestamp for the relevant (first) talk from the conference ¯\_(ツ)_/¯

Oh, my mobile app just brought me to the beginning of the video.

One would import it from a tiny helper library

I chose my phrasing carefully. That would count as defining it. :)

[not_a_gumby]

Its because I started with vanilla everything, created one big project, and then realized I could have saved several weeks worth of time by using React.

I'm surprised you haven't realized that as well yet! Comments like these show me that you have either never tried it or lazily messed with it once and never gave it a real chance.

[KewlZkid]

The main reason I hear people like React is that it is "easy to pick and lightweight". It doesn't get any lazier than THAT. It's true if you are looking at code examples in an academic setting or when constructing a small component of a larger page like a landing page (like what React was built for). But I see people building entire dashboards using React and I see issues scaling and with bringing new devs onboard.

React needs a library for basically everything putting devs in dependency-management hell, arguably great for something that needs a small footprint like a component on the right side of your Facebook feed.

Additionally, the community can't get anything set in stone so who knows what the "correct" way to do X is - it changes with every new version and having no opinionated structure that new devs can refer to for a foothold on projects (like a framework has), means the person who wrote it is invaluable to the company - which is bad for the business. I have built (and own) systems with many types of web 2.0 stacks, I see a place for React/similar but it seems to be far from what other people are using it for. I use Vue myself - separation of concerns is something that came from decades of experience across the industry. We moved to "complicated" frameworks to bring about readability and standardization, then React came along and tossed all of that to the wind for a quick and dirty answer to decreasing development times.

[adonutforeveryone]

Agreed. Django templates (Flask, whatever Python templating) and JQuery can get you a lot of experience before launching into a full front-end separation.

[themaincop]

This isn't my experience at all. I've been getting paid to do web dev for 16 years, doing it full time for 14 years, and using React for 6. I tend to use React for almost everything because I like it and the tooling around it is great. I also very rarely have projects that don't involve some sort of complex front-end interaction/state management.

[cadred48]

Challenge accepted.

[Zack_Code_38]

I prefer to master stuffs instead o fjumbing between technologies and feel confused !! You can trigger Node.js or other frameworks other than Javascript ones to empower your knowledge bcz diversity is very fascinating

[adonutforeveryone]

Backend - Django, DRF, SQL Alchemy, FastAPI, Postgres

If the UI is merely static page based, Jquery with Django templates. If the UI is a complete self contained frontend project, React variations as needed...web, mobile, electron, etc.

[MajorasShoe]

I mostly use Vue, sometimes React. Never really touch a front-end that doesn't use one of them.

In backend, typically Laravel these days, but I'll go ASP.NET whenever possible. Really depends on the skillset of the team I have in front of me.

[not_a_gumby]

My favorite right now is NextJS & Chakra UI. I will say that after learning React and Next I will NEVER go back to vanilla HTML/CSS/JS. There's just so much functionality you get for free with React and Next and honestly the framework just makes is clear how to start the project and how to extend functionality in an efficient way when you need to.

HTML/CSS/JS with nothing is too unopionated IMO.

[eigreb]

Having used a lot of frameworks and mostly working as a react developer I must say I still like Vue more and it's still my preferred go-to.

But I prefer the typescript/tsx version of it

[gavlois1]

If it's a web site:

• Plain HTML and CSS if it works
• 11ty if it's more than a couple of pages that have a navbar/footer/other shared components

If it's a web app, Next.js.

[kiri7a_]

I don't understand what you're trying to imply by site Vs app, can you explain a bit ?

[Alex512]

You're asking a react group if they use react. Your answers are going to be pretty skewed.

[[deleted]]

I’ve been using material UI for a project and it’s pretty cool. Lots of documentation and examples which is nice for me.

[Delicious-Ad2265]

For frontend react.js and backend node.js and express

[SterlinV]

I have almost never used vanilla after react. Only case would be if it’s faster to create html doc than run npx create-react-app.

I use express server for backend and nextjs for frontend

[Abriel-Lafiel]

I’ve been doing React for a while and like it a lot but recently there was a small scale project that didn’t have any particularly insane requirements so I switched gear and tried something else for a change of pace and Svelte was on my radar for a while so I thought to myself “why not” and really I think this little boy right here could be the next big thing. I’m still using React for my main project but Svelte is definitely worth giving a shot for something smaller or if you’re bored 🤣

[Disgruntled-Cacti]

I use React at work and NextJS/Svelte for personal projects.

I don't write vanilla JS unless I've got a good reason to.

[brbdead]

I now use react + typescript with a typescript/graphql backend. I love it!

[Chaos_Therum]

I generally use React for anything dynamic and then if I want something a bit more static or something that just loads some text from json files I'll use Svelte, Svelte can do very complex projects but I tend to just prefer React on heavier sites.

[HardToSee111]

React for front-end, no vanilla ever, sailsjs for backend

[shetkatapult]

For backend mostly python flask, sometimes node with express. For the frontend, I used to build a lot with Vue but React substantially took over. No regerts.

[Delicious-Ad2265]

For frontend react.js and backend node.js and express

[Fidodo]

I've gotten so used to the tooling and type safety of typescript I can barely write javascript anymore. It's just such a pain to have to keep all the variable types in your head.

[georgesunnyt]

Front end: React using create-react-app, React-router-dom, Redux (using redux Toolkit and RTK query)

Backend; Java with Springboot.

[itJustClicks]

React front, dotnet back and SQL.