51–60 of 164 posts
I haven't spent much time with Next.js, but luckily React will soon natively support[0] SSR. Wonder if Next.js will still be around once React Server Components are fully released. [0] https://reactjs.org/blog/2020/12/21/data-fetching-with-react...
> Therefore, we've elected to render our application completely on the client. On Next.js this means that we wrap our React app in a "client-side only" component that looks like this: > > This component only allows our React code to render inside the browser environment, minimizing Next.js' server-side render runtime. Yep, sounds like a practical way to do what is literally the default. So does the 4 paragraphs of cl…
> At Liferay Cloud, our project lives behind authentication and our clients are enterprise-level, with relatively modern browsers and powerful networks. So, SEO and client-side limitations are not concerns for us. Therefore, we've elected to render our application completely on the client.
So, why are you using an SSR framework then?
The FE stack at my current co. is React, MobX and TypeScript, powered by REST APIs that are well documented via OAS. It’s a very nice, easy to learn and maintain stack.
I really love this kind of article because, as primarily a Backend developer, I'm finding it really really hard to make a "clean" SPA without any mentorship or help from experienced Frontend Devs. I can't find any well-documented best practices or architectures and patterns that seem to be widely accepted in the frontend ecosystem like there are for backends. Next is the closest that comes to having a "right way" but…
I'm in the same boat. But I don't think there's a lack of good info, but rather there's too much info and too many variants and options. There are probably many "correct" choices in the beginning, but we naturally want the good beginning and good long term maintainability/extendability. Rails without a JS frontend is excellent in so many cases. The trap is when you start adding a little JS here and there to make thin…
Not sure if Yeoman is still around but did they not attempt something similar?
I really love this kind of article because, as primarily a Backend developer, I'm finding it really really hard to make a "clean" SPA without any mentorship or help from experienced Frontend Devs. I can't find any well-documented best practices or architectures and patterns that seem to be widely accepted in the frontend ecosystem like there are for backends. Next is the closest that comes to having a "right way" but…
As someone without this new web tech background, I have same experience about react. create-react-app has so many dependencies and takes a lot of time to scaffold a hello world. Adding some router or some popular library produces deprecation warnings and '2 moderate vulnerability' messages. Folder size will blow up over 1 GB to make trivial apps. That's insane.
Not the smoothest first impression for what's supposed to be the "on rails" introduction to react development.
We are using every new technology because why not, but we don't think about our use cases.
Things like "/items/12345/detail" let me believe that this is not a spa really? More like a good old MPA?
I'm not sure if the chosen technologies are the right ones for the jobs.
In general, I don't understand the trend to default to something like reactjs. We have and had alternatives.
What I see is that people complain about technologies which are not build for what they are using. To get good performance and bundle size out of SPA like apps, you really need to put in work. Maybe a simple Laravel/RubyOnRails website would have been the better stack for a lot of projects which are right now written in reactjs/nextjs.
> Therefore, we've elected to render our application completely on the client. On Next.js this means that we wrap our React app in a "client-side only" component that looks like this: > > This component only allows our React code to render inside the browser environment, minimizing Next.js' server-side render runtime. Yep, sounds like a practical way to do what is literally the default. So does the 4 paragraphs of cl…
I probably should’ve titled this post better, since I’ve been wanting to write more about how to make appropriate front end tooling decisions in general... not just our extremely dynamic use-case. The entire web seems to be running bloated React apps despite most sites’ needs being solved by the old stuff or new things like 11ty.
Just to clarify as well (since I didn’t in the post), we’re still using Next despite nuking the SSR because the filesystem-based server is useful to us and we like the patterns they provide for running server-side code.
Throwing errors to be caught higher up, the way they manage redirects, and the lack of discussion around managing state (which could on its own solve lots of these problems).
So much of this seems convoluted and unnecessary for a very simple goal of building a dashboard. Their use of Apollo seems to provide no advantage over a basic REST API.
There's frankly very little discussion about actual front end architecture. I'd expect a conversation on a React application architecture to focus on things like how is client side state managed? How is server state managed and kept up to date? Are the two mingled together or kept separate? How are they kept separate? How can you build reusable components? How can you avoid components bloating in size and scope etc
Front End development today - especially with React - is so easy to get running with and there are tons of better articles that actually discuss front end architecture including lots of courses on common patterns. Beyond articles, open source projects themselves often provide great architecture discussions.
Higher order components, react-query for server state, react-router for client side routing, building reusable behaviors with hooks are all good places to get started for actual architectural design
Been interviewing for a few roles lately and finding the new “react dev” eerily similar to those relying on jQuery back in the day. I ask vanilla js and low level layout/styling questions in my interviews (not gotcha questions, but instead what I consider to be fundamental skills indicative of experience) and am consistently met with confusion. Maybe I’m too old for this game and front end devs will never again need…
Just wait till HTML is rediscovered. "Hey, look, my content page is 2KB instead of 8MB"
HTML was never gone :) I have and still working on big e-commerce websites.
For example, Ikea for product lists sends mini chunks of simple HTML. No JS involved.
What I see is the problem that people think that "Frontend development is easier than backend development".
For me, they have different challenges and different ways of thinking. Getting a good full stack developer is kind of getting a good doctor, which has at least to specialities.
Hey all, as someone ignorant to this whole SSR/Next.js stuff: I understand that Next.js is particularly popular for creating landing pages that require strong SEO. What I don't understand is, in what way is it better than say, using something like HUGO or Jekyll? If you require some dynamic content, wouldn't it be easier (and faster to build) to use a SSG and ship the JS along with all the other static assets? What a…
That gur feeling like you are missing something important is nothing more than psuedo FOMO. Its complicated and contrived for no good reason at all. SSG are good. Plain HTML is even better.
> Therefore, we've elected to render our application completely on the client. On Next.js this means that we wrap our React app in a "client-side only" component that looks like this: > > This component only allows our React code to render inside the browser environment, minimizing Next.js' server-side render runtime. Yep, sounds like a practical way to do what is literally the default. So does the 4 paragraphs of cl…
I was excited about this post, saw the stack, and noped out of there. I was hoping for a really simple approach but this ain’t it.