5 ms·

Not a main factor but a factor is 'always the latest tech' issue. Most banks and airlines I use rewrote their perfectly fine and fast sites and apps to reactjs

Not a main factor but a factor is 'always the latest tech' issue. Most banks and airlines I use rewrote their perfectly fine and fast sites and apps to reactjs and now they seriously suck. This is not the fault of react but more of this idea of tech people that everything has to be new which means we don't have 10+ year experience in it and the results just take more work to get right (despite what everyone says here). My local bank did a rewrite from php with js/jquery to react and it's just unusable now. Slow, buggy etc; I have to have my developer console open to see if a transaction actually worked... The site before this was instant loading and perfect; it was over 10 years old and worked fine. The new one doesn't look much better but is garbage. HSBC HK did something similar and the result is awful. I click things and see the console light up red with errors 'undefined' etc. Revolut business has more bugs (which I keep reporting but they don't fix them). And I know how to use developer tools; what do other people do when they click something over and over and nothing happens? Etc etc. Use tools you have experience with ; you don't need to use all this new crap; use it in 10-15 years if it is still around. Edit; in the same vain: microservices etc are not helping either. When done well they are supposed to help, but in reality I only see systems that can work when all microservices are up and responsive; if one is down, the entire thing is dead. Why didn't you make a monolith? Now you have brittle all over the place and devops with 247 stress.

kgeist 5y ago
>Most banks and airlines I use rewrote their perfectly fine and fast sites and apps to reactjs and now they seriously suck. This is not the fault of react but more of this idea of tech people that everything has to be new. I doubt they rewrote it just for the sake of rewriting it in a new framework, it costs money for no benefit. What's more likely, which I have witnessed multiple times, is that the original codebase was an unmantainable mess, hard to support and extend, with abandoned/unmaintained third-party dependencies, and fewer and fewer developers on the market who know the stack. Sometimes it costs as much (or even less) to rewrite the whole thing than to refactor the original. And when the decision to rewrite the codebase is made, they choose the most popular tools/frameworks so that it was easier to find new developers, and today it happens to be react and the like.
- JKCalhoun 5y ago
  Why does it seem (I'm not a backend engineer) that a company moves off of one technical-debt ridden backend to another, even bigger, more complex framework for their backend. It's like we're in a downward tech-debt spiral. Is it going to take an Ever-Given-like or Covid-like disruption of e-commerce that shuts down society to cause us to wake up and take this seriously? (Or have government step in and set standards and requirements for e-commerce.)
  - nicoburns 5y ago
    Presumably because they didn't fix the organisational issues that caused the first codebase to become a mess. If they had those sorted then they could most likely have stuck with the original codebase AND a rewrite would likely be succesful.
  - deleted 5y ago
    [deleted]
- tluyben2 5y ago
  I really do not think so; the places I saw, just go from crap to crap because tech leads/new ctos need to put their mark on things. I consulted for clients in the past years who were told to dump react (in 1m$+ apps) for svelte because react is yesterday. That is insane. One of the larger insurers is doing this now; I told them not to because it makes no sense. But they drank the koolaid and doing react to svelte rewrites for no reason besides a new cto. The churn in companies is high and it is not good.
- stjohnswarts 5y ago
  None of that matters to the customer if the new interface is completely different and much less functional. You should make sure there is an easy transition or you're going to lose a lot of business with your "improved interface".
sergiomattei 5y ago
> Most banks and airlines I use rewrote their perfectly fine and fast sites and apps to reactjs and now they seriously suck. Nostalgia might be staining your view here… I don’t remember any airline or banking apps that have ever been “perfectly fine and fast”.
- projektfu 5y ago
  FWIW, Dollar Bank had one of the earlier web banking sites and it was perfectly serviceable. I often wondered why larger banks couldn't do it as well. ING Direct (before it became CapitalOne 360) was pretty handy too, and while the CapitalOne site is slower and more SPA-like, it mostly does what I expect. American Express, on the other hand, is the real WTF.
- wott 5y ago
  I never had a problem with the website of my Finnish bank 20 years ago. And I could order my plane tickets too through the Web in the first half of the 2000s. I cannot say the same of the website of my French bank and its multiple rewrite over the last 8 years, which still provides less features and make them harder to reach each time. Or the website of the national lottery and its countless rewrites, each of them getting slower, more inconsistent, and displaying less information on each screen. Or the website of the national weather forecast, which gets worse at each iteration: now there's a 'weekly' view that shows 5 days; and I cannot for the love of God find the curves of snow and other parameters from the automated altitude weather stations any more (at each iteration, they have become harder to find, but with last iteration there is no access any more; someone's got direct links to the pictures URL on a website, but for how long?). Each time they make an update, the site is completely broken for days or weeks, before they sort out their crap and return the new shit to a more functional state. Or the website where I did put my bicycle recordings for years without a problem and without feeling the need for any extra feature, which all of a sudden cannot be displayed any more by my old browser. In all those cases (except the last, which is probably more recent), the needed features have been implemented for at least 15 years. They were working 15 years ago. Yet they got rewritten multiple times, and not for the best. Oh yeah, sorry, for the weather forecast website (which is a public service belonging to the legal type which is the most integrated with the State), there is a new feature added at each iteration: more advertisement, and now more tracking too! The site has become unbrowsable without and ad blocker. And BTW now, I am met more and more often with the infamous "your browser is not compatible with this site, please update to Chrome / Edge / ..." messages. I thought this kind of things were dead and buried. They were dead and buried, for 10 or 15 years, but now dreadful times are starting again and they rise from their grave.
