Above all our commitment and priority are the customer and their happiness. It’s okay if there’s large, critical parts of the application in Backbone now, months and perhaps even a year or two in the future.
This is to avoid scope creep and ensure we can release updates with confidence in timelines and process the way data travels to and from the backend shouldn’t change, so the risk can be minimised. Frontend-only – While not ideal, the work to replace Backbone and ERB templates with React should not affect the backend.There is no clear line or requirements which dictate if something would be updated to React, but it’s always treated as an important discussion. If a part of the old frontend needed some copy or colour changes, a link added etc. If an existing feature was changing drastically or was getting extended with new responsibilities, a rewrite was obvious. As required – There are two general objectives at play here, modernise the codebase and improve product development time.
#Backbone js vs react code#
We would need to be able to write new features in React, but also rewrite old features to React without letting the new code affect existing implementations and making rewrites lengthy. The general premise is you write a new system around an old one until it’s that prominent that the old implementation is strangulated. Piecemeal – This is sometimes referred to as the Strangler Pattern.After a lengthy analysis about the technical implementation of moving from Backbone and Embedded Ruby (ERB) to React, we decided to bite the bullet with a few hard rules: The above is to say we didn’t take the investigation lightly, as “rewrite” horror stories are very common, and as a team, we’d be burnt by something very similar before. That said, the ‘do what I do’ mentality is something I want to be proud of, and looking at the codebase as an example of implementation is something I want all of our developers to do. It’s a fine line, perhaps sometimes it was wrong, but largely it comes down to a business decision.
We have a “junior” developer in the team, and our codebase has suffered a well-known fate – in a race to profitability and customer happiness, code quality can be sacrificed. Growth – We want a culture which encourages learning.If we’re investing time in improving Backbone views, we could hypothetically implement something like React in a similar time. Simplicity – If you’ve ever used Backbone, you know why React is good, and therefore know why our views can be very complicated.We will prevent domain knowledge as much as possible, but having a modern codebase that’s easy to digest could be just as important. It can be re-learnt, but often in a 9-year-old codebase that’s riddled with complications, it’s costly and can be off-putting. Onboarding Developers – Like other small SaaS companies, it’s common for long-standing employees to end up with domain knowledge, and when they go, the knowledge goes too.Growing the team – There are more React devs for hire (in Melbourne, Australia) I mention Backbone and the reaction is mostly familiarity with the name, not the library itself – let alone a desire to work with it.However, it became apparent we needed to start thinking about updating the technical implementation of the front-end, because:
Over that time, it’s been relatively easy to ignore new technology in favour of stability (and there was a period of inactive development). This.$el.html(" If you see that it's working") Ĭlass TestComponent extends React.BugHerd has survived for nine years as a successful SaaS product built using Backbone, jQuery and Rails. In a similar way I've done in sample project: import React from 'react' My initial idea is to wrap this backbone view in a react component.
#Backbone js vs react how to#
I am very uncertain how to approach this. I have backbone control that I want to reuse in new module that would be written in React and Redux.
0 kommentar(er)
