4 ms·
Without any input from me and several other js devs in our org, it was decided that we'll do a complete rewrite of our Ember.js app in React. The primary reaso
by Mc_Big_G 8y ago
Without any input from me and several other js devs in our org, it was decided that we'll do a complete rewrite of our Ember.js app in React. The primary reason stated was hiring and the secondary was build times. The first should have been performance but they've been pretending like performance doesn't matter and that it's good enough. It's not.
Since it's easier to develop, our backend admin system is built in .NET's MVC framework and it's lightning fast compared to our frontend. Like ridiculously fast. I'm not currently a backend dev but I have extensive experience with Rails and I've seen the same with Rails. It's fast.
Despite the fact that I'm a front-end dev and it's not in my best interest, my un-requested recommendation was to do the rewrite in MVC, thus delivering everything from the server side. Here are my stated reasons:
• The site will load and responds incredibly fast
• The "build time" problem disappears
• The "hiring a lot of specialized javascript developers" problem disappears
• Backend devs suddenly become full-stack devs
• Deploying is easier
• Testing, both automated and manual, is easier
• SEO is easier
• You can now hire junior developers who are productive and don't create a mess in a new js framework
• It's going to be supported for a long time, unlike the latest javascript-framework-of-the-day
• Our website is a website full of mostly content and CRUD forms, not an app.
We actually have very little "highly interactive" parts of our site and those that we do have can be a light-weight framework or simply a sprinkling of javascript. It should have never been an app in the first place.
If everything had been build in Rails from the beginning, instead of .NET and Ember, we would have been twice as productive with half as many developers and wouldn't need QA at all if we wrote tests.
This opinion was basically scoffed at with no valid counter-arguments given. They will move forward with a complete rewrite in React, which will solve none of their problems, except MAYBE hiring, and likely create more. They'll also probably do it without me. I'm not against SPAs or React when used for the correct reasons, especially considering I've been focused on front-end for the last 5 years, but I am vehemently opposed to bad decision making.
- zdragnar 8y ago"We actually have very little "highly interactive" parts of our site" That should have been your determining factor as to whether or not a SPA was appropriate. We've had the opposite experience; our new react SPA is noticibly faster than our current rails site, but it is due to the nature of the pages, not "X is always Y compared to Z"
- korm 8y agoI think if the conversion is led by a very experienced React developer this could be a good decision. We decided to write all our sites in React a long time ago and couldn't be happier. It doesn't have to be a SPA because it's React, we have static sites too. Judging by how your org made the decision without the devs input though, I'm not too confident it won't be disaster. It's depressing but I've been offered too many contracting opportunities to rescue a project after a similar conversion that is a total dumpster fire.
- Mc_Big_G 8y agoNo one on the team has ever used React.
- manquer 8y ago>> Backend devs suddenly become full-stack devs this is the reason we moved in the other direction, in my limited experience, people would should really backend devs doing frontend work because you framework/ arch is full stack and requires it, has been terrible
- acdha 8y ago> wouldn't need QA at all if we wrote tests. If this is true, you’ve been doing QA wrong. A good QA team will catch gaps in the developers’ thinking, not just click buttons like robots.
- vmware513 8y agoWhy you had to rewrite Ember.js to React? Ember.js is fast, modern and easy to work with. The Ember ecosystem is matured and reliable. It doesn't really make sense.
- lauritzsh 8y agoOP said the primary reason was hiring -- "The primary reason stated was hiring and the secondary was build times."