kgeist 5y ago
>When done well they are supposed to help, but in reality I only see systems that can work when all microservices are up and responsive; if one is down, the entire thing is dead. Why didn't you make a monolith? There are different kinds of microservices, some are infrastructure critical (for example, we have an auth service, if it goes down the whole thing goes down because users simply can't login anymore - and it doesn't matter if it's a microservice or a monolith, the end result is same), others are not so critical, for example we implement additional product modules (purchased separately) as microservices which have their own SPAs so if they go down basically only one page becomes unavailable and the system as a whole is unaffected. Microservices aren't necessarily about 100% SLA, they help scale teams and deployment (however I'd say it only makes sense in larger organizations).
robertlagrant 5y ago
> microservices etc are not helping either. When done well they are supposed to help, but in reality I only see systems that can work when all microservices are up and responsive; if one is down, the entire thing is dead. Why didn't you make a monolith? Now you have brittle all over the place and devops with 247 stress. You could make a monolith where the UI keeps working even if some of the monolith's endpoints don't work, and you can make a microservices architecture where the UI still doesn't cope if a microservice is down. I think the pros of microservices are: - deploy smaller - you only update the parts of the system you need to when you modify something. - different technologies - you can use Ruby here and Go there if you like; very un-locked-in and you can maximise the value of any libraries you have. E.g. if you have a number crunching bit of your app you could make a Python microservice with numpy etc installed. - independent data stores - pro and con, of course, but it's nice if you can decouple bits of your system and again use mongo here, postgres there if you need to - as an microservices-based application grows in scope, the number of engineers working on different bits of it can scale, as they can deliver independently. It's harder to scale engineers working on the same codebase
deepstack 5y ago
> Not a main factor but a factor is 'always the latest tech' issue. Most banks and airlines I use rewrote their perfectly fine and fast sites and apps to reactjs and now they seriously suck. overusage of SPA of SPA framework (Next.js etc) has caused a lot of problem for users who are used using browser, which is most of web users. It breaks open the link in another tab, back/forward flow. It is not SPA is bad, however if you chose to go that route then design the app with screen size mind and you got think it as an Application instead of a web page.
- shmatt 5y ago
  From my experience its CTO/CIO's wanting better more stable and fest tech, but not willing to pay for good engineers Next.js is amazing, and it could make any airline/bank website blazing fast. Are said banks hiring the same devs from Google that are building the newer version of Next? Nope, they're hiring 3rd party companies in Romania. React et al is far from plug and play. Quality of implementation means a lot more than it used to in terms of performance
