How to start a React Project in 2023(robinwieruch.de)
robinwieruch.de
How to start a React Project in 2023
https://www.robinwieruch.de/react-starter/
288 comments
Unpopular opinion: like most frameworks, things are moving far too fast to be beneficial. I've been in the development community since the mid-late 80s, and I've been a web developer since the early 2000s, yet I still cannot keep up with the latest and greatest from the technologies I work with, which change both one job to the next, as well as one project to the next in many cases.
Angular lost me going from 1-2, for example. Not because Angular 2 was bad, but because they decided they needed to do a fresh start. Vue2 -> Vue3 is almost the same story, though I stuck with that one. Rails? Oh boy...PHP? That is a damn nightmare. Tell me without looking at the docs what the best practices should be for even the most basic stuff.
If I have to rewrite large portions of my code for a new revision, even a major one, you are most certainly doing it wrong. If you want to rewrite the project, at least care to add a compatibility layer (which some projects have done, but most have not).
Angular lost me going from 1-2, for example. Not because Angular 2 was bad, but because they decided they needed to do a fresh start. Vue2 -> Vue3 is almost the same story, though I stuck with that one. Rails? Oh boy...PHP? That is a damn nightmare. Tell me without looking at the docs what the best practices should be for even the most basic stuff.
If I have to rewrite large portions of my code for a new revision, even a major one, you are most certainly doing it wrong. If you want to rewrite the project, at least care to add a compatibility layer (which some projects have done, but most have not).
The really frustrating part to me, is that every year the frontend claims they have finally slowed down and that things are stable.
I just did the "create-next-app" and, I can't claim that all of that is not eventually needed in some form or the other; however, it is mind blowing that I think I know how to hello world a video game with less crap here.
That point is crazy to me. Yes, if you are making a multi platform game, you will need a ton of boilerplate. Will far outstrip the boilerplate that this react thing gave me. Same for if you have a large team building a web based application.
However, for dipping your toes in to the frontend part of a web page, it is boggling to me that they also push so much on you that are not directly front end concerns. Worse, there is a ton here to help with "fast" web pages. Problem is, most of the slow pages out there are slow because the teams just can't keep up with all of these shifts in how you are supposed to do things. Every page that is actually fast, simply stayed with how to do things years ago.
I just did the "create-next-app" and, I can't claim that all of that is not eventually needed in some form or the other; however, it is mind blowing that I think I know how to hello world a video game with less crap here.
That point is crazy to me. Yes, if you are making a multi platform game, you will need a ton of boilerplate. Will far outstrip the boilerplate that this react thing gave me. Same for if you have a large team building a web based application.
However, for dipping your toes in to the frontend part of a web page, it is boggling to me that they also push so much on you that are not directly front end concerns. Worse, there is a ton here to help with "fast" web pages. Problem is, most of the slow pages out there are slow because the teams just can't keep up with all of these shifts in how you are supposed to do things. Every page that is actually fast, simply stayed with how to do things years ago.
>Problem is, most of the slow pages out there are slow because the teams just can't keep up with all of these shifts
Not really. Most pages are slow not because they're using outdated techniques, or they're still serving everything from a large Windows Server running an ancient version of .NET. Those old react pages aren't slow either because they "didn't keep up", they still run fine.
Pages are slow because of the obscene amounts of tracking and "user conversion" techniques. Banners, notices, trackers to make note of everything you do on the page, trackers to make note of errors, third party trackers, ads everywhere because a simple static one isn't good enough, list goes on.
Guess what those old pages that "stayed fast" don't have? You guessed it, all those BS trackers, they weren't readily available back then.
Not really. Most pages are slow not because they're using outdated techniques, or they're still serving everything from a large Windows Server running an ancient version of .NET. Those old react pages aren't slow either because they "didn't keep up", they still run fine.
Pages are slow because of the obscene amounts of tracking and "user conversion" techniques. Banners, notices, trackers to make note of everything you do on the page, trackers to make note of errors, third party trackers, ads everywhere because a simple static one isn't good enough, list goes on.
Guess what those old pages that "stayed fast" don't have? You guessed it, all those BS trackers, they weren't readily available back then.
I didn't mean that old react pages are slow. I meant sites that started on old react and kept trying to keep up with all of the newest best practices throughout the years are slow. Typically because they do too much on the webapp and don't treat it as a gui only. The last web app I looked at in the old job was literally as much code as the entire backing service for it. I don't know how to justify that.
And yeah, for public sites, tracking almost certainly dominates how slow things are. I was thinking of internal tooling sites. I remember how fast many of the tools were when I started at the last job. I also remember how slow all of them were getting as I was leaving said job. It is more than a touch insane.
And yeah, for public sites, tracking almost certainly dominates how slow things are. I was thinking of internal tooling sites. I remember how fast many of the tools were when I started at the last job. I also remember how slow all of them were getting as I was leaving said job. It is more than a touch insane.
I can't say I've come across many internal tooling where the experience is anywhere near as bad as public sites. I find that even the cheap hardware offerings from businesses tend to handle bloated internal tooling pages fine, even if your first load might take a good minute. Ignoring tooling specifically crafted for IE6 and hasn't been touched. May that rot in hell.
There was this really horrific one I did experience, come to find out the entire company is relying on this angular app that connects to an ancient mac mini that IT is responsible for but mostly forgot about. Wasn't a large company, but they weren't stalling in growth!
There was this really horrific one I did experience, come to find out the entire company is relying on this angular app that connects to an ancient mac mini that IT is responsible for but mostly forgot about. Wasn't a large company, but they weren't stalling in growth!
Certainly many sites with tons of tracking are worse than most internal sites. You will not get a disagreement from me on that.
I can't really cite examples, as I'm not at the old job. But silly things like our "news" homepage was getting so that it lazy loaded all of the news. HR things would load in parts, too. And issue tracking seemed to constantly be a mess.
The tool my team controlled had bloated to excessive points. Some of that was almost certainly my fault. I had designed a somewhat granular backend. That said, I remember things were certainly faster before we had a ton of redux based code to do things.
I can't really cite examples, as I'm not at the old job. But silly things like our "news" homepage was getting so that it lazy loaded all of the news. HR things would load in parts, too. And issue tracking seemed to constantly be a mess.
The tool my team controlled had bloated to excessive points. Some of that was almost certainly my fault. I had designed a somewhat granular backend. That said, I remember things were certainly faster before we had a ton of redux based code to do things.
The backend doesn't have to do things like respond to user events, persist state, do validation while typing, handle modal dialogs, etc.
Sorta? The backend specifically exists to be where state is persisted. And the validation of the data has to happen at the backend, even if you also repeat it at the front end.
You are correct that there can be more interactions on the frontend, but frontends were both faster and easier to deal with when they did not do all of this. For many internal tools, bouncing back the validation from the backend is also easier to understand than the validation that the website is providing.
I suspect it is a bit of a curve. Zero interaction on the front is not pleasant. All of the state replicated on the front is also not useful and likely to be more problematic.
You are correct that there can be more interactions on the frontend, but frontends were both faster and easier to deal with when they did not do all of this. For many internal tools, bouncing back the validation from the backend is also easier to understand than the validation that the website is providing.
I suspect it is a bit of a curve. Zero interaction on the front is not pleasant. All of the state replicated on the front is also not useful and likely to be more problematic.
Then go back and use ASP.Net 2.0 and submit a few mb of view state for every user action. Or Blazor server rendering.
If you are pushing megabytes of state for every user action, you've made plenty of other mistakes along the way
And I know it is more than a straw man. There really were bad sites like that. We have swung to another side of bad code, though.
And I know it is more than a straw man. There really were bad sites like that. We have swung to another side of bad code, though.
That's how server-side interaction was in the early 00's with ASP.Net WebForms. This type of interaction is one of the things being proposed as opposed to client-side. And yeah, it definitely was a (very painful) thing. Server-driven Blazor has very similar (poor) behavior today. I know there's other frameworks that do similar things. Which really sucks if you have any latency or bandwidth issues.
Not that I like the idea of several MBs of JS being sent over the wire either... I know that is also a thing, not to mention poor state mgt, which is also a regular occurrence (most angular apps have many state bugs).
Personally, I'm not too bothered by client rendered/driven apps... They can often be split accordingly, and it's reasonable to stay under 500kb JS payload for a moderately sized web application. Not that everyone has as much awareness. I think of the browser as a thick-ish client toolkit as much as it is a rendering platform. That doesn't mean SPA is the right way for everything. I wouldn't do it for a mostly text content site (news, blog, etc). And most of my work is web based applications, not text driven content sites.
Not that I like the idea of several MBs of JS being sent over the wire either... I know that is also a thing, not to mention poor state mgt, which is also a regular occurrence (most angular apps have many state bugs).
Personally, I'm not too bothered by client rendered/driven apps... They can often be split accordingly, and it's reasonable to stay under 500kb JS payload for a moderately sized web application. Not that everyone has as much awareness. I think of the browser as a thick-ish client toolkit as much as it is a rendering platform. That doesn't mean SPA is the right way for everything. I wouldn't do it for a mostly text content site (news, blog, etc). And most of my work is web based applications, not text driven content sites.
Explain Jira then.
You're not wrong, you have to be pretty invested to keep up to date with most technologies.
There's even a new crop of frameworks coming up now, like Astro, Qwik, Solid, etc. Plus a paradigm shift towards MPA and abstractions like server components.
There's even a new crop of frameworks coming up now, like Astro, Qwik, Solid, etc. Plus a paradigm shift towards MPA and abstractions like server components.
You only need to care about those if you need to find a new job though, at least until they make a dent.
I agree 100%. Framework devs forget that the rest of us have real jobs to do and can't spend weeks updating to the latest version of the framework every 6 months.
The job of framework devs (at least the ones working for companies on those frameworks) is to make it seembusy and evolving, even if that’s not needed; if a framework is ‘stable’ and ‘done’, contributions drop fast and the project dies. People, for some weird reason, don’t see it as an advantage where a project on GitHub has only security and dependency updates but is done feature wise.
Those of still using Django are quietly enjoying ourselves doing things in fundamentally the same way for the past decade.
.NET is trying to move fast and break things, however most devs are using it like they had in the past 15 years (with some new best practices for c# and frameworks); it's lovely working on that. Updating libraries is painless, even for projects > 5 years old. Try that with npm... After 5 weeks.
There's an effect (sic) from having open source and ubiquitous internet that makes everybody react (sicsic) to everybody whenever something is seen as the new way.
Before that you had 2-3 years of stable blindfolds before knowing what the other teams cooked secretly.
Before that you had 2-3 years of stable blindfolds before knowing what the other teams cooked secretly.
The Angular API has been pretty stable for the past 6-7 years since v2 (well, since v4 if you count the Router changes), and the upgrade process between major versions is pretty smooth. Especially since the Ivy release, they've matured a lot... That's one of the reasons I still prefer it over React, especially in enterprise settings. (Although with their latest versions they are again trying to keep up with the cool kids by introducing standalone components and signals... not sure what to think about that yet)
I completely agree with this..
I have been trying to get into front end JS development and it feels like every guide is broken within 6 months... When I actually succeed at one part, I then realize that to add testing, or bundling, I need to follow this other guide, which isn't stable anymore, and then breaks the whole project. I have tried 4 or 5 times now trying different frameworks and "quick start" features or following recent YouTube videos, giving it 3-5 hours each time, and I can't get a working typescript based UI + test + bundler to work.
Edit: I should say, I'm open to any _working_ guides that go from start to bundle that you all know about...
I have been trying to get into front end JS development and it feels like every guide is broken within 6 months... When I actually succeed at one part, I then realize that to add testing, or bundling, I need to follow this other guide, which isn't stable anymore, and then breaks the whole project. I have tried 4 or 5 times now trying different frameworks and "quick start" features or following recent YouTube videos, giving it 3-5 hours each time, and I can't get a working typescript based UI + test + bundler to work.
Edit: I should say, I'm open to any _working_ guides that go from start to bundle that you all know about...
This definitely doesn't just apply to frontend. A lot of the JS ecosystem can be like this :(
Too many projects. Not enough focus. Everyone creates their "alternative".
Too many projects. Not enough focus. Everyone creates their "alternative".
This is the easiest way I know to get a React app up and running. https://ymse.io/blog/how-to-create-a-minimal-react-app/
> As someone who just decided to learn React (and modern javascript, after 1.5 decades or so of not programming in javascript at all
Sorry you're experiencing this. It's not "just React" though, it's pretty much all Javascript (or Typescript) now. Especially front-end, but I swear, JS/TS on the front or back is like trying to learn to drive a car in heavy traffic while also repairing the brake lines which are malfunctioning
Sorry you're experiencing this. It's not "just React" though, it's pretty much all Javascript (or Typescript) now. Especially front-end, but I swear, JS/TS on the front or back is like trying to learn to drive a car in heavy traffic while also repairing the brake lines which are malfunctioning
Saying it's not "just React" is normalising the problem, which I think really doesn't benefit React trying to set itself as the de-facto standard for front-end code.
De facto what...? Maybe if you only read Twitter. There's tremendous amount of work in other libraries too.
I would also argue that poor web standards support hinders the future of React, especially for web components.
I would also argue that poor web standards support hinders the future of React, especially for web components.
[deleted]
It is also not just JavaScript, but also with current AI technologies, which arguably, change even faster than JavaScript. You see, fast changing technology does not imply the underlying tech is bad, but rather there are unexplored new ideas and there are enough interested people ready to dive right in. Yes, it is exhausting to follow. Yes, it is frustrating when the floor shifts underneath you. However, dismissing a tech just because it is fast changing is not a good altitude.
Going to train an AI to write JavaScript frameworks.
I love your analogy. That's definitely how it's felt for me.
For context I'm a specialized back-end (but with a lot of experience in desktop GUI/game engine stuff) dev and I also wanted to learn React recently to round off my skills and be more marketable in the job market.
Like yourself I also prefer written docs, but trying to find such structured info was an exercise in futility. At the end I used my existing Pluralsight subscription and went through the React 18 path they have which is around 18 hours or so in total. The courses covered different topics around React like components, hooks, testing etc. Good thing is the courses also have full transcripts! I followed them along and created some small apps myself in the process. Now I'm pretty much sure I can handle working with React in a normal job setting. You might want to consider that option. To be honest FE seems like programming on easy mode compared to some of the things I'm used to working on in my day to day. If you are an experienced programmer you should have no problem getting caught up to speed on that relatively quickly.
Like yourself I also prefer written docs, but trying to find such structured info was an exercise in futility. At the end I used my existing Pluralsight subscription and went through the React 18 path they have which is around 18 hours or so in total. The courses covered different topics around React like components, hooks, testing etc. Good thing is the courses also have full transcripts! I followed them along and created some small apps myself in the process. Now I'm pretty much sure I can handle working with React in a normal job setting. You might want to consider that option. To be honest FE seems like programming on easy mode compared to some of the things I'm used to working on in my day to day. If you are an experienced programmer you should have no problem getting caught up to speed on that relatively quickly.
Similar experience, frontend work is more relaxed and forgiving. You can more or less trial and error until it works and looks good. It's all very visual. On the other hand, making a mistake in your backend auth, order handling/accounting or even mass email efforts can have some really nasty results.
You’ve basically said that you did a React course, built some toy apps (which almost certainly had sterile, malleable requirements) and now feel like the whole “front end” thing is easy mode.
Chances are you aren’t materially smarter than the hoards of smart people doing this day-to-day and find it ‘not-easy-mode’, and that you’re instead in deep Dunning-Kruger territory.
You watched the VHS about foundation repair but you’re yet to get thrown off-course when you find out that you don’t know what carbon-fibre stucco lath is.
Chances are you aren’t materially smarter than the hoards of smart people doing this day-to-day and find it ‘not-easy-mode’, and that you’re instead in deep Dunning-Kruger territory.
You watched the VHS about foundation repair but you’re yet to get thrown off-course when you find out that you don’t know what carbon-fibre stucco lath is.
A more charitable interpretation is that _hao has learned that React has simple, easy-to-remember patterns, allowing the developer to focus on domain-specific problems (which can be arbitrarily deep and complex, just like backend code.)
Not to be combative, but I didn't say anything about being smarter or master at web FE and React. My comment was supposed to be seen as more like how @hathawsh read it. It's easy to do work with React if you have a good programming background and it doesn't need that big of an investment of time to go into it.
I'm sure React has it's own intricacies just like every other tool and it takes time to appreciate those. I can see how managing your reconciliation state can become a big hurdle in larger projects for example. I've done WPF, MFC and a lot of other things on native desktop programming and the ideas in React are not that different. Those ideas in the browser context are actually easier to deal with than on a native platform hence my "easy mode" thought.
I'm sure React has it's own intricacies just like every other tool and it takes time to appreciate those. I can see how managing your reconciliation state can become a big hurdle in larger projects for example. I've done WPF, MFC and a lot of other things on native desktop programming and the ideas in React are not that different. Those ideas in the browser context are actually easier to deal with than on a native platform hence my "easy mode" thought.
Agreed... I've done a bit of simulation work, and the unidirectional flow for react (and redux) was pretty natural to me and similar to other approaches I'd used for ui composition and state management. A few patterns that can be more difficult (slightly/arguably) to get started with, but easy to repeat.
I've been a fan for several years now, almost a decade and I adopted the hooks relatively early on as well. It feels right, even if something under the covers are complex, you don't have to think about a lot of that when you aren't looking at it.
I've been a fan for several years now, almost a decade and I adopted the hooks relatively early on as well. It feels right, even if something under the covers are complex, you don't have to think about a lot of that when you aren't looking at it.
I write React but don't look at the docs much so I am not familiar with all the changes there. The basic concepts of React haven't changed much over its history. Hooks are newer than class components, etc but class components still work. Hooks have been out since 2019 so they aren't exactly new (and they were in the old documentation). React itself has been quite backwards compatible.
The Javascript ecosystem tends to have lots of flux with new libraries and ways of doing things coming out all the time. I have found React to be one of the most stable libraries around. I can update versions of React and my code continues to work as before. Libraries that I depend on tend to have more issues with this and version updates can mean changes in the API for the library or a newer version of React not being supported.
My suggestion for someone learning React would be to start with the simplest way of getting started and learn React before learning concepts brought in with frameworks, etc. If I were to start learning React today, I would start with Vite.
The Javascript ecosystem tends to have lots of flux with new libraries and ways of doing things coming out all the time. I have found React to be one of the most stable libraries around. I can update versions of React and my code continues to work as before. Libraries that I depend on tend to have more issues with this and version updates can mean changes in the API for the library or a newer version of React not being supported.
My suggestion for someone learning React would be to start with the simplest way of getting started and learn React before learning concepts brought in with frameworks, etc. If I were to start learning React today, I would start with Vite.
In the end it's all state -> view -> interactions -> state -> view -> interactions.
Svelte does it most simply though. I've been doing React for years now, but it still feels ridiculous to me compared to Svelte and others.
I honestly think people who like React have Stockholm syndrome. And everyone is taken hostage since it's the most popular one. UseEffect is ridiculous, hooks in general are ridiculous, mapping over array to create elements is ridiculous, having no tools out of the box for JSX to do simpler if else, for loops, etc. All these bizarre concepts just to hack around JS to make all of it work. And in the end it's all very difficult to read and reason. And all this bizarre boilerplate is just tech debt. It does nothing to describe what is actually going on in that component.
Svelte does it most simply though. I've been doing React for years now, but it still feels ridiculous to me compared to Svelte and others.
I honestly think people who like React have Stockholm syndrome. And everyone is taken hostage since it's the most popular one. UseEffect is ridiculous, hooks in general are ridiculous, mapping over array to create elements is ridiculous, having no tools out of the box for JSX to do simpler if else, for loops, etc. All these bizarre concepts just to hack around JS to make all of it work. And in the end it's all very difficult to read and reason. And all this bizarre boilerplate is just tech debt. It does nothing to describe what is actually going on in that component.
React is a lot better than what came before it (Angular 1, Backbone, jQuery), etc. And I think it's longevity is in large part because it hit the "good enough" where the frameworks ceases to be a major barrier to productivity.
The newer frameworks (Svelte, SolidJS, etc) definitely seem to improve on React. But it will take some time for the wider ecosystem of libraries to catch up (and ideally for one of the newer frameworks to establish themselves as the next-gen "winner)
The newer frameworks (Svelte, SolidJS, etc) definitely seem to improve on React. But it will take some time for the wider ecosystem of libraries to catch up (and ideally for one of the newer frameworks to establish themselves as the next-gen "winner)
Doing frontend in this day and age is like doing agility with your dog. And people who've been doing frontend for a while are so conditioned that they see this as normal. "Why would want to just go to park," they ask "when you could do agility course? It's not hard, the are hurdles, yes, but it's fun and it's not really complicated once you do it twenty times."
Very peculiar analogy but yes I’d just prefer to go to the park with my dog, as you say
> As someone who just decided to learn React (and modern javascript, after 1.5 decades or so of not programming in javascript at all) in the past month or two, I've been extremely frustrated by the documentation (in particular) and the whole state of flux that it's in (in general).
As someone who was in a similar boat (2 decades of .Net essentially, with a lot of HTML/JS but no frameworks), I found jumping into Angular very nice in this regard.
New versions every 6 months but not with "changing things for the sake of change", actual small but incremental improvements. The documentation I've found to be great, and since it is "opinionated" it easy to jump between multiple projects and not feel completely lost.
It seems a lot of flak that Angular gets is because it is "opionated" but I look at this as a major positive.
I've jumped between React projects and have been bewildered at how different they all are.
The whole framework vs. library thing.
As someone who was in a similar boat (2 decades of .Net essentially, with a lot of HTML/JS but no frameworks), I found jumping into Angular very nice in this regard.
New versions every 6 months but not with "changing things for the sake of change", actual small but incremental improvements. The documentation I've found to be great, and since it is "opinionated" it easy to jump between multiple projects and not feel completely lost.
It seems a lot of flak that Angular gets is because it is "opionated" but I look at this as a major positive.
I've jumped between React projects and have been bewildered at how different they all are.
The whole framework vs. library thing.
The problem with Angular (back when I used it, around versions 4-6) was that it had a ton of opinions, and they were half baked. Angular had its own plugin for driving flex layouts, and roughly 90% of the bugs we had were related to one of those plugins.
Another problem I've seen is that the default data binding being taught to new comers is slow. At least slow enough for a team I was on to later have switched to an approach (called OnPush) where you must manually tell the UI when to update with calls to detectChanges() all over the place. The way to avoid that is to fully embrace Reactice Extensions, but that seems to be very hard to grasp for a lot of developers that instead work around the library in all sorts of quirky ways (subscription()'s everywhere, that you must remember to dispose, that calls detectChanges()....).
Edit: Found this old GitHub issue I stumpled upon when looking up why this performance improvement wasn't the default.. I think these comments are interesting:
> Both OnPush and zone coalescing would, however, change the default semantics of building Angular apps. This is outside the scope of the feature.
> We did discuss this a couple of months ago and felt that we shouldn’t since it would complicate things for new user which are not familiar with change detection.
https://github.com/angular/angular-cli/issues/21278
Edit: Found this old GitHub issue I stumpled upon when looking up why this performance improvement wasn't the default.. I think these comments are interesting:
> Both OnPush and zone coalescing would, however, change the default semantics of building Angular apps. This is outside the scope of the feature.
> We did discuss this a couple of months ago and felt that we shouldn’t since it would complicate things for new user which are not familiar with change detection.
https://github.com/angular/angular-cli/issues/21278
You are probably talking about rxjs, possible even ngrx.
I have become to love it.
However, it should be way simpler now with the upcoming Angular version that's supporting signals now.
I have become to love it.
However, it should be way simpler now with the upcoming Angular version that's supporting signals now.
Yes, the rx in rxjs means Reactive Extensions. I think it's perfect for UI dev, but the steep learning curve excludes a lot of developers.
Signals look identical to React hooks.
Signals look identical to React hooks.
Regarding the flex layout thing, they decided to deprecate it.
https://2022.ng-conf.org/a-new-layout-ahead
More recent versions (I'm currently on 15) don't seem to have these issues, as least from my working with them. I started an enterprise product on version 13, the upgrade path to 15 has been smooth and so far, so good.
https://2022.ng-conf.org/a-new-layout-ahead
More recent versions (I'm currently on 15) don't seem to have these issues, as least from my working with them. I started an enterprise product on version 13, the upgrade path to 15 has been smooth and so far, so good.
> is it always such a chaotic changing climate around it?
The old doc was like 10 years old, they just officialized the new one this week.
Create React App was the recommended way to build a React app for like forever but Facebook stopped maintaining it 2 or 3 years ago. The drop-in replacement is Vite.
The old doc was like 10 years old, they just officialized the new one this week.
Create React App was the recommended way to build a React app for like forever but Facebook stopped maintaining it 2 or 3 years ago. The drop-in replacement is Vite.
CRA is deprecated? Glad I switched to Vue a while back, jeeze.
Welcome to the club. Relax, the pain eventually passes. After you leave webdev, never before that.
This is not a problem specific to React, it seems to be a problem with the industry as a whole. I had this problem with Cloudflare, AWS and others. Documentation is old, inaccurate, software is unstable, etc... These companies keep pushing features like startups while breaking everything up and not fixing the old stuff or maintaining it.
And have you checked Web 3.0?
And have you checked Web 3.0?
Try out https://vuejs.org/
It’s simpler to learn. Guides are phenomenal. Creator is a designer and author of Vite.
React is great in that it’s being developed by a great team of diverse engineers. However diversity comes with differing opinions of end user experiences.
In the world of product development and innovation, the role of a designer is often more impactful than that of an engineer, especially when it comes to shaping the overall user experience.
Designers possess the unique ability to understand the end user's needs, desires, and challenges, translating those insights into functional and aesthetically pleasing solutions. Their holistic perspective allows them to balance form and function in a way that elevates the value of the end product.
While engineers excel at the technical aspects of a project, ensuring that the underlying systems function properly and meet performance specifications, designers take a more human-centered approach. They focus on usability, ergonomics, and aesthetics, often serving as a bridge between the technical and the emotional aspects of a product. This ability to understand and empathize with the user is invaluable, as it ensures that the product not only performs well but also resonates with its intended audience on a deeper level.
Collaboration between designers and engineers is crucial, as their combined skills and expertise can lead to groundbreaking innovations. However, it is the designer's intuitive understanding of the user experience that often plays a key role in creating a product that stands out from the competition and truly resonates with consumers. By prioritizing the needs and desires of the end user, designers help to create products that are both functional and emotionally engaging, ultimately enhancing the overall success of a project.
Thus why the more granular and slower approach such as Vue is what I think is software framework done right.
It’s simpler to learn. Guides are phenomenal. Creator is a designer and author of Vite.
React is great in that it’s being developed by a great team of diverse engineers. However diversity comes with differing opinions of end user experiences.
In the world of product development and innovation, the role of a designer is often more impactful than that of an engineer, especially when it comes to shaping the overall user experience.
Designers possess the unique ability to understand the end user's needs, desires, and challenges, translating those insights into functional and aesthetically pleasing solutions. Their holistic perspective allows them to balance form and function in a way that elevates the value of the end product.
While engineers excel at the technical aspects of a project, ensuring that the underlying systems function properly and meet performance specifications, designers take a more human-centered approach. They focus on usability, ergonomics, and aesthetics, often serving as a bridge between the technical and the emotional aspects of a product. This ability to understand and empathize with the user is invaluable, as it ensures that the product not only performs well but also resonates with its intended audience on a deeper level.
Collaboration between designers and engineers is crucial, as their combined skills and expertise can lead to groundbreaking innovations. However, it is the designer's intuitive understanding of the user experience that often plays a key role in creating a product that stands out from the competition and truly resonates with consumers. By prioritizing the needs and desires of the end user, designers help to create products that are both functional and emotionally engaging, ultimately enhancing the overall success of a project.
Thus why the more granular and slower approach such as Vue is what I think is software framework done right.
Actually building in React nowadays is really easy. You just need six hooks, useReducer - for the reactive state, useRef - for the imperative state, useMemo, useCallback - for memoizing state/callbacks, useEffect - for side-effects, create/useContext - for contextualizing states. If you're able to grasp it, you can build any application you want – it only has these hooks on top and returns JSX to execute all of the logic in the most efficient way in terms of rendering.
Basically, you don't need anything else, and the signature for hooks is stable for years. What makes it harder to navigate is the infinite libraries and frameworks to choose from, but the vanilla part is a really pleasing functional JavaScript experience, with some learning curve, but greater returns.
Really understanding those properly and deeply can take a lot of time, though. I've been using it professionally for almost two years at this point and some of those hooks I'm still a bit shaky on (although we don't use them that often, and probably less often than we should). And I just learned a couple more new things in the 'You might not need an effect' article that was posted here the other day (I already do most of those, but not all of them).
And I manage several junior developers and I've seen them struggle to understand all of these, even over many months including pair programming and code review feedback.
That being said, I was able to jump into an existing codebase and be useful in about a week with very little prior knowledge of React (just some dabbling in React Native pre-hooks), so I don't think it's hard to learn enough to start doing useful things with it, especially if you already know Javascript/Typescript.
And I would agree that I've struggled much more with other React libraries than core React itself. It's been a long time since I've had to look anything up for core React hooks, I can write lots of React code (in Typescript) and be relatively confident it will work as intended, barring some dumb mistake I made or a misunderstanding of how the data flows in the existing codebase, as long as it compiles.
And I manage several junior developers and I've seen them struggle to understand all of these, even over many months including pair programming and code review feedback.
That being said, I was able to jump into an existing codebase and be useful in about a week with very little prior knowledge of React (just some dabbling in React Native pre-hooks), so I don't think it's hard to learn enough to start doing useful things with it, especially if you already know Javascript/Typescript.
And I would agree that I've struggled much more with other React libraries than core React itself. It's been a long time since I've had to look anything up for core React hooks, I can write lots of React code (in Typescript) and be relatively confident it will work as intended, barring some dumb mistake I made or a misunderstanding of how the data flows in the existing codebase, as long as it compiles.
Agreed, it employs a lot of good functional concepts and shifts you into another kind of "reactive" thinking, where the render function is a pure representation of its state. This actually allows you to "declare" your state and its mutations in a way that perfectly executes your business logic and presents it in a single pure function, but generally, it's hard to think with pure functions for some reason, and side effects are imminent, as well as some asynchronous black-boxed action takes place. Actually – for many, side-effect becomes a patch for conceptual blanks in knowledge about functional data flow in its pure form, and you can tell who really understands it just by looking at his side-effect usage. In the end, what makes the library so appealing is that you need just 6 basic hook functions aligned together in a proper way to describe any kind of state and functionality user interface needs, and it actually performs top-notch and takes little space.
Flux? Javascript has been "fluxing" for almost 30 years. Unpleasant chaos has to become your friend.
It is really unappealing and driven by "smart" people.
1. The "tutorials" are terrible. 2. The tooling - webpack etc - is terrible. 3. Things change too quickly. 4. There are an absurd number of technical layers trying to make frontend "safe" like backend EG typescript.
I like react as long as I am the only author involved. All the FE devs I've been forced to work with pull in an asinine number of external dependencies, weave painfully elaborate webpack setups, among many other things. I can't stand it.
It is really unappealing and driven by "smart" people.
1. The "tutorials" are terrible. 2. The tooling - webpack etc - is terrible. 3. Things change too quickly. 4. There are an absurd number of technical layers trying to make frontend "safe" like backend EG typescript.
I like react as long as I am the only author involved. All the FE devs I've been forced to work with pull in an asinine number of external dependencies, weave painfully elaborate webpack setups, among many other things. I can't stand it.
I've had a similar time reading the Firebase docs for Swift and SwiftUI!
Just learn javascript, or better, typescript. It's a fine language and you can do a lot of things on its own.
I've have some side projects in typescript, e.g. https://aperocky.com/cellular-automata/, and none of it needed react or any of the common frameworks. Just pure HTML and javascript, turns out it's not that hard.
I've have some side projects in typescript, e.g. https://aperocky.com/cellular-automata/, and none of it needed react or any of the common frameworks. Just pure HTML and javascript, turns out it's not that hard.
I would checkout Vue. It's much more user friendly IMHO.
I think it depends on the developer. I started with Vue and loved it for a year, then decided on a whim to look into React. This was just after hooks were released. I love React – never looked back.
I gave up on React 5 years ago for this very reason (and others)...it sounds like not much has changed, and it's still a constantly changing minefield.
I've had much better mileage with Vue.js - far more opinionated (which I like in a framework).
I've had much better mileage with Vue.js - far more opinionated (which I like in a framework).
That is a world full of marketable-skill-hype. Pity you didn't started with Svelte.
Start with The Tao of Redux
Redux is so painful to refactor, it makes my head explode. I don’t trust any tech that makes refactoring so painful
It might seem chaotic to you, but the docs change has been a long time coming, and isn't a surprise to anybody.
> Is this just a really bad time for React
There are some concepts you may struggle with. That's to be expected.
But the new docs don't represent negative change. The old docs were not representative of how most react is written today. That was really confusing for newcomers. There's nothing "wrong" with doing it the old way, but most jobs that use React are going to require you to work with hooks in some capacity.
> Is this just a really bad time for React
There are some concepts you may struggle with. That's to be expected.
But the new docs don't represent negative change. The old docs were not representative of how most react is written today. That was really confusing for newcomers. There's nothing "wrong" with doing it the old way, but most jobs that use React are going to require you to work with hooks in some capacity.
How deep in the React ecosystem do you have to be to NOT see that the problems OP is describing are not inherent in change, but rather Meta deprioritising public / open-source React?
You wouldn’t see this shit otherwise.
Especially with Meta’s resources, there were MUCH better ways to handle React’s documentation situation. The JS community, but especially React, just happens to set the bar on the floor as far as end user communication goes, compared to other open-source projects, say…Django, with like…two paid staff and a bunch of volunteers.
This isn’t just the cost of progress. It’s laziness.
You wouldn’t see this shit otherwise.
Especially with Meta’s resources, there were MUCH better ways to handle React’s documentation situation. The JS community, but especially React, just happens to set the bar on the floor as far as end user communication goes, compared to other open-source projects, say…Django, with like…two paid staff and a bunch of volunteers.
This isn’t just the cost of progress. It’s laziness.
I recently showed the (old) React Hooks documentation to my 70-year-old mentor, a comp sci PhD who started on punch cards and never stopped. I wish I had taken a reaction video of the flabbergasted look on his face when he was reading the React docs section titled "Classes Confuse People and Machines" (https://legacy.reactjs.org/docs/hooks-intro.html#classes-con...).
Now, I like React, more or less. But some of the discussion around React reminds me of Wimp Lo from Kung Pow ("...we trained him wrong as a joke..."). For instance, the whole immutability for performance thing (I get it, but lol). Or statements like this: "[w]ith Hooks, you can extract stateful logic from a component so it can be tested independently and reused" (thank God someone finally figured out how to reuse stateful logic in software /s).
Now, I like React, more or less. But some of the discussion around React reminds me of Wimp Lo from Kung Pow ("...we trained him wrong as a joke..."). For instance, the whole immutability for performance thing (I get it, but lol). Or statements like this: "[w]ith Hooks, you can extract stateful logic from a component so it can be tested independently and reused" (thank God someone finally figured out how to reuse stateful logic in software /s).
Saying hooks are less confusing than classes and understanding the weirdness of `this` is a pretty bad selling point and easily refuted. Hooks are weird. Really weird. They make all your components that use them impure which makes them harder to reason about. But hooks do compose better than classes. With classes, everything is tied to `this` which means that if you decide to reuse some stateful or effectful(?) logic somewhere, you have to disentangle it from `this` first. So on the whole, I think hooks are a win over classes. But they are weird and confusing.
I had to read the code when hooks came out, because I couldn't believe they'd done the thing that the documentation of hooks' behavior sure made it look like they'd done.
Sure enough, they had. I was left in a state somewhere between dumbfounded and amused. Reading the justifications for what they'd done just made both reactions more intense.
Sure enough, they had. I was left in a state somewhere between dumbfounded and amused. Reading the justifications for what they'd done just made both reactions more intense.
Yeah that's one of the biggest annoyances of the frontend community in general to me. This constant "We have to do X because Y confuses developers" uhhhhh maybe they should expand their knowledge instead of putting bumper rails on everything causing pain for everyone.
Does anybody else think it's extremely damning that a mature framework such as React still has no agreed up on way to start a project? One of React's initial selling points was that it was a library, not a framework! React is unopinionated! Etc. Perhaps some opinion might have been better, in hindsight.
How is `react new` not a thing?
How is `react new` not a thing?
I'm fine with having options, I just find it odd that Vite isn't recommended in the official doc. I mean, they talk about it but it's hidden at the end of a collapsed 500-word "deep dive" section following a list of recommended frameworks. I would personally recommend Vite to anyone learning React, it doesn't add features to React so you can actually just focus on learning React instead of learning at the same time some framework's APIs. I understand the benefits of going with Next.js, but I feel like I would be overwhelmed if I was learning React and had all those extra layers of features and concepts (SSR, SSG, CSR, ISR...) that come with Next.js thrown into my face.
It's like telling someone who wanna learn Python to start with Django.
It's like telling someone who wanna learn Python to start with Django.
It's the same story with Express as a web server framework for Node.
I've always felt that the biggest problem with the Javascript ecosystem is that it's entirely too preoccupied with syntax. Remember CoffeeScript!? Some of the most influential forces in the community can waste entire years bikeshedding some syntactic thing that is mostly a matter of personal aesthetics. And this trickles down to the grunts trying to ship a product.
It's a fundamental drawback to Javascripts other strengths. And that's the reason it's so easy to find Express apps that are hot garbage. It's one of the most enduring myths that If you know Javascript, you can write a Node app.
It only works because software has been such an economically productive force, that having thousands of professionals spending weeks deciding whether semicolons are good or bad, or fighting their webpack configs, or migrating for loops to array methods... whatever... it still makes money at the end of the day.
I've always felt that the biggest problem with the Javascript ecosystem is that it's entirely too preoccupied with syntax. Remember CoffeeScript!? Some of the most influential forces in the community can waste entire years bikeshedding some syntactic thing that is mostly a matter of personal aesthetics. And this trickles down to the grunts trying to ship a product.
It's a fundamental drawback to Javascripts other strengths. And that's the reason it's so easy to find Express apps that are hot garbage. It's one of the most enduring myths that If you know Javascript, you can write a Node app.
It only works because software has been such an economically productive force, that having thousands of professionals spending weeks deciding whether semicolons are good or bad, or fighting their webpack configs, or migrating for loops to array methods... whatever... it still makes money at the end of the day.
Sorry to be obtuse, but it’s not damning at all because it’s a library, not a framework.
It's not a library. I think this would be a valid argument if it was an actual library.
jquery was a library. React is a framework because you're passing in code to React, which it then uses to do things like render components and respond to state changes.
React misleadingly called itself a library to distinguish itself from more batteries-included frameworks like Angular.
jquery was a library. React is a framework because you're passing in code to React, which it then uses to do things like render components and respond to state changes.
React misleadingly called itself a library to distinguish itself from more batteries-included frameworks like Angular.
I’ll admit to using the words framework and library interchangeably when referring to React in my day to day, but what distinguishes React from frameworks to me is the fact it doesn’t tie itself to a particular rendering context, i.e. it is flexible and unopininated and relies on wrappers and rendering libraries to actually function.
Maybe not standard definition but I view a library as something that can be swapped out of a project with low-medium effort.
If I build an app on React, there's not much chance I'm ever going to swap it out for anything else, thus it's a framework.
If I use Twilio's JS library for sending SMS and then decide to swap to a different vendor (or a different library for the Twilio API) that's fairly easy with the right design.
If I build an app on React, there's not much chance I'm ever going to swap it out for anything else, thus it's a framework.
If I use Twilio's JS library for sending SMS and then decide to swap to a different vendor (or a different library for the Twilio API) that's fairly easy with the right design.
> If I build an app on React, there's not much chance I'm ever going to swap it out for anything else, thus it's a framework.
Preact exists though? And literally emulates React's API. It even has a guide for aliasing the Preact module as React with your bundler so your app wouldn't need any code changes. Can a framework do that?
Preact exists though? And literally emulates React's API. It even has a guide for aliasing the Preact module as React with your bundler so your app wouldn't need any code changes. Can a framework do that?
That's the entire downside of a tool being unopinionated. It's up to the community to decide how it wants to use that tool. And for the most part, the answer is turning to Next.js.
When a business decides to pick a tech, they look at following:
1. Longevity
2. Market share
3. Developer supply
4. Third party support. (Ecosystem)
5. Technically mature and advanced
Among those criteria react excels at first four. And is good enough for the fifth.
So, most business will pick react. Depending on the local environment, some may pick angular for those same reason.
All newer, better technologies will be evaluated afterwards and only if react and angular prove to be too troublesome for the business's current needs.
This is why "react new" is not a thing. This sentiment is echoed almost weekly basis. Recent threads were under title "React is holding me hostage"
1. Longevity
2. Market share
3. Developer supply
4. Third party support. (Ecosystem)
5. Technically mature and advanced
Among those criteria react excels at first four. And is good enough for the fifth.
So, most business will pick react. Depending on the local environment, some may pick angular for those same reason.
All newer, better technologies will be evaluated afterwards and only if react and angular prove to be too troublesome for the business's current needs.
This is why "react new" is not a thing. This sentiment is echoed almost weekly basis. Recent threads were under title "React is holding me hostage"
I don't understand how any of that is related to why "react new" is not a thing.
Then let me iterate it more clearly. The reason "react new" is not a thing because from business perspective "react" is superior to "react new".
Hence newer projects are likely to pick react instead of solid/svelte
Hence newer projects are likely to pick react instead of solid/svelte
For posterity’s sake, they weren’t suggesting a new React, they were describing a missing official way to create a new app at the command line like “react new my-todo-app”
They had/have create-react-app ... though I don't want/agree with a lot of the config.
It's a library, less of a framework. For frameworks, you can bring together your own, or use next.js etc. For that matter, getting started with react/jsx and vite.js or parcel are easy enough.
It's a library, less of a framework. For frameworks, you can bring together your own, or use next.js etc. For that matter, getting started with react/jsx and vite.js or parcel are easy enough.
To start a new react project, you just need to declare a root react-dom node and call its render method to get it to the regular DOM. It is so trivial any other way becomes more complicated, and it is up to you to have an opinion on how to build and serve it, or to stick with some popular bundle of opinions aka "framework". If you know how to cook - you can come up with an original and delicious dish, but anytime you can resort to frozen pizza.
It appears the layoffs affected the React team, and the once-standard way for starting a new framework-less project (CRA) isn't supported anymore.
The ecosystem is confusing, but I'd argue it's still quite straightforward to start a new project: either use one of Vite's basic React templates or Next if you want an opinionated framework.
The ecosystem is confusing, but I'd argue it's still quite straightforward to start a new project: either use one of Vite's basic React templates or Next if you want an opinionated framework.
I don't think it's fair to blame CRA's state of disrepair on the layoffs. CRA has been barely maintained for years now and what releases it did receive were mostly to update its dependencies. CRA was created out of a need for a "blessed" starter but it feels like the hope was that it would spark competition so it could be replaced with something else.
I agree! I meant to say the layoffs were probably the final nail in the coffin for CRA. Honestly, I always disliked CRA, and I'm glad to see it go.
The existence of craco to deal with CRA being opinionated to a fault is both awesome (in that I <3 the craco devs for making it, especially given when I discovered it I was right on the verge of reinventing it in a fit of rage and they'd already done it better than I would have) and something of a demonstration that one can take opinionation too far such that it becomes evolutionarily maladaptive.
I'm glad it's this way. I'm opinionated. I couldn't live in a Rails-like ecosystem. If you want an opinionated framework, there are frameworks built on top of React. Choose the one that fits your opinions best.
It's a view library. You'd expect there to be one opinionated way to use it?
> `react new`
This is basically what create-react-app was, but the community came out with better options.
> `react new`
This is basically what create-react-app was, but the community came out with better options.
[deleted]
At this time in my life, learning to do front end work at work seems to be more difficult than reading and understanding the LLM paper from OpenAI (or Stephen Wolframe: How LLM works lengthy article). I did some front end work in the first 3 years of my career in server side render with JSP. We added jquery and the likes and it felt little complicated but manageable. Then I become mostly backend eng for the next 14 years. Now I feel like the dumbest folk in the group when it comes to talking UI framework. I know how those stuff works but the process to put them all together is akin to pulling teeth. And then there is a recent discussion at work about going back to SSR with hydration and get rid of react altogether. Hydration, SSR, improving response time by lower round trip calls, geez we did that in the early 2000s.
Somehow I can’t help but thinking the way of shit we are in now maybe because of the ZIRP which is ending now. Maybe I can take a deep breath and say “things will be back to normal for fuck sake”
Sorry for the rant :-)
Sorry for the rant :-)
Things aren't normal because JavaScript in the browser is, technically, a very strange starting point for a computer revolution. It is quite different than the Unix REPL approach that preceded it. Much of the craziness is around shoe-horning javascript into the gcc paradigm (webpack) or shoe-horning gcc into javascript (webasm).
The question I'd like to explore, is what if you just author web pages in html, css, and javascript? I feel like web standards are very good, browsers are incredibly powerful, to the point it may be safe to attempt this approach.
Writing pages for modern browsers, with no polyfills, no transpilers, is quite pleasant. Writing JavaScript with arrow functions and destructuring and jquery-esque selector methods, and consistent event apis, is very pleasant. The module system is fine (I'm warming up to it). But how many professional front-end or full-stack folks would even know?
The question I'd like to explore, is what if you just author web pages in html, css, and javascript? I feel like web standards are very good, browsers are incredibly powerful, to the point it may be safe to attempt this approach.
Writing pages for modern browsers, with no polyfills, no transpilers, is quite pleasant. Writing JavaScript with arrow functions and destructuring and jquery-esque selector methods, and consistent event apis, is very pleasant. The module system is fine (I'm warming up to it). But how many professional front-end or full-stack folks would even know?
I've messed around a little with this because I like the idea of zero-dependency websites. I think the biggest issue I have is how web components work. I really hate that JavaScript is required. At least with SSR you can have nice, scoped components that don't need JavaScript. I know it's more and more niche but if my project doesn't need JavaScript for functionality and only uses it to enhance some experiences when available, I simply cannot use standard web components without using some other tool to deal with SSR, but at that point why bother with writing standard web components if some framework has some other nice additions?
>hate that JavaScript is required
JS hatred is a huge problem. It has driven huge projects since XHR was invented. Google's GWT was one of the first, targeted at Java devs. jQuery was a bit js hatey, too (early devs didn't know where js stopped and jquery began, including me). And js hatred continues to drive countless projects promising devs 'you don't have to learn js'.
I believe this attitude is utterly foolish. To build a webapp without knowing the foundations of the web is foolish. And much of the misery devs experience is because they weren't willing to do the harder, but wiser, thing and just suck it up, and learn how to program browsers. Literally every dev who's ever believed the line about not needing to know html, css, or js has discovered how utterly false this is.
(TypeScript is actually an exception here since it's a strict superset of JavaScript, so if you are a TS expert you are already a JS expert)
JS hatred is a huge problem. It has driven huge projects since XHR was invented. Google's GWT was one of the first, targeted at Java devs. jQuery was a bit js hatey, too (early devs didn't know where js stopped and jquery began, including me). And js hatred continues to drive countless projects promising devs 'you don't have to learn js'.
I believe this attitude is utterly foolish. To build a webapp without knowing the foundations of the web is foolish. And much of the misery devs experience is because they weren't willing to do the harder, but wiser, thing and just suck it up, and learn how to program browsers. Literally every dev who's ever believed the line about not needing to know html, css, or js has discovered how utterly false this is.
(TypeScript is actually an exception here since it's a strict superset of JavaScript, so if you are a TS expert you are already a JS expert)
Most of the "developers" working on "front-end" don't really understand these frameworks. These frameworks are "good" because they allow economies of scale. You can push a 6-month bootcamp "dev" into your project and he can start pumping React components almost immediately. The few companies I interacted with that went this way, can't produce any software beyond a nice front-end, a few back-end calls (nextjs functions) and the basic setup that nextjs/netlify boxed them in.
Wolframe's piece was specifically written to be as understandable as possible. No tech documentation were written with this intent in mind, or at least I don't know any.
(I'm on the Next.js team)
Something we haven't done a great job of, so far, is talking about how you can use Next.js for SPAs or client-only React sites. You can start with basic HTML/CSS/JS, deploy and host anywhere, and then optionally opt-into features that require using a server (and host somewhere like a Node.js server or through a Docker container). Next.js can generate an HTML file per route, rather than having one large SPA bundle.
There's been a lot of feedback around CRA no longer being recommended and folks looking for a replacement[1]—and uncertainty if Next.js is the correct solution. We've been working on some better docs[2] that help explain how to use Next.js without a server.
[1]: https://twitter.com/dan_abramov/status/1636886736784457734
[2]: https://beta.nextjs.org/docs/configuring/static-export
Something we haven't done a great job of, so far, is talking about how you can use Next.js for SPAs or client-only React sites. You can start with basic HTML/CSS/JS, deploy and host anywhere, and then optionally opt-into features that require using a server (and host somewhere like a Node.js server or through a Docker container). Next.js can generate an HTML file per route, rather than having one large SPA bundle.
There's been a lot of feedback around CRA no longer being recommended and folks looking for a replacement[1]—and uncertainty if Next.js is the correct solution. We've been working on some better docs[2] that help explain how to use Next.js without a server.
[1]: https://twitter.com/dan_abramov/status/1636886736784457734
[2]: https://beta.nextjs.org/docs/configuring/static-export
Vercel just does not get it, it tries to sell SSR-first(and that's what Vercel cares commercially, understood that) to CSR-works-too every time it gets a chance. It's not about document at all, if anything the document should never fake SSR-first to something like: set this flag then you get a CSR too, it does not work that way.
It's about the burden of mixing SSR and CSR, Vercel's next.js and sveltekit are both SSR-first by design no matter how you sugarcoat it. I may use them when I need SSR one day, but please stop overselling it as CSR-ready.
Talking about documentation, please do not forget Vuejs, it has the best document all in one place in the JS ecosystem, by the way, it is a true CSR SPA and its SSR(nuxt) is truly an opt-in.
It's about the burden of mixing SSR and CSR, Vercel's next.js and sveltekit are both SSR-first by design no matter how you sugarcoat it. I may use them when I need SSR one day, but please stop overselling it as CSR-ready.
Talking about documentation, please do not forget Vuejs, it has the best document all in one place in the JS ecosystem, by the way, it is a true CSR SPA and its SSR(nuxt) is truly an opt-in.
The core of Next.js is static/CSR. There's a one line configuration option to set your application in this mode—if you don't want to use the server, you don't have to.
The obvious question is: what's the advantage of using Next (over, say Vite) if you're not doing SSR?
Clean architecture, common patterns, lots of docs, fast compilation, horizontal scalability (one bundle per page), etc.
If you ever wanted to migrate to SSR, the path is open with Next, unlike Vite (without a lot of extra configuration).
You should really step up your elevator pitch. I'm not in the JavaScript ecosystem and after skimming your docs and searching on Google "what does next.js actually do" I'm still none the wiser. Seems to have something to do with what web developers call "routing" (which btw seems like a pompous way of describing how pages map to urls but I digress).
So one more time, explain like I'm five, what does next.js actually Do?
So one more time, explain like I'm five, what does next.js actually Do?
ELI5: Helps you make websites.
Next level (no pun intended): Makes working with React easy.
And another: Next.js provides tools for web developers (rendering UI components, fetching data from APIs, optimizing and displaying images and fonts, etc.) to create fast web sites/apps.
Next level (no pun intended): Makes working with React easy.
And another: Next.js provides tools for web developers (rendering UI components, fetching data from APIs, optimizing and displaying images and fonts, etc.) to create fast web sites/apps.
It's not obvious from that what the difference between React and Next.js is. React handles rendering UI components, you don't need either to fetch data from APIs, and displaying images and fonts is not something you need any JavaScript for, and srcset and media queries deal with optimizing, still no JavaScript required.
I'm not dismissing Next.js or you, I just feel like these aren't great points in a vacuum.
I'm not dismissing Next.js or you, I just feel like these aren't great points in a vacuum.
Next adds all the "missing pieces" that you would otherwise need to cobble together yourself when using just plain React to create a production-grade and ready web app.
Obviously these things can be done without using Next, React or even Javascript, like you say, but it all comes in a really well-integrated solution that mostly just works.
Obviously these things can be done without using Next, React or even Javascript, like you say, but it all comes in a really well-integrated solution that mostly just works.
I could believe it, I just think it's hard to sell that to some people, as it's not very specific. The pitch just isn't that compelling, as things like "fast", "just works", etc. aren't very useful. I'm not against things like Next, and I do think they're useful, but this branch of discussion was about the pitch. The homepage lists "Client and Server Rendering", "Nested Layouts", "Data Fetching", "API Routes", "Middleware", and "CSS Support" (and a few others) in a list of features that "make the web. Faster." Other than middleware, I would sure hope all of those things would be supported by a web tool since they've all been features of web browsers and servers for decades.
The point is that it's not clear what exactly Next does, let alone why it does those things. In my mind, Next (and friends) just helps smooth the edges of all aspects of modern web development. That's just not a very specific statement. Also, a lot of those edges aren't so sharp for a lot of use cases since modern browsers and servers offer the same functionality. I still think Next and friends are useful because the edges may not be as sharp, but there are quite a lot of them.
The point is that it's not clear what exactly Next does, let alone why it does those things. In my mind, Next (and friends) just helps smooth the edges of all aspects of modern web development. That's just not a very specific statement. Also, a lot of those edges aren't so sharp for a lot of use cases since modern browsers and servers offer the same functionality. I still think Next and friends are useful because the edges may not be as sharp, but there are quite a lot of them.
It's not the same as traditional SPA, especially with that 1 file per route setting. This is SSG and does impact how and where it can be deployed.
E.g. a traditional SPA (client only) can handle dynamic routes without extra intervention of a higher level router.
Otherwise yes SSG can be useful :)
E.g. a traditional SPA (client only) can handle dynamic routes without extra intervention of a higher level router.
Otherwise yes SSG can be useful :)
You can still do client-only routing (it was mentioned in the tweet linked above). It can be deployed anywhere that takes HTML/CSS/JS files.
Dan's gist clearly states you need to do rewrites yourself to make it work compared to traditional client side routed apps.
If you have rewrites it is not anywhere that purely takes HTML/CSS/JS.
If you have rewrites it is not anywhere that purely takes HTML/CSS/JS.
Dans gist is referring to needing a routing layer to map something like `/blog/my-latest-article` to `/blog/[article].html`. This is the same of any non-React SPA.
If I have `pages/blog/index.tsx` in my NextJS app this will get output to `blog.html` and can be deployed like a static site without further top-level routing.
If I have `pages/blog/index.tsx` in my NextJS app this will get output to `blog.html` and can be deployed like a static site without further top-level routing.
My original comment was specifically in reference to dynamic routes.
You're referring to static routes.
This is not the same as any non-React or non-Next SPA either way. A lot of them have SPA support i.e. route anything to index if there is no match. They may not have random rewrite support though.
You're referring to static routes.
This is not the same as any non-React or non-Next SPA either way. A lot of them have SPA support i.e. route anything to index if there is no match. They may not have random rewrite support though.
I think you bring up a great point! But while true, nothing really prevents one from adding their own router that handles for them that's decoupled from Next.JS and it would largely function as a traditional SPA (in that the export/'SSG' only builds one page, a la a true SPA).
And that IMO is kind of where the problem is - what level of abstraction should be added? Lots of beginners had problems because they were bombarded with the many confusing things to install to make something, and more often than not routing was one of them. It's just that Next.JS' is opinionated, but I'd argue so is everything else.
And that IMO is kind of where the problem is - what level of abstraction should be added? Lots of beginners had problems because they were bombarded with the many confusing things to install to make something, and more often than not routing was one of them. It's just that Next.JS' is opinionated, but I'd argue so is everything else.
Strong agree, lack of confirmation that this is a planned and intended usage of next is one of the reasons I've been hesitant to recommend it. All of our backends are java, and no one on my projects want to change that. We don't want to risk adopting a framework that will deprecate client side only usage.
Folks have been using Next.js this way for many years, and it has been documented, but not as clearly as we could have been. So the answer is, yes! There are no plans to ever deprecate client-side usage. We believe it's important to use the best parts of both the client and the server, not just one.
> We believe it's important to use the best parts of both the client and the server, not just one.
And many believe they do not need server-side JavaScript at all. We just need an SPA to speak to our API. We do not need "best of both worlds". Next is just more complexity over plain old client-side React. That's why some people including me are looking for alternatives to React recently. Next is not what we want or need.
And many believe they do not need server-side JavaScript at all. We just need an SPA to speak to our API. We do not need "best of both worlds". Next is just more complexity over plain old client-side React. That's why some people including me are looking for alternatives to React recently. Next is not what we want or need.
Does this include the ability to embed a NextJS CRA as a component from within a traditional server-returns-html page? I'd love to see an example of that sometime, where I could update my template to paste in some code that pulls in a NextJS component in one area of the page.
Yeah, of course. It's a set of HTML/CSS/JS files, so you can do really anything with it!
I recall reading Next docs and stumbling across features that are Vercel-only (like something about responsive images IIRC). Vercel being apparently their commercial thing, it put me off.
Shouldn't be (I'm on the team). All Next.js features work out of the box when using `next start`, either when deployed self-hosted (like a Node.js server or a Dockerfile), or when deploying to a platform like Vercel. We have documentation and examples for both types. This includes the image component, which automatically optimizes images for you.
Happy to see Client side stuff come back into NextJS. We exist and have legit use cases :-)
An incomplete sampling of the projects/frameworks/libraries mentioned in the article:
- create-react-app
- React
- Vite
- Webpack
- esbuild
- TypeScript
- ESLint
- Vue
- Remix
- Next.js
- OpenNext
- Astro
- Gatsby
- Parcel
- Turborepo
- React Native
- Expo
- Tauri
- Electron
- SvelteKitI'm a non-programmer, and recently I've been trying to turn a bunch of various time-saving scripts I've created over the years into a vaguely cohesive GUI. I figured aiming for a modern web gui framework (run locally) would be the way to go.
This comment encapsulates the experience so, so well. I have no idea what is going on, everyone tends to have a very strong opinion on which way to go, but no one can provide an explanation of the baby steps in how to get started. Or even why to get started. It's maddening.
This comment encapsulates the experience so, so well. I have no idea what is going on, everyone tends to have a very strong opinion on which way to go, but no one can provide an explanation of the baby steps in how to get started. Or even why to get started. It's maddening.
From that list you only need React and a bundler, which can be Vite. You really don't need more than that to get started. Please ask, I'll do my best to help you out.
What do you need for keeping CSS scoped to React components?
Solution 1: You can give a classname to your component and prefix every CSS rule with this classname. e.g. <CustomSelect>, which translates to <div className="custom-select">, which you can style by prefixing every rule with .custom-select. You put that in the index.css inside your folder CustomSelect to be easily editable when you need it.
Solution 2: Otherwise you could try to use CSS modules (Vite supports them out-of-the-box I think).
Solution 3: Otherwise you could try one of the many "CSS-in-JS" libraries like styled-components.
Personally I'm using the solution 1, did for more than a decade, works fine, scales well, nothing to install and learn, just old straightforward CSS.
Solution 2: Otherwise you could try to use CSS modules (Vite supports them out-of-the-box I think).
Solution 3: Otherwise you could try one of the many "CSS-in-JS" libraries like styled-components.
Personally I'm using the solution 1, did for more than a decade, works fine, scales well, nothing to install and learn, just old straightforward CSS.
In practice, I find keeping your CSS separate from the JSX tends to be cleanest (your solution 1).
Separation of concerns with what are essentially totally different markup languages is best when you can. We tolerate it with JSX because there isn't a fantastic first-class declarative way to express an object, a list of objects, or filtering in HTML. (I have seen WebComponents and the MDN tutorial seemed like taking a step back.)
Separation of concerns with what are essentially totally different markup languages is best when you can. We tolerate it with JSX because there isn't a fantastic first-class declarative way to express an object, a list of objects, or filtering in HTML. (I have seen WebComponents and the MDN tutorial seemed like taking a step back.)
Personally I suck at CSS and avoid writing it like the plague, even after 20+ years of doing it.
I use TailwindCSS [1] for all my styling needs and couldn't be happier.
If you really want scoped CSS in React this approach [2] can also work, and it makes it easy to use tailwind if you want.
[1] https://tailwindcss.com
[2] https://miyauchi.dev/posts/lib-vite-tailwindcss/#css-modules
I use TailwindCSS [1] for all my styling needs and couldn't be happier.
If you really want scoped CSS in React this approach [2] can also work, and it makes it easy to use tailwind if you want.
[1] https://tailwindcss.com
[2] https://miyauchi.dev/posts/lib-vite-tailwindcss/#css-modules
styled-components
If you are non-programmer, then you need to stay away from whatever bleeding edge tech HN and Reddit raves about.
Instead pick a stable tech. In js framework land, no tech is stable. But relatively speaking, react, Vue and Angular are more stable and popular. Among these Vue is more newbie friendly than others.
So, I would start with Vue. Checkout laracasts course on vue 3 to get started.
Instead pick a stable tech. In js framework land, no tech is stable. But relatively speaking, react, Vue and Angular are more stable and popular. Among these Vue is more newbie friendly than others.
So, I would start with Vue. Checkout laracasts course on vue 3 to get started.
I'm not particularly fond of Vue for my own use but pretty much every trade-off it makes that annoys -me- is one that also makes things easier to get started with.
So since the person we're making suggestions to is (so far as I'm aware, and I'm pretty sure I remembered my dried frog pills today) very definitely -not- me, I think I agree entirely with Vue as a starting point.
So since the person we're making suggestions to is (so far as I'm aware, and I'm pretty sure I remembered my dried frog pills today) very definitely -not- me, I think I agree entirely with Vue as a starting point.
I've stopped chasing front-end and fullstack roles and I know happily bang out PHP, because of this mess. PHP, think of the irony.
Did you find the salary trade off worth it though? PHP devs earn much less than others
Depends where you are and the company's industry.
I think this would be more useful as a tree structure than as a list.
Eg. Why would I need to care about electron and react native for a web app?
Eg. Why would I need to care about electron and react native for a web app?
I dove into the article expecting some advice on "How to start a React Project in 2023", got a compendium of the JS/TS framework landscape instead.
It comes close, but it isn't mentioning Turbopack [0], the thing I'm using right now to replace webpack. Really happy with it so far. (Turborepo is a sister project, but I'm not sure how the two are related - if Turborepo depends on Turbopack or vice-versa - and in any case I don't need it)
[0] https://turbo.build/pack
[0] https://turbo.build/pack
Perfectly called out. I think we have gone from “how to build a,b,c, will React help” to “I am building a,b,c in React. What all do I need” a long time ago and that’s been a perpetual source of pain. Cart before the horse all the way.
The article does a pretty good job of telling you which ones you need to care about and which ones you don't need to care about. And it's only 4-5 of these for a given project, which would look something like:
- TypeScript (langauge) - React (framework) - Vite (build tooling) - ESLint (linter)
That's not really any different to any other language. Maybe you have one extra tool in there for the build step.
- TypeScript (langauge) - React (framework) - Vite (build tooling) - ESLint (linter)
That's not really any different to any other language. Maybe you have one extra tool in there for the build step.
What‘s your point?
It's ridiculous.
Can you name another industry in tech that doesn't have a lot of options? Lets try backend, database, infra, ML, data science.
I feel there is a difference between all the domains you mention and frontend in that once you have made your choice regarding a single vendor or technology, very few vastly different avenues are left for starting a project. One example:
1) "How to start a Java project" - very vague, the article will arrive at your doorstep in book form as there are tons of possible ways depending on the use case
2) "How to start a REST API backend in Java" - a handful of bigger contenders are left on the table; some feature and performance comparisons could be handy
3) "How to start a REST API backend using Spring Boot" - a focused set of steps that leaves you with a controller class that will happily greet the user when a GET request is sent towards its general direction. I don't really want to explore the possibility of creating an application using NetBeans Platform or whatever at this point.
Here the casual reader might think that we are at level 3, but it seems that it's closer to level 1.
1) "How to start a Java project" - very vague, the article will arrive at your doorstep in book form as there are tons of possible ways depending on the use case
2) "How to start a REST API backend in Java" - a handful of bigger contenders are left on the table; some feature and performance comparisons could be handy
3) "How to start a REST API backend using Spring Boot" - a focused set of steps that leaves you with a controller class that will happily greet the user when a GET request is sent towards its general direction. I don't really want to explore the possibility of creating an application using NetBeans Platform or whatever at this point.
Here the casual reader might think that we are at level 3, but it seems that it's closer to level 1.
Once you choose any of those frameworks listed that support it, creating a REST api is trivial and very well documented within many. Likewise, they almost all prescribe recommended solutions for many other things.
That we have a wealth of good solutions is amazing, and it feels like people will find anything to complain about. If we had just a couple it’s lock-in or bad ecosystem. When you have a lot it’s messy and stupid.
It feels like a communist Russian coming to a US grocery store in the 80s and concluding it’s ridiculous they have too many choices how can they ever decide what to eat.
That we have a wealth of good solutions is amazing, and it feels like people will find anything to complain about. If we had just a couple it’s lock-in or bad ecosystem. When you have a lot it’s messy and stupid.
It feels like a communist Russian coming to a US grocery store in the 80s and concluding it’s ridiculous they have too many choices how can they ever decide what to eat.
As a mostly backend java developer and occasional frontend developer: every spring boot backend looks mostly the same, but every react frontend seems to look and work completely different. Sure, maybe there's a different library for db access or messaging or whatever used on the backend, but the general patterns are the same. Since React doesn't have any of the other pieces required for an app built in everyone glues together a hodgepodge to solve the same problems.
I don't know Java well but I think you're comparing different things. Compare Next.js with Spring for example.
[deleted]
If you're interested, this is the "absolute minimum" React project I was able to create, using esbuild (see `dev.mjs`) and some .html files. [0] It's a sub-package in a larger workspace, so there is some complexity inherited from the monorepo in terms of `tsconfig.json` and dependency management, but you can ignore that; the esbuild part was pleasantly simple to implement, and it pretty much "just works," such that each file in `www` is an entrypoint with one corresponding script from `pages/` that calls `createRoot(container).render(<App />)`.
Note that's also a "sandbox" for development purposes. If I were creating a new production app today, I would probably use Vite, which uses esbuild under the hood anyway. It's super easy to get started [1] with not only React, but also Lit or Vue or any other number of pre-configured templates, and it takes care of all the drudgery of bundling and tests for you so that you can get straight to work.
[0] https://github.com/splitgraph/madatdata/tree/main/packages/t...
[1] https://vitejs.dev/guide/#trying-vite-online
Note that's also a "sandbox" for development purposes. If I were creating a new production app today, I would probably use Vite, which uses esbuild under the hood anyway. It's super easy to get started [1] with not only React, but also Lit or Vue or any other number of pre-configured templates, and it takes care of all the drudgery of bundling and tests for you so that you can get straight to work.
[0] https://github.com/splitgraph/madatdata/tree/main/packages/t...
[1] https://vitejs.dev/guide/#trying-vite-online
So we’re back to the old pre SPA web and even have a term for it: MPA
If I build an MPA, why should I choose Astro if I can choose Rails? That’s a serious question to the HN community, not a rhetorical one - would very much love to learn if there’s something new here.
If I build an MPA, why should I choose Astro if I can choose Rails? That’s a serious question to the HN community, not a rhetorical one - would very much love to learn if there’s something new here.
As I see it, basically the inertia that JS devs don't want to switch from their beloved horrors of NPM.
Rails, Django/Flask or even Apache Struts or Java Spring would do good in this use case.
Rails, Django/Flask or even Apache Struts or Java Spring would do good in this use case.
They would not, they're not even trying to be the same thing.
I get that you don't like RSCs, that's fine you're allowed to have that opinion, but you can't justify it by saying it's a CRUD framework. Apples and oranges.
I get that you don't like RSCs, that's fine you're allowed to have that opinion, but you can't justify it by saying it's a CRUD framework. Apples and oranges.
Can you expand? I'm able to do non-CRUD things in Django just fine too. What's unique about RSC? People have been building production grade, multi page apps with it for almost two decades.
Yes, you can build static pages very easily in any of those frameworks, they're great for that.
The problem is that as soon as your frontend needs to be dynamic, these frameworks do nothing for you. You can do it on your own by using a library like React and making API calls, but that comes with its own set of issues.
RSCs are a way of addressing these issues by making UI and data streaming a core feature of the framework.
With Django you create an API endpoint that queries the database (this already gets complicated if you want types), then on the frontend fetch that endpoint (using some kind of library to manage the request complexity for you), then render that data.
With RSCs you write a server component that grabs data from the database directly and render it.
GraphQL addresses some of the same problems, but has its own set of issues. It's all about tradeoffs.
The problem is that as soon as your frontend needs to be dynamic, these frameworks do nothing for you. You can do it on your own by using a library like React and making API calls, but that comes with its own set of issues.
RSCs are a way of addressing these issues by making UI and data streaming a core feature of the framework.
With Django you create an API endpoint that queries the database (this already gets complicated if you want types), then on the frontend fetch that endpoint (using some kind of library to manage the request complexity for you), then render that data.
With RSCs you write a server component that grabs data from the database directly and render it.
GraphQL addresses some of the same problems, but has its own set of issues. It's all about tradeoffs.
> you can build static pages
There's some term confusion. "Static pages" is a different concept -- when there's no code executed on the server, server can only serve static content (no DB naturally), usually from a CDN that can cache responses. We're talking here about dynamic pages.
> a server component that grabs data from the database directly and render it.
Render where?
1. If it renders it to the html content for the browser, it's called "templating", and all the frameworks have been doing it for 20+ years (e.g. ASP, JSP, Jinja).
2. Render to the browser -- it still need to pass that data from server to browser, there's no way around it. And the idea of abstracting that, so the user would not know or care where the code is executed is not new at all. There were multiple attempts, for example see JSF, released on 2001. It burned in flames because you really want and need to know where the code is run.
And there never-ending attempts to at least write in the same language on server and browser, without abstracting the XMLHttpRequest (aka AJAX aka Fetch) layer. For example Node.js -- to use JS on server. Or GWT -- to use Java in browser (died, because you still absolutely want to know how it will be compiled to JS). Now Kotlin compiles to JS. Those are successful to a point. And the ultimate answer to bring all the languages to browser -- WebAssembly.
My point is -- all the attempts aiming to abstract away client-server boundary has been an utterly obvious failure. But if RSC does not aim to abstract it, then it's not different than technologies from 1999, but in Javascript.
There's some term confusion. "Static pages" is a different concept -- when there's no code executed on the server, server can only serve static content (no DB naturally), usually from a CDN that can cache responses. We're talking here about dynamic pages.
> a server component that grabs data from the database directly and render it.
Render where?
1. If it renders it to the html content for the browser, it's called "templating", and all the frameworks have been doing it for 20+ years (e.g. ASP, JSP, Jinja).
2. Render to the browser -- it still need to pass that data from server to browser, there's no way around it. And the idea of abstracting that, so the user would not know or care where the code is executed is not new at all. There were multiple attempts, for example see JSF, released on 2001. It burned in flames because you really want and need to know where the code is run.
And there never-ending attempts to at least write in the same language on server and browser, without abstracting the XMLHttpRequest (aka AJAX aka Fetch) layer. For example Node.js -- to use JS on server. Or GWT -- to use Java in browser (died, because you still absolutely want to know how it will be compiled to JS). Now Kotlin compiles to JS. Those are successful to a point. And the ultimate answer to bring all the languages to browser -- WebAssembly.
My point is -- all the attempts aiming to abstract away client-server boundary has been an utterly obvious failure. But if RSC does not aim to abstract it, then it's not different than technologies from 1999, but in Javascript.
After watching all this for a while, in order to get MVPs up and running while holding the IP and other things under control I’ve worked through RoR docs and did some projects in Django and I’d like to know more too. I’d bet on a re-emergence of traditional monoliths quite soon. That is if pocketbases and supabases aren’t going to be the new default which I’m not sure about right now. Recently built a site in NextJS and Nuxt though and I got to say it wasn’t that bad at all. But there’s something people are not considering enough and that is bringing value fast. That’s why I’m going deeper into Django (stability, reliability, value).
The other thing that keeps me in the Django ecosystem is frankly Django Admin. If any of the JS backend frameworks would provide these out of the box things that basically everyone needs, I would be much more open to using them.
For example, an admin panel for changing your models (like Django Admin), performance monitoring like Phoenix's LiveDashboard.
For example, an admin panel for changing your models (like Django Admin), performance monitoring like Phoenix's LiveDashboard.
TypeScript.
Rails is faster for building an MVP. But it's significantly worse than a project built with a typed language when it comes to extending and maintaining.
I thought I had misconfigured Sentry (for error logging) because the type of errors that plague Rails, or any language that is not typed, just don't happen with a typed language (unknown method called on NilClass).
We can decide to make a column in the DB to no longer allow NULL values, and we are immediately notified by the TypeScript compiler about every line that needs to be updated.
Rails is faster for building an MVP. But it's significantly worse than a project built with a typed language when it comes to extending and maintaining.
I thought I had misconfigured Sentry (for error logging) because the type of errors that plague Rails, or any language that is not typed, just don't happen with a typed language (unknown method called on NilClass).
We can decide to make a column in the DB to no longer allow NULL values, and we are immediately notified by the TypeScript compiler about every line that needs to be updated.
Exactly. more than 5 years ago or so I used a lot of Rails (and have worked with Java/C++ before), but after switching to a typed language like Go on large projects I completely removed Rails from my future projects.
The Ruby/Rails magic feels like its not worth it for long-term or even short-term maintenance.
The Ruby/Rails magic feels like its not worth it for long-term or even short-term maintenance.
I love type languages to the point Typscript is unacceptable. But Elixir/Phoenix has so many nice things to to point that an unsound static type is far inferior.
> Rails is faster for building an MVP. But it's significantly worse than a project built with a typed language when it comes to extending and maintaining.
I'm not sure that the academic work on software engineering really bares this out. Th Static vs. Dynamic debate is far from settled and increasingly looks to me like a matter of preference.
I'm not sure that the academic work on software engineering really bares this out. Th Static vs. Dynamic debate is far from settled and increasingly looks to me like a matter of preference.
[deleted]
>make a column in the DB to no longer allow NULL values, and we are immediately notified by the TypeScript
Can you elaborate on this? Is this using something like knex/objection or something else?
Is there something that will do this if one is using mostly raw sql with knex?
Can you elaborate on this? Is this using something like knex/objection or something else?
Is there something that will do this if one is using mostly raw sql with knex?
Prisma does the heavy lifting on our project:
https://www.prisma.io
I don't have experience with Knex so I, unfortunately, don't have an answer to your question.
https://www.prisma.io
I don't have experience with Knex so I, unfortunately, don't have an answer to your question.
This isn't really why most developers are choosing to use what they're choosing to use today, but in the long term the most granular serverless compute available is going to be running on V8 isolates, not containers. With JS (& WASM) you're going to be able to deploy globally w/o a build step in less than 10 seconds and pay a fraction of the cost for compute. That's why I'm focused on the JS ecosystem personally, I think the advantages are just going to keep compounding and the % of web applications being built with it is probably just going to keep going up.
I'd definitely choose Rails or Phoenix over Astro.
Mostly because of partial/conditional hydration. But you can achieve the same thing with is-land[1] on Rails as well.
[1]: https://github.com/11ty/is-land
[1]: https://github.com/11ty/is-land
Because Rails isn't good at building modern frontend experiences. It's built around static pages.
RSCs (and Next) are (going to be) built for dynamic pages. Loading new data from the backend is as simple as editing an ERB template, and you get updates on top of that. Suddenly you don't need to think about APIs nearly as much, you don't need to worry about making fetch requests, you don't need separate codebases.
If Rails decides to make data and UI streaming a primary building block then that would be awesome. Until then, that's why you would use RSCs.
RSCs (and Next) are (going to be) built for dynamic pages. Loading new data from the backend is as simple as editing an ERB template, and you get updates on top of that. Suddenly you don't need to think about APIs nearly as much, you don't need to worry about making fetch requests, you don't need separate codebases.
If Rails decides to make data and UI streaming a primary building block then that would be awesome. Until then, that's why you would use RSCs.
We’re using typescript to create static html like it’s 1996 again! Complete with inline styles and everything.
In the web browsers eyes, a Next.js app is just a plain old html page load when you navigate within the app. I believe the days of SPA’s and mounting on the bang# sign are dead. Some smart folks realized that it was more computational efficient to output plain old html like back in the days.
In the web browsers eyes, a Next.js app is just a plain old html page load when you navigate within the app. I believe the days of SPA’s and mounting on the bang# sign are dead. Some smart folks realized that it was more computational efficient to output plain old html like back in the days.
Because Rails is awful. You do not need to choose JavaScript. Just don‘t go with Rails.
Which parts of Rails do you dislike? It can be terrible if done poorly but overall Rails is pretty good for fast iteration.
You are correct. What I dislike about Rails is almost entirely because of Ruby and its damned ability to monkey patch everything.
Any serious production ruby codebase will have either no monkeypatching, or do it in isolated ways using things like refinements - https://ruby-doc.org/core-3.1.0/Refinement.html
The most I've seen it used is for backporting fixes from future Rails versions or other gems that are hard to update - and again it's easy to do this in an organized and clean way
Just because ruby gives you the tools to do stupid things (and every language lets you do stupid things) doesn't mean that you should do them in a real business app
The most I've seen it used is for backporting fixes from future Rails versions or other gems that are hard to update - and again it's easy to do this in an organized and clean way
Just because ruby gives you the tools to do stupid things (and every language lets you do stupid things) doesn't mean that you should do them in a real business app
Rails + hotwire for the win!
And you can use something like htmx to do everything on the server and use jquery to do fancy things. It’s a thing, especially for small one-off projects.
Neither, you would choose Remix
Create-react-app is deprecated? And the recommended replacement for SPAs is from the guy that makes Vue? What on earth?
It seems crazy, but it’s true. Also consider that Vite is a wrapper around 2 tools that are impressive in their own right: esbuild and rollup (and the latter was created by the guy who made svelte!)
It started out as one of his projects - an experiment to see if esbuild and native JS modules support in browsers could be used for development instead of webpack. It's become it's own project and has a large plugin ecosystem. The project doesn't involve vue, although it's the currently prescribed way to build vue projects now.
Vite is just an opinionated replacement for webpack, one of the biggest parts of create-react-app (which is obvious if you eject). This article's writer believes the out-of-the-box config for Vite is close enough to pre-eject CRA webpack config to be a drop in replacement.
You could stick with webpack. Its defaults have gotten better, even if CRA never quite aligned with that shift. (It is still slow and prone to config-related crankiness, but you don't need two thirds of what CRA ejected.)
So far in my own development, I find I generally prefer to use esbuild directly rather than the added weight of Vite and sometimes Vite feels like Create-React-App in that way that it obscures the power of the underlying components, though unlike Create-React-App Vite doesn't offer any sort of "eject" option. Vite adds some nice things like HMR support, but also now that browsers support script type="module" you can get nice dev experiences from unbundled modules without HMR and tools like esbuild/webpack become more of a "final pass" for Production rather than an always present development need. (Which is how Vite powers things like HMR, too, but you can do it by hand so easily now, I haven't yet been convinced to use Vite in a project.)
You could stick with webpack. Its defaults have gotten better, even if CRA never quite aligned with that shift. (It is still slow and prone to config-related crankiness, but you don't need two thirds of what CRA ejected.)
So far in my own development, I find I generally prefer to use esbuild directly rather than the added weight of Vite and sometimes Vite feels like Create-React-App in that way that it obscures the power of the underlying components, though unlike Create-React-App Vite doesn't offer any sort of "eject" option. Vite adds some nice things like HMR support, but also now that browsers support script type="module" you can get nice dev experiences from unbundled modules without HMR and tools like esbuild/webpack become more of a "final pass" for Production rather than an always present development need. (Which is how Vite powers things like HMR, too, but you can do it by hand so easily now, I haven't yet been convinced to use Vite in a project.)
To start developing a react project - all you need is a file bundler and a local dev server. Luckily webpack provides both and as a long-time web developer I strongly recommend just doing `npm init; npx webpack-cli init;`. To get react going you just do `npm install react react-router-dom`. I don't know why the author is suggesting rather "how to a start a React Project constrained by some kind of a framework".
So, let's recap the real rad method to start a React Project in 2023:
npx webpack-cli init Advantages:
1. You get what you want: a web bundler and a dev server
2. No premature bargains or decisions, all this base belongs to you.
3. Expand infinitely and meaningfully with modules you will want to utilize for covering your app's use-case, starting with react and react-dom
npx webpack-cli init Disadvantages:
1. Have to learn about your problems and discover solutions
2. Have to scroll through solutions documentation and configure them manually
3. Have to own your technical decisions and structure
So, let's recap the real rad method to start a React Project in 2023:
npx webpack-cli init Advantages:
1. You get what you want: a web bundler and a dev server
2. No premature bargains or decisions, all this base belongs to you.
3. Expand infinitely and meaningfully with modules you will want to utilize for covering your app's use-case, starting with react and react-dom
npx webpack-cli init Disadvantages:
1. Have to learn about your problems and discover solutions
2. Have to scroll through solutions documentation and configure them manually
3. Have to own your technical decisions and structure
> 1. You get what you want: a web bundler and a dev server
No I just want to build an app fast. Frameworks allows this to. One NPX command gets you a running app.
> 2. No premature bargains or decisions, all this base belongs to you.
Cool now you're the only snowflake in the world with a setup like your custom setup. All online help on frameworks people commonly use is useless to you, good luck
> 3. Expand infinitely and meaningfully with modules you will want to utilize for covering your app's use-case, starting with react and react-dom
Nope, with this naive approach you will soon encounter scalability problems, you will need code splitting, (per page maybe?), and you will inevitably re invent NextJS or a similar framework.
> 1. Have to learn about your problems and discover solutions
I want to focus on my client's problems not my problems
> 2. Have to scroll through solutions documentation and configure them manually
Yep
> 3. Have to own your technical decisions and structure
There is enough to own in this world. I guess you're also the kind of person who want to build your own Linux Distro and own the entire stack?
No I just want to build an app fast. Frameworks allows this to. One NPX command gets you a running app.
> 2. No premature bargains or decisions, all this base belongs to you.
Cool now you're the only snowflake in the world with a setup like your custom setup. All online help on frameworks people commonly use is useless to you, good luck
> 3. Expand infinitely and meaningfully with modules you will want to utilize for covering your app's use-case, starting with react and react-dom
Nope, with this naive approach you will soon encounter scalability problems, you will need code splitting, (per page maybe?), and you will inevitably re invent NextJS or a similar framework.
> 1. Have to learn about your problems and discover solutions
I want to focus on my client's problems not my problems
> 2. Have to scroll through solutions documentation and configure them manually
Yep
> 3. Have to own your technical decisions and structure
There is enough to own in this world. I guess you're also the kind of person who want to build your own Linux Distro and own the entire stack?
My npx command gives you the runnable app too, the problem with your approach is just that it is superficial, and it doesn't show a lot of comprehensions. I don't have any problem with that, since that places you behind in the competition. I see why you would want to use Next.js in order not to build it yourself, but in the first place, I don't see why you need Next.js features for a plain React app at all, and what benefits it gives, I don't see why you need to be renting a whole VPS for hosting that. React projects are typically statically built single-page apps which are not required to be statically rendered or dynamically served, you can serve the static bundle itself on a file-hosting, so the title of an OP post is just misleading, it clearly says "How to choose a framework for your React Project in 2023"
As someone who does actual software engineering (although I have done my share of software tree houses and garages as well):
If you don't have solid experience already: Don't plan your projects with anything except plain React configured with TypeScript. Use "Create React Application" (cra) to set it up and stick with the standards.
Everything else you can add later - if you need it - and in the mean time you have the chance to move faster without breaking things and make better decisions.
If you already have solid experience: consider this anyway if it is just another web application. I personally at least have seen a lot of time wasted because people always deviate from the standards both in React, Angular and Maven.
When time comes to add things we think we need, think about the tokens mentioned in https://boringtechnology.club
If you don't have solid experience already: Don't plan your projects with anything except plain React configured with TypeScript. Use "Create React Application" (cra) to set it up and stick with the standards.
Everything else you can add later - if you need it - and in the mean time you have the chance to move faster without breaking things and make better decisions.
If you already have solid experience: consider this anyway if it is just another web application. I personally at least have seen a lot of time wasted because people always deviate from the standards both in React, Angular and Maven.
When time comes to add things we think we need, think about the tokens mentioned in https://boringtechnology.club
A comment above said CRA is unmaintained and there were unfixed vulnerabilities. Is that not the case?
Last I checked the "unfixed vulnerabilities" where regex Denial Of Service at build time, see https://github.com/facebook/create-react-app/issues/11174
CRA is no longer recommended. Official recs are Next, Remix, and Gatsby.
https://react.dev/learn/start-a-new-react-project
https://react.dev/learn/start-a-new-react-project
Seems you are right. More context here: https://github.com/facebook/create-react-app/issues/13077
I just built a ChatGPT-powered Spanish tutor for my son using Fresh from Deno and it was overall an enjoyable experience. Once I grok’d how islands worked it was pretty smooth sailing.
I do love NextJS but I will try a few more Fresh projects soon.
I do love NextJS but I will try a few more Fresh projects soon.
Use svelte. Trust me. JS/TS + html and css
The biggest svelte complaint I see is that there aren’t enough libraries. That’s because it is trivial to built things with svelte. And as a UI engineer you should know how to build, not just npm install some-shit
Source: former UI tech lead, been using react since Dec 2015 and have built apps with it that are used by millions of users.
The biggest svelte complaint I see is that there aren’t enough libraries. That’s because it is trivial to built things with svelte. And as a UI engineer you should know how to build, not just npm install some-shit
Source: former UI tech lead, been using react since Dec 2015 and have built apps with it that are used by millions of users.
I dev in svelte/kit full time. I’ve built a ton of projects with it after doing corporate react stuff for a couple years. I’m so tired of hearing people say “well the ecosystem for react is stronger because of how many libraries there are.”
No, that’s not a good sign for a framework. If you need an enormous ecosystem of helpers to get anything done, that’s a detriment. Svelte doesn’t have libraries because it doesn’t need them. Kit comes with tons of out of the box features, and there’s nothing I can’t achieve with either:
1. My own JavaScript code. 2. An NPM package IF need be.
Seriously. Svelte has everything react has, with a much better developer experience. It’s the evolution of vanilla web, and even if I got canned tomorrow, I would search until I found another job with either stack freedom or svelte as it’s framework.
No, that’s not a good sign for a framework. If you need an enormous ecosystem of helpers to get anything done, that’s a detriment. Svelte doesn’t have libraries because it doesn’t need them. Kit comes with tons of out of the box features, and there’s nothing I can’t achieve with either:
1. My own JavaScript code. 2. An NPM package IF need be.
Seriously. Svelte has everything react has, with a much better developer experience. It’s the evolution of vanilla web, and even if I got canned tomorrow, I would search until I found another job with either stack freedom or svelte as it’s framework.
I started a new React project earlier this week and ran into approximately zero of the issues or concerns mentioned here in the comments.
I genuinely don’t get why the webdev community insists in making their jobs so difficult by refusing to actually learn the tools they’re using. CRA is unnecessary, Next.js is unnecessary. The simple tutorial on the React website gives you everything you need to get started, and you can research which other tools you need once and be good forever.
I genuinely don’t get why the webdev community insists in making their jobs so difficult by refusing to actually learn the tools they’re using. CRA is unnecessary, Next.js is unnecessary. The simple tutorial on the React website gives you everything you need to get started, and you can research which other tools you need once and be good forever.
If you need a framework: NextJS (no, don't suggest Remix, every single good feature about it has been copied by every library and their grandpas)
If you only need a bundler: Vite
If you want to be happy: Don't.
If you only need a bundler: Vite
If you want to be happy: Don't.
Remix is very nice if you want to do any of the things they designed it for, and absolutely impossible if you want to do something else.
[deleted]
I know it's not popular, but I still use "npx create-react-app" and have built successful apps with it. I'm sure I'm missing something, but it doesn't seem essential for my use cases.
Just use Next.js? If you just use it by following the getting started and don't use their SSR features if you don't want them, it will Just Work™
I really don't understand why the outcry even exists. It's recommended for a reason and whining about how SPAs still exists misses that no one ever said that it doesn't. The only thing people are mad about is that Vite didn't make the list but that's understandable because I could never tell the new React developers we just hired to do this project by themselves with Vite. But with Next.js (or whatever else on the list) it was a matter of "File here, this URL, your React component here. Don't think about SSR I'll take care of it if we need it."
And it just works. Even too good because they run into issues so rarely that I forget that they make so much progress and we're already on our 3rd project with it. And they literally started coding 5 months ago.
And if you care about what's going on under the hood, guess what? You're one Bing chat away from finding Vite and a few commands to have it running locally. Want SSR now too? Guess again, you are already setup to do exactly that in a way more ergonomic way than the low level Vite plugin (which I like, but I would never be able to hand-off to other developers)
I really don't understand why the outcry even exists. It's recommended for a reason and whining about how SPAs still exists misses that no one ever said that it doesn't. The only thing people are mad about is that Vite didn't make the list but that's understandable because I could never tell the new React developers we just hired to do this project by themselves with Vite. But with Next.js (or whatever else on the list) it was a matter of "File here, this URL, your React component here. Don't think about SSR I'll take care of it if we need it."
And it just works. Even too good because they run into issues so rarely that I forget that they make so much progress and we're already on our 3rd project with it. And they literally started coding 5 months ago.
And if you care about what's going on under the hood, guess what? You're one Bing chat away from finding Vite and a few commands to have it running locally. Want SSR now too? Guess again, you are already setup to do exactly that in a way more ergonomic way than the low level Vite plugin (which I like, but I would never be able to hand-off to other developers)
Also, Next works reasonably well as a static site generator, too.
> However, since SSR is becoming a more important topic these days
Is it? This is the first I’ve heard of this fantastic news. What’s changed to have caused the increased importance?
Is it? This is the first I’ve heard of this fantastic news. What’s changed to have caused the increased importance?
IMO the community shifted from SSR to SPA initially very rapidly due to the huge benefits over entirely SSR apps, but it came with some notable pain points and some new frameworks that incorporate parts of SSR have been attracting a lot of attention for solving those pain points.
A lot of leading maintainers now feel that the best solution is more of a middle ground where frameworks support both server side and client side rendering with the developers given the flexibility to choose what renders where (or on both) depending on the app's needs. React is driving a lot of this now with server side components, but there's a lot of frameworks that were doing it beforehand which has inspired much of what they're doing now.
A lot of leading maintainers now feel that the best solution is more of a middle ground where frameworks support both server side and client side rendering with the developers given the flexibility to choose what renders where (or on both) depending on the app's needs. React is driving a lot of this now with server side components, but there's a lot of frameworks that were doing it beforehand which has inspired much of what they're doing now.
I tend to only use esbuild on solo projects. It's simple, compiles JSX and TS, and the documentation is mostly easy to understand. The API also makes it easy to just create a `build.js` script I can call. As a bonus, it also includes live reload and a server these days.
Vite seems like the best batteries-included solution that is still relatively lightweight compared to going all in on a framework like Next.
I feel like the React folks are in this unfortunate position where they have to cater to people differently than other JavaScript libraries do, because to a lot of people, "React" means more than just a JavaScript library. And to some, they've never written JavaScript without React or even without build tools for that matter. I personally prefer the less-is-more approach to learning JS or any JS library (start with an .html file and a <script> tag, work your way up) and even though that may be a healthier way of learning React, it might frustrate more new users who just wanna make a shiny app.
Vite seems like the best batteries-included solution that is still relatively lightweight compared to going all in on a framework like Next.
I feel like the React folks are in this unfortunate position where they have to cater to people differently than other JavaScript libraries do, because to a lot of people, "React" means more than just a JavaScript library. And to some, they've never written JavaScript without React or even without build tools for that matter. I personally prefer the less-is-more approach to learning JS or any JS library (start with an .html file and a <script> tag, work your way up) and even though that may be a healthier way of learning React, it might frustrate more new users who just wanna make a shiny app.
The best way to start a react app is to use Svelte.
Someone should map out every frontend framework and it's path to everything, from SPA to SSR & which libraries that exists within that ecosystem.
Nvm, roadmap.sh/frontend came to my mind.
Nvm, roadmap.sh/frontend came to my mind.
i can feel i am not the only one sharing the frustration on this, has anyone seen any dead simple js library or approach to build simple web apps that does not include boilerplates, builders, generators and what not? something like jquery but on steorids?
I haven’t built anything with it yet, but htmx looks promising.
A bit unrelated, but what happened to Angular?
Angular is basically headed down the same path that Ember went down IMO. A stable & mature but declining framework.
The same could ultimately happen to React as well. I'm working on a new project right now using Remix, which is great, but I've also realized that really nothing I've done wouldn't have worked just as well without React. Fortunately I really enjoy Remix, but if SvelteKit or SolidStart provide a similar experience I don't really see why I would stick with React.
The same could ultimately happen to React as well. I'm working on a new project right now using Remix, which is great, but I've also realized that really nothing I've done wouldn't have worked just as well without React. Fortunately I really enjoy Remix, but if SvelteKit or SolidStart provide a similar experience I don't really see why I would stick with React.
Stable? dont they release breaking majors each 6 months?
Technically yes but just because they have a scheduled major release every 6 months doesn’t mean you’re going to see significant breaking changes. They’re not as conservative as Ember in that regard (still on 3.x!) but relative to React, Vue, etc things aren’t changing as quickly.
That's never been my experience at all. React's backwards compatibility has been always in a class of its own.
Angular? Migrating from one major to another was always source of great pain.
Angular? Migrating from one major to another was always source of great pain.
Still the best choice in my opinion. Batteries included for pretty much anything and RxJS is a delight. I really never have to think about state management issues.
My only concern are signals. They seem like worse Observables just for the sake of something new. Hope they never get added
My only concern are signals. They seem like worse Observables just for the sake of something new. Hope they never get added
Just keep in mind that SSR in Angular is a bit more painful than in other libraries. It's also quite bloated in both development and production. Other than that I quite like it. RxJS takes some time to learn but pays off well.
If you're ok with learning something with less adoption but similar batteries-included feel I'd recommend learning SvelteKit. I see it do a lot of things that Angular does well without failing were it's bad (i.e. breaking changes every six months).
If you're ok with learning something with less adoption but similar batteries-included feel I'd recommend learning SvelteKit. I see it do a lot of things that Angular does well without failing were it's bad (i.e. breaking changes every six months).
I still love it, after 6 years I don't really know what problem it isn't solving and I mean 10 versions later! Also keep it to yourself but RXJS, my old hatred is now responsible for some of the best code I have ever written as far as being proud is concerned.
Couldn't agree more!
Still heavily used in gov / enterpries / finance.
Anecdotally after 6 years of React, switching back to Angular it has a huge learning curve. Such a large surface area with zonejs, rxjs, modules. I feel productive with it now and actually prefer services + rxjs to redux. I like how much is included and has established pattern but it feels very heavy handed, just adding a single component involves a stupid amount of boilerplat.
Anecdotally after 6 years of React, switching back to Angular it has a huge learning curve. Such a large surface area with zonejs, rxjs, modules. I feel productive with it now and actually prefer services + rxjs to redux. I like how much is included and has established pattern but it feels very heavy handed, just adding a single component involves a stupid amount of boilerplat.
Angular has a deprecated modules now, so dealing with components should be less work as well.
Probably few people use it, but it is probably very useful for those who use it. I like angular's philosophy of trying to solve every issue in itself.
Maybe it's not so popular for startups, but Angular is kinda like .NET - maybe not the new hot thing, but very well bedded down in large orgs and govt.
I use Angular daily as a frontend for our C++ app, hosted in Electron. I personally love the fact that it's opinionated (using their router, DI, etc) and most of their API is pretty extensible. For our purposes, it beats out Qt if you want an app with a highly custom UI. We chose it over React for the simple fact that it is so "batteries included".
It is stuck on webpack, while everyone else moved to next gen tool.
If you are new to angular, then I suggest stay away and come back in a year or two because Angular is going through a major paradigm shift. From webpack to esbuild, from zones to signals, from Rxjs everywhere to signals for synchronous change detection etc.
If you are new to angular, then I suggest stay away and come back in a year or two because Angular is going through a major paradigm shift. From webpack to esbuild, from zones to signals, from Rxjs everywhere to signals for synchronous change detection etc.
Angular doesn't play well with newer build tools - esbuild, vite, etc., making Angular quite isolated from the other frameworks. So a plug for vite is a plug for most frameworks except Angular (and others not on the radar).
But also Angular has egregiously big build times as your project scales up, and that sucks.
But also Angular has egregiously big build times as your project scales up, and that sucks.
What about your developers though? Our company pays for 5 days a week 8 hours a day of talented humans in a medium team. I can throw compute for 1/10000th that.
A 56 module Angular 15 codebase `npm start` takes 10 seconds, and compiles after change faster than a browser refresh. The build takes 67 seconds.
What scale up are you talking about so that I know in the future what to look out for?
A 56 module Angular 15 codebase `npm start` takes 10 seconds, and compiles after change faster than a browser refresh. The build takes 67 seconds.
What scale up are you talking about so that I know in the future what to look out for?
I think we were at around ~150k lines of typescript I think. We were also stuck on Angular 12 due to browser compatibility issues (cries in IE11). I think we were looking at ~20s for the dev server and ~25 minutes for the the prod builds.
25 minutes??
Do you know which parts of the build are taking the longest? Transpiling, bundling etc?
Do you know which parts of the build are taking the longest? Transpiling, bundling etc?
I'm struggling with those numbers personally.
I'm still using it - it does the job.
I think there can be a bit more complexity than React (components, services, interceptors etc) but I've never found it to be hard to understand, even with all the extra stuff.
I learned Angular with v1. When v2 came out, it was so different I had to learn a new framework either way. I went with React because it was the one gaining the most traction. I think that’s what happened writ large.
Same thing that happens to every JS framework after a few years.
Not sure what your definition of few is, but there are plenty of old, boring, stable frameworks out there that run perfectly fine, like Mithril. You don't have to constantly rewrite your frontend if you stick as close to raw JS/TS as possible.
Angular 14 is the latest version, last I looked it was 5. Things move so fast in FE world!
And soon quite a bit of us FE devs or any devs for that matter are nailed out anyhow, just look at the LLMs developing. Give it some time, haha.
They started doing fast top level versions like Chrome, since Angular is Google too.
I was fully expecting to see a one-liner for this article: npx create next app. I think this article overstates the disadvantages of using a framework like NextJS.
If you don’t want to work on the bleeding edge, then don’t upgrade right away. That’s true of literally every library out there.
And IMO it’s trivial to host a next app just about anywhere. Vercel has done a much better job with portability than you would typically expect from similar companies.
The docs for NextJS are also just… rock solid. It really feels like they cover everything.
I’m not affiliated, just a happy developer using their framework.
If you don’t want to work on the bleeding edge, then don’t upgrade right away. That’s true of literally every library out there.
And IMO it’s trivial to host a next app just about anywhere. Vercel has done a much better job with portability than you would typically expect from similar companies.
The docs for NextJS are also just… rock solid. It really feels like they cover everything.
I’m not affiliated, just a happy developer using their framework.
Thank you, glad to hear the docs worked well! Let me know if you have any feedback.
Vendor lock-in.
Theres no vendor lock-in if you can scp your codebase to any vps and run `next build && next start` and have it work out of the box
It is literally MIT licensed software. It’s no more vendor lock-in than React is in the first place.
the license wouldn't be that important if say it was just covering over a vercel specific API. that's not the case here, but the license would be irrelevant if it's just talking to a vendor locked service.
Oh wow, this couldn't be more topical for me if it had to be. I seeded and maintained a react site at old job; so thought that I would do the same at new job.
I'm more than a little wary, as I have seen how easily out of hand the front end can get. Any "services" we are writing will be backend and mirroring all of that effort on the frontend feels very misguided. Not at all happy that the first thing I stumble into is looking to be a giant featured framework.
I'm more than a little wary, as I have seen how easily out of hand the front end can get. Any "services" we are writing will be backend and mirroring all of that effort on the frontend feels very misguided. Not at all happy that the first thing I stumble into is looking to be a giant featured framework.
I love Next.js and don't find Vercel vendor lock-in from it. I've deployed a next app on github pages and it understood my folder based API structure fine
How to start a react project: don't. Use raw browser APIs. Maybe build yourself some thin wrappers for those APIs that you find awkward to use as is.
I genuinely don't understand why so many people want to abstract the platform away in projects that only run on a single platform (the browser in this case). You want to be as close to your platform as possible if you care about performance and resource use.
I genuinely don't understand why so many people want to abstract the platform away in projects that only run on a single platform (the browser in this case). You want to be as close to your platform as possible if you care about performance and resource use.
And once you've assembled your thin wrappers, and a few utility functions that really improve QoL, it would be a shame not to share it with the community.
So make a cute name and logo, make a website using words like "superhero" and "fun!", and make an announcement on Hacker News (where someone will invariably make some comment about not needing a framework lol)... then toss it in the pile with the thousands of other (unmaintained) front end frameworks.
So make a cute name and logo, make a website using words like "superhero" and "fun!", and make an announcement on Hacker News (where someone will invariably make some comment about not needing a framework lol)... then toss it in the pile with the thousands of other (unmaintained) front end frameworks.
I care about shipping products to customers for feedback, and then iterating as quickly as possible once I get it, so that I can earn as much money as possible.
Have fun with your performance and resource use, though. Sounds really interesting.
Have fun with your performance and resource use, though. Sounds really interesting.
I’m currently working on a free open source framework for React developers and I’d love some feedback!
It’s a batteries included React framework for scaffolding out a Stripe level frontend, complete with a blog and documentation.
It’s built on top of Next.js, and is essentially free to host. :)
Please check out my minimum viable prototype and tell me what you think: https://elegantframework.com
It’s a batteries included React framework for scaffolding out a Stripe level frontend, complete with a blog and documentation.
It’s built on top of Next.js, and is essentially free to host. :)
Please check out my minimum viable prototype and tell me what you think: https://elegantframework.com
As someone new to React, but who has used Webpack, I'm glad that CRA is gone.
It felt like "ravioli code" to me, and it seemed wrong that everyone was reluctant to use "eject", but then you couldn't configure any of the underlying tools, like Webpack, easily either.
Tools should be easily composable, they shouldn't be clumped together with an inflexible "ravioli" abstraction.
It felt like "ravioli code" to me, and it seemed wrong that everyone was reluctant to use "eject", but then you couldn't configure any of the underlying tools, like Webpack, easily either.
Tools should be easily composable, they shouldn't be clumped together with an inflexible "ravioli" abstraction.
The irony of CRA is that it would become a system you needed to learn in and of itself in order to navigate the treachery of trying to manage a modern React app.
I’m not disparaging it generally though. It was truly useful to many people and reduced barriers to allowing people to more easily experience React. Arguably, the mess of needing to understand internals of CRA to solve weird bugs or needing to eject was in some ways a good thing. Perhaps people wouldn’t have made it that far without the initial ease of building with react!
You’re absolutely right though. The design of CRA imposed a lot of inevitable issues. Partially due to how webpack works and due to (in my opinion) the fragility of the npm ecosystem. There was so much complexity and so many dependencies. Perhaps some of these things changed for the better over time — it has been a while since I looked at it. The last time I did, that aspect was labyrinthine and awful to navigate when things went wrong.
I’m not disparaging it generally though. It was truly useful to many people and reduced barriers to allowing people to more easily experience React. Arguably, the mess of needing to understand internals of CRA to solve weird bugs or needing to eject was in some ways a good thing. Perhaps people wouldn’t have made it that far without the initial ease of building with react!
You’re absolutely right though. The design of CRA imposed a lot of inevitable issues. Partially due to how webpack works and due to (in my opinion) the fragility of the npm ecosystem. There was so much complexity and so many dependencies. Perhaps some of these things changed for the better over time — it has been a while since I looked at it. The last time I did, that aspect was labyrinthine and awful to navigate when things went wrong.
> I’m not disparaging it generally though.
Definitely, it was neat how the developers gave you a survey if you did use "eject".
But I think the answer is to deal with the issue of making tools more easily composable, or improving the documentation of how to use them, rather than providing the abstraction.
Definitely, it was neat how the developers gave you a survey if you did use "eject".
But I think the answer is to deal with the issue of making tools more easily composable, or improving the documentation of how to use them, rather than providing the abstraction.
I am not much of a fan of CRA myself but I am very much glad that https://craco.js.org exists - so far it's handled my needs for tweaking CRA behaviour in situations where "eject" didn't seem like a good route to take.
Mostly tbh to stop the freaking thing spawning inotify watchers for the entire contents of node_modules - I don't mind having to do a manual restart when I've changed dependencies and I definitely -do- mind having it eat a shedload of my user's inotify kernel allocation. (I know you can up the allocation, that's not the point, why are you on my lawn? :)
Mostly tbh to stop the freaking thing spawning inotify watchers for the entire contents of node_modules - I don't mind having to do a manual restart when I've changed dependencies and I definitely -do- mind having it eat a shedload of my user's inotify kernel allocation. (I know you can up the allocation, that's not the point, why are you on my lawn? :)
I'd add to the article that Vite allows to make React components libraries too. Same tool to build your apps and your libraries.
> bleeding edge tech solves many problems ...
> which day to day tech workers working on internal B2B do not face
That's so true. Good luck explaining to management that the front-end app needs additional cloud resources, such as a server, so we are on the edge of the trend with SSR.
Most apps behind a login face tough architectural / security meetings, defending SSR for their use-case.
> which day to day tech workers working on internal B2B do not face
That's so true. Good luck explaining to management that the front-end app needs additional cloud resources, such as a server, so we are on the edge of the trend with SSR.
Most apps behind a login face tough architectural / security meetings, defending SSR for their use-case.
Both React's and NextJS' marketing is straight-up obnoxious.
Currently, React Router is the only React framework that is even offering a solution to data fetching, mutations and transitions in the CSR space. Very basic problems.
NextJS is not at all a CSR framework. In that space it suffers all the problems your average CRA application has.
Currently, React Router is the only React framework that is even offering a solution to data fetching, mutations and transitions in the CSR space. Very basic problems.
NextJS is not at all a CSR framework. In that space it suffers all the problems your average CRA application has.
The frontend web framework landscape is pretty complicated and fragmented, sure, but is it really any different from backend?
Take a look at Amazon’s or Google’s enormous list of cloud products and tell me your eyes don’t glaze over. And that’s not even the full ecosystem, it’s just the products directly supported by one company!
Take a look at Amazon’s or Google’s enormous list of cloud products and tell me your eyes don’t glaze over. And that’s not even the full ecosystem, it’s just the products directly supported by one company!
I think the difference is that AWS doesn't have seven frameworks for the same thing.. there certainly different levels to their services, but they generally are abstracting away the lower end each time they make a new product in a category..
There isn't really two different EC2-like systems, or two different S3 products, there's a new "popular" JS UI framework every year, and if you're still using the older framework 4 years later, it likely needs a heavy rework to upgrade to the latest version.
I "learned" SQS 6 years ago, now I just keep up with the minor feature releases.. same with S3, and Lambda. In the same time I've looked at 4 different UI frameworks that have no overlap but try to do the same and result. Their services exist and they work.. and generally a guide from 5-10 yeas ago is still valid today (though the UI might be different, but the content remains reasonably valid)..
There isn't really two different EC2-like systems, or two different S3 products, there's a new "popular" JS UI framework every year, and if you're still using the older framework 4 years later, it likely needs a heavy rework to upgrade to the latest version.
I "learned" SQS 6 years ago, now I just keep up with the minor feature releases.. same with S3, and Lambda. In the same time I've looked at 4 different UI frameworks that have no overlap but try to do the same and result. Their services exist and they work.. and generally a guide from 5-10 yeas ago is still valid today (though the UI might be different, but the content remains reasonably valid)..
If you enjoy productivity on all levels (also performance) just go with Next. If you are a purist go vanilla js.
If you genuinely care about productivity go with Svelte. React is unproductive and unintutive.
Tried it, went well for awhile, but when you get stuck it's tough to find support. Very small community. Probably 1000x less content/resources/references out there for it.
On the other hand NextJS/React have been both productive and intuitive. There are so many examples out there and people are constantly talking about the nuances of both here and on other sites.
It'd be great to see Next integrate something like TRPC/OpenAPI into it so calls to the backend could be statically typed. That would really polish up the end to end experience.
On the other hand NextJS/React have been both productive and intuitive. There are so many examples out there and people are constantly talking about the nuances of both here and on other sites.
It'd be great to see Next integrate something like TRPC/OpenAPI into it so calls to the backend could be statically typed. That would really polish up the end to end experience.
You might be interested in this if you weren't already aware of it https://blitzjs.com/
I've been using their superjson library with Remix & its pretty much solved all of my client/server type issues.
I've been using their superjson library with Remix & its pretty much solved all of my client/server type issues.
React was the same in 2014, Give Svelte time.
Svelte was released in 2016, it's 7 years old now. Year-to-year, it should match 2020 React.
Sure but Svelte 3 was the big one, which was 2019. More to the point there's a generational difference.
I feel like StackOverflow for Svelte is healthy and due to the batteries-included approach for storage and CSS the community is a lot less fragmented than the React community was (and maybe still is, I don't know).
I feel like StackOverflow for Svelte is healthy and due to the batteries-included approach for storage and CSS the community is a lot less fragmented than the React community was (and maybe still is, I don't know).
Remix is worth checking out as well. I've had a great experience with it so far.
Although I don't like some features of nextjs, it works for me. (things like server side prop management)
An interesting article, but it's unfortunately one more that misses the elephant in the room: Nrwl NX: https://nx.dev/
The esbuild diagram is quite misleading because Vite does not only use esbuild, but also rollup and postcss.
Webpack can be set up with esbuild and will be equally fast, while being more flexible to configure, especially regarding multiple CSS entry points, which to my knowledge is not possible with Vite.
Webpack can be set up with esbuild and will be equally fast, while being more flexible to configure, especially regarding multiple CSS entry points, which to my knowledge is not possible with Vite.
> [Vite is] almost drop-in replacement for create-react-app (CRA)
Can anyone with experience replacing CRA with Vite speak to how true this is?
Can anyone with experience replacing CRA with Vite speak to how true this is?
How to start a React project in 2023: Don't.
Seriously there is zero reason to use monstrous, painful software unless you're a sadist.
Use something like solid or better yet go for a substantially better language like Imba, especially if you're a startup.
Seriously there is zero reason to use monstrous, painful software unless you're a sadist.
Use something like solid or better yet go for a substantially better language like Imba, especially if you're a startup.
React is neither monstrous nor painful, and the main concept people tend to forget is that we build software to provide value. If React gets me that value the fastest, I’m going to use it.
Most folks aren’t trying to win a CS purity contest when founding a company.
Most folks aren’t trying to win a CS purity contest when founding a company.
I should maybe give solid a fair shake again, I don't think I got "Reactivity" or the signals stuff properly explained to me and got frustrated that something I could easily, competently do with react+setState just fell over or bugged out in their little demo / codepen (huge props to having that demo/codepen though, much nicer UX for a dev trying to learn than just documentation)
But that Imba thing? I rewrote this and the kindest I can say is.... I don't see the value add? Learning it isn't going to be transferable?
But that Imba thing? I rewrote this and the kindest I can say is.... I don't see the value add? Learning it isn't going to be transferable?
Reactivity is magnitudes simpler and more performant than react style state diffing, it's also much harder to write bad performance code because there's no react style re-rendering. The basic form of signal can be just
Of course Solid's signal implementation is much more robust and have some very mild magic to make the UX better, but the core concept is really simple. Read about Solid's implementation here https://dev.to/ryansolid/building-a-reactive-library-from-sc...
function signal(value) {
const subs = []
return {
get: () => value,
set: (newValue) => {
value = newValue
subs.forEach(f => f(value))
},
sub: (action) => subs.push(action),
}
}
Of course Solid's signal implementation is much more robust and have some very mild magic to make the UX better, but the core concept is really simple. Read about Solid's implementation here https://dev.to/ryansolid/building-a-reactive-library-from-sc...
> there's almost no overhead
The runtime has to maintain a graph of those signals tree in memory at all time, no? Compared to React that can throw away the vdom after it finished the render.
The runtime has to maintain a graph of those signals tree in memory at all time, no? Compared to React that can throw away the vdom after it finished the render.
I don't think there need to be a tree or any data structure signals need to be stored in, as long as those objects are preserved in memory and can be referenced.
Imba looks absolutely awful. I guarantee that will never take off!
I gave you an upvote. There are many legitimate reasons not to start with React in new projects. At this point I think we reach the consensus that React's benefit is only it being popular (hiring pool + libs pool). It's slow and bloat relatively compared to the rest.
npx create-next-app@latest myapp
Honestly, for every new project I now use tRPC + Next.js, and I expect this to finally be the stack that will last me the next 10 years.
If you are targeting native and web, I think the Tamagui + Solito starter that lets you share code between Expo/Nextjs is unbeat (disclaimer, I made Tamagui):
Just `npm create tamagui@latest`
See: https://tamagui.dev
Happy hacking!
Just `npm create tamagui@latest`
See: https://tamagui.dev
Happy hacking!
Related: I really hate the trend of always using @latest. It's like in frontend there's no stable versions with known feature list and known bugs, it's always latest of whatever it is. Why?
Latest ensures if you used it before it won’t use the old version. npm create otherwise will always use the starter script that you last used, which isn’t what you want in this case. You always want the latest if you’re starting a new project. For the first time you can leave it off, but it’s safer just to recommend always using it to avoid confusing stale create script problems down the road.
And now I just read this article, and, well, I'm even less motivated to get into this stuff. Is this just a really bad time for React? Or is it always such a chaotic changing climate around it?