0

On my team I'm working as a frontend developer in a React codebase. We're building an application and do everything in React. Before this I was actually always a backend developer. Now I have the feeling that in most "backend" frameworks it's quicker to just generate a view with a template engine instead of connecting everything through REST api's.

So I started thinking about an alternative approach to write React, because I have the feeling I'm way slower writing in javascript only. But I still want to keep the advantage dynamic components.

The ReactDOM.render method is the part that connects the dom with the component.

I would still render serverside most stuff and the dynamic stuff I would build into components and then render them with the ReactDom.render method.

By doing this I still keep the development speed of building/generating pages on the backend while I get the advantage of the React stack to build sophisticated dynamic components.

This method could even be possible for front end projects only. If you build your site statically (layout, pages, static content, ...) and then the dynamic content API stuff you just do in React.

So what do you people think? What are the (dis)advantages of this approach? And would it be more efficient?

I'm assuming that the team members were I would implement this strategy are both knowledgeable of the backend and the frontend.

  • 1
    What's the problem here? Is it your feeling of being slower developing or a non-mentioned issue of performance in the rendering of the client application? In any case, It depends on the needs and the requirements. Functional and non-functional. – Laiv Sep 16 '17 at 20:14
  • The problem here is that development speed is slower doing everything via an API, instead of some hybrid model where you can get the advantages of both ways. I'm searching for things I overlooked and maybe a good setup for these kind of projects. – Vince V. Sep 16 '17 at 20:17
  • Have you thought about using React with Typescript instead of Javascript? – Robert Harvey Sep 16 '17 at 20:32
  • @RobertHarvey How would that make a difference? (I'm just curious, I just don't know :) ) – Vince V. Sep 16 '17 at 20:35
  • 1
    Maybe the problem is the tool. Maybe React doesn't provides your team with the resources required for you to be productive. Or It could be the whole development environment. Or the skills of the team. In any case, both modalities of development (or application design) are not exempt of trade-offs. Find out what make you slower. Look for those things that can be enhanced and replaced, but ultimatelly, the application design depends only on the requirements. Choosing a wrong design based on false assumptions can lead you to situations worse than the actual one. – Laiv Sep 16 '17 at 20:57
1

I think you have a wrong conception of how React is supposed to work.

I'll start saying that your idea is completely valid and for some kind of use cases it can be a successful approach. If your web page is mostly static content and you just need few interactable components, if you need an high performant website on first render or if you are upgrading a legacy app, your idea makes a lot of sense.

Returning to my first statement, React components don't have to be connected through a REST API. Most of the React apps out there will have a few requests used at top of the main pages of the application, and the data passed down to the components that form the page.

Actually, binding a REST API to a component is considered an anti pattern, because it prevents the component from being reused in different contexts.

An approach used as alternative is to have a central store (usually Redux) and some wrapper components, called containers, that take care to read part of the state from Redux and pass it to the wrapped component. This is known as Flux approach.

Consider that lot of people use React to render static pages (no backend API at all) and even to render content on the backend to provide the markup via HTTP.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.