iso1210 5y ago
I logged into British Gas yesterday to look at my account. It was painfully slow, wouldn't even load before I disabled ublock origin, and cpu shot up. All to output something along the lines of "select * from meter_readings where accountid = ?", $accountid "select * from bills where accountid = ?", $accountid In the end I never actually got what I wanted.
- stjohnswarts 5y ago
  My water bill page is the most over designed thing I've ever seen :( . It takes over 30 seconds to load with all these obviously widget based sections of the page to load. All I want is to log in and see my bill. I don't need to see the community water usage, or my usage for the last 6 months, or the weather for the next three days. I just want to see my bill and pay it. Have a button I can click for further details and load the rest of their stuff if something seems off. I don't need a "single page web app" to do that stuff.
commandlinefan 5y ago
> always the latest tech' issue ... rewrote their perfectly fine and fast sites and apps to reactjs ... we don't have 10+ year experience React was open sourced in 2013. It's not that "new" - there are plenty of people who've been using it for 7+ years now. > did a rewrite from php with js/jquery to react The problem isn't the rewrite from php to react (or any x to any y), but the management saying "ok, we need to rewrite this thing in 'y'. You have two days to learn it. And you'd better show 40 productive hours of work on your timesheets in the meanwhile."
- tluyben2 5y ago
  Sure, but when we have tech 20 years old we can assume you don't need two days to learn it. 7 years is not that young but it changes way, way too fast. So the react 7 years ago is not the same as today: hell I have nodejs and react stuff that simply doesn't work anymore and is only a few years old. While php/html/css/jquery code written 15+ years ago is fast and robust on the very latest versions. I updated one of my oldest saas app written 17 years ago to the latest php version from apache to nginx and the latest php and it works 100%. That makes me sleep well at night. It has 60000 active users and costs $4/mo to host and has not had downtime in over 10 years. How is this new stuff holding up?
- denton-scratch 5y ago
  > using it for 7+ years That's not really very long, IMO. There's a huge amount of churn in programming systems these days. Once upon a time, writing compilers and designing languages was something that nerds did for fun and instruction, in their spare time. People didn't get paid to write compilers. Incidentally, I've never heard of "svelte".
stjohnswarts 5y ago
This happened to me recently :( . My community bank upgraded their interface (probably been basically the same for 10 years+) that they've been using just fine and moved EVERYTHING around with their new app and web interface that is made to look like their app. I was so angry I switched banks (which is easier than you think these days). I sent them a letter letting them know the same. It looked "better" but is was also slower, less organized, broke their API for downloading stuff to import to gnucash, etc. It's all just such a waste.

kgeist 5y ago

>Most banks and airlines I use rewrote their perfectly fine and fast sites and apps to reactjs and now they seriously suck. This is not the fault of react but more of this idea of tech people that everything has to be new. I doubt they rewrote it just for the sake of rewriting it in a new framework, it costs money for no benefit. What's more likely, which I have witnessed multiple times, is that the original codebase was an unmantainable mess, hard to support and extend, with abandoned/unmaintained third-party dependencies, and fewer and fewer developers on the market who know the stack. Sometimes it costs as much (or even less) to rewrite the whole thing than to refactor the original. And when the decision to rewrite the codebase is made, they choose the most popular tools/frameworks so that it was easier to find new developers, and today it happens to be react and the like.

JKCalhoun 5y ago
Why does it seem (I'm not a backend engineer) that a company moves off of one technical-debt ridden backend to another, even bigger, more complex framework for their backend. It's like we're in a downward tech-debt spiral. Is it going to take an Ever-Given-like or Covid-like disruption of e-commerce that shuts down society to cause us to wake up and take this seriously? (Or have government step in and set standards and requirements for e-commerce.)
- nicoburns 5y ago
  Presumably because they didn't fix the organisational issues that caused the first codebase to become a mess. If they had those sorted then they could most likely have stuck with the original codebase AND a rewrite would likely be succesful.
- deleted 5y ago
  [deleted]
tluyben2 5y ago
I really do not think so; the places I saw, just go from crap to crap because tech leads/new ctos need to put their mark on things. I consulted for clients in the past years who were told to dump react (in 1m$+ apps) for svelte because react is yesterday. That is insane. One of the larger insurers is doing this now; I told them not to because it makes no sense. But they drank the koolaid and doing react to svelte rewrites for no reason besides a new cto. The churn in companies is high and it is not good.
stjohnswarts 5y ago
None of that matters to the customer if the new interface is completely different and much less functional. You should make sure there is an easy transition or you're going to lose a lot of business with your "improved interface".

sergiomattei 5y ago

> Most banks and airlines I use rewrote their perfectly fine and fast sites and apps to reactjs and now they seriously suck. Nostalgia might be staining your view here… I don’t remember any airline or banking apps that have ever been “perfectly fine and fast”.

projektfu 5y ago
FWIW, Dollar Bank had one of the earlier web banking sites and it was perfectly serviceable. I often wondered why larger banks couldn't do it as well. ING Direct (before it became CapitalOne 360) was pretty handy too, and while the CapitalOne site is slower and more SPA-like, it mostly does what I expect. American Express, on the other hand, is the real WTF.
wott 5y ago
I never had a problem with the website of my Finnish bank 20 years ago. And I could order my plane tickets too through the Web in the first half of the 2000s. I cannot say the same of the website of my French bank and its multiple rewrite over the last 8 years, which still provides less features and make them harder to reach each time. Or the website of the national lottery and its countless rewrites, each of them getting slower, more inconsistent, and displaying less information on each screen. Or the website of the national weather forecast, which gets worse at each iteration: now there's a 'weekly' view that shows 5 days; and I cannot for the love of God find the curves of snow and other parameters from the automated altitude weather stations any more (at each iteration, they have become harder to find, but with last iteration there is no access any more; someone's got direct links to the pictures URL on a website, but for how long?). Each time they make an update, the site is completely broken for days or weeks, before they sort out their crap and return the new shit to a more functional state. Or the website where I did put my bicycle recordings for years without a problem and without feeling the need for any extra feature, which all of a sudden cannot be displayed any more by my old browser. In all those cases (except the last, which is probably more recent), the needed features have been implemented for at least 15 years. They were working 15 years ago. Yet they got rewritten multiple times, and not for the best. Oh yeah, sorry, for the weather forecast website (which is a public service belonging to the legal type which is the most integrated with the State), there is a new feature added at each iteration: more advertisement, and now more tracking too! The site has become unbrowsable without and ad blocker. And BTW now, I am met more and more often with the infamous "your browser is not compatible with this site, please update to Chrome / Edge / ..." messages. I thought this kind of things were dead and buried. They were dead and buried, for 10 or 15 years, but now dreadful times are starting again and they rise from their grave.

kgeist 5y ago

>When done well they are supposed to help, but in reality I only see systems that can work when all microservices are up and responsive; if one is down, the entire thing is dead. Why didn't you make a monolith? There are different kinds of microservices, some are infrastructure critical (for example, we have an auth service, if it goes down the whole thing goes down because users simply can't login anymore - and it doesn't matter if it's a microservice or a monolith, the end result is same), others are not so critical, for example we implement additional product modules (purchased separately) as microservices which have their own SPAs so if they go down basically only one page becomes unavailable and the system as a whole is unaffected. Microservices aren't necessarily about 100% SLA, they help scale teams and deployment (however I'd say it only makes sense in larger organizations).

robertlagrant 5y ago

> microservices etc are not helping either. When done well they are supposed to help, but in reality I only see systems that can work when all microservices are up and responsive; if one is down, the entire thing is dead. Why didn't you make a monolith? Now you have brittle all over the place and devops with 247 stress. You could make a monolith where the UI keeps working even if some of the monolith's endpoints don't work, and you can make a microservices architecture where the UI still doesn't cope if a microservice is down. I think the pros of microservices are: - deploy smaller - you only update the parts of the system you need to when you modify something. - different technologies - you can use Ruby here and Go there if you like; very un-locked-in and you can maximise the value of any libraries you have. E.g. if you have a number crunching bit of your app you could make a Python microservice with numpy etc installed. - independent data stores - pro and con, of course, but it's nice if you can decouple bits of your system and again use mongo here, postgres there if you need to - as an microservices-based application grows in scope, the number of engineers working on different bits of it can scale, as they can deliver independently. It's harder to scale engineers working on the same codebase

deepstack 5y ago

> Not a main factor but a factor is 'always the latest tech' issue. Most banks and airlines I use rewrote their perfectly fine and fast sites and apps to reactjs and now they seriously suck. overusage of SPA of SPA framework (Next.js etc) has caused a lot of problem for users who are used using browser, which is most of web users. It breaks open the link in another tab, back/forward flow. It is not SPA is bad, however if you chose to go that route then design the app with screen size mind and you got think it as an Application instead of a web page.

shmatt 5y ago
From my experience its CTO/CIO's wanting better more stable and fest tech, but not willing to pay for good engineers Next.js is amazing, and it could make any airline/bank website blazing fast. Are said banks hiring the same devs from Google that are building the newer version of Next? Nope, they're hiring 3rd party companies in Romania. React et al is far from plug and play. Quality of implementation means a lot more than it used to in terms of performance

iso1210 5y ago

I logged into British Gas yesterday to look at my account. It was painfully slow, wouldn't even load before I disabled ublock origin, and cpu shot up. All to output something along the lines of "select * from meter_readings where accountid = ?", $accountid "select * from bills where accountid = ?", $accountid In the end I never actually got what I wanted.

stjohnswarts 5y ago
My water bill page is the most over designed thing I've ever seen :( . It takes over 30 seconds to load with all these obviously widget based sections of the page to load. All I want is to log in and see my bill. I don't need to see the community water usage, or my usage for the last 6 months, or the weather for the next three days. I just want to see my bill and pay it. Have a button I can click for further details and load the rest of their stuff if something seems off. I don't need a "single page web app" to do that stuff.

commandlinefan 5y ago

> always the latest tech' issue ... rewrote their perfectly fine and fast sites and apps to reactjs ... we don't have 10+ year experience React was open sourced in 2013. It's not that "new" - there are plenty of people who've been using it for 7+ years now. > did a rewrite from php with js/jquery to react The problem isn't the rewrite from php to react (or any x to any y), but the management saying "ok, we need to rewrite this thing in 'y'. You have two days to learn it. And you'd better show 40 productive hours of work on your timesheets in the meanwhile."

tluyben2 5y ago
Sure, but when we have tech 20 years old we can assume you don't need two days to learn it. 7 years is not that young but it changes way, way too fast. So the react 7 years ago is not the same as today: hell I have nodejs and react stuff that simply doesn't work anymore and is only a few years old. While php/html/css/jquery code written 15+ years ago is fast and robust on the very latest versions. I updated one of my oldest saas app written 17 years ago to the latest php version from apache to nginx and the latest php and it works 100%. That makes me sleep well at night. It has 60000 active users and costs $4/mo to host and has not had downtime in over 10 years. How is this new stuff holding up?
denton-scratch 5y ago
> using it for 7+ years That's not really very long, IMO. There's a huge amount of churn in programming systems these days. Once upon a time, writing compilers and designing languages was something that nerds did for fun and instruction, in their spare time. People didn't get paid to write compilers. Incidentally, I've never heard of "svelte".

stjohnswarts 5y ago

This happened to me recently :( . My community bank upgraded their interface (probably been basically the same for 10 years+) that they've been using just fine and moved EVERYTHING around with their new app and web interface that is made to look like their app. I was so angry I switched banks (which is easier than you think these days). I sent them a letter letting them know the same. It looked "better" but is was also slower, less organized, broke their API for downloading stuff to import to gnucash, etc. It's all just such a waste.