10 ms·

I've always felt this problem from the first time I touched Angular. It was just so much more complex and fragile without actually a lot of benefit unless you w

by cateye 6y ago

I've always felt this problem from the first time I touched Angular. It was just so much more complex and fragile without actually a lot of benefit unless you wanted to make a really interactive async application like Google Docs or Facebook Chat. When SPA's became the norm and even static web pages needed to be build with React, developing became more and more inefficient. I saw whole teams struggling to build simple applications and wasting months of time, while these used to be developed within a couple of weeks with just 1 or 2 developers, on proven server side opinioated frameworks. But that was no longer according to best practices and industry standards. Everything needed to be SPA, micro services, distributed databases, Kubernetes etc. These components and layers needed to be glued together by trial and error. I am really happy that common sense is starting to return and more developers are starting to realize that integrated end to end frameworks are very useful for a lot of real life application development scenario's.

throw_m239339 6y ago
> I've always felt this problem from the first time I touched Angular. It was just so much more complex and fragile without actually a lot of benefit unless you wanted to make a really interactive async application like Google Docs or Facebook Chat. It sounds crazy to say that now but Angular became big because it was actually quite lightweight compared to other JS frameworks of this era, declarative 2 way databinding was cool, it was compatible with jQuery (thus its widget ecosystem) and it was also developed with testing in mind. So it was easy to move jQuery projects to Angular ones, and developers cared about this aspect and it helped organize code quite a bit. Angular 2 on the other hand never made sense and it was a solution looking for problem. React and JSX came along and allowed developers to use JS classes when a lot of browsers didn't support them. And unidirectional dataflow was all at rage. It was always the right solution of course, but I never heard about DOM diffing before that which to me is the main appeal to React. To this date, HTML API still do not have a native(thus efficient) DOM diffing API which is a shame. > When SPA's became the norm and even static web pages needed to be build with React, developing became more and more inefficient. I saw whole teams struggling to build simple applications and wasting months of time, while these used to be developed within a couple of weeks with just 1 or 2 developers, on proven server side opinionated frameworks. But that was no longer according to best practices and industry standards. Everything needed to be SPA, micro services, distributed databases, Kubernetes etc. These components and layers needed to be glued together by trial and error. IMHO the problem isn't React and co or even SPA. In fact writing an REST/Web API should be easier than writing a server-side generated HTML website (no need for templating language, ugly form frameworks,...). The problem is the horrible and complex NodeJS/NPM backed asset compilation pipelines and build tools that these framework often require in a professional setting, which incur a lot of complexity for very little gain.
- Scarbutt 6y ago
  In fact writing an REST/Web API should be easier than writing a server-side generated HTML website (no need for templating language, ugly form frameworks,...). Why is that easier? It's more work, you are now rendering two views instead of one, a JSON one(server) and HTML one(in the client) with all the JSON encoding/decoding that it entails. You are still using a templating language and, dealing with forms in React is more cumbersome than doing it server-side.
  - IggleSniggle 6y ago
    To be fair, they only said writing an API should be easier than writing a server-rendered HTML form (1:1).
  - deleted 6y ago
    [deleted]
  - black3r 6y ago
    separation of concerns, easier testability, easier mocking..., the thing is especially in more complex applications the code that generates/validates the data and the code that displays them are usually written by two different people. nowadays once the json schema design is settled, they can work in parallel, each of them can test their parts without needing the other and the merges can be simpler, because the parts do work more or less stand-alone.
- kccqzy 6y ago
  > React and JSX came along and allowed developers to use JS classes Nitpick, but I doubt that was the reason developers are flocking to React back then. In the beginning browsers didn't support JavaScript classes and neither did React. You fake them by using a function known as React.createClass instead. There was also no transpilation required, as JSX was optional. In fact React was always about unidirectional data flow, and reasoning about state -> DOM elements rather than reasoning about changes to the DOM.
- mixmastamyk 6y ago
  > The problem is the horrible and complex NodeJS/NPM backed asset compilation pipelines and build tools Would like to hear more.
Nextgrid 6y ago
> Everything needed to be SPA, micro services, distributed databases, Kubernetes etc. These components and layers needed to be glued together by trial and error. This is a major problem with our industry. Unfortunately, the people with the power to curb this trend have their paycheck depend on it continuing. As a company, you are incentivised to have a large tech team to appear credible and raise funding, so you hire a CTO and maybe some engineering managers. Their career in turn benefits from managing large amounts of people and solving complex technical problems (even if self-inflicted), so they’ll hire 10x the amount of engineers the task at hands truly requires, organise them in separate teams and build an engineering playground that guarantees their employment and gives them talking points (for conferences or the seemingly-mandatory engineering blog or in interviews for their next role) about how they solve complex problems (self-inflicted, as a side-effect of an extremely complex stack with lots of moving parts). Developers themselves need to constantly keep up to date, so they won’t usually push back on having to use the latest frontend framework, and even if they do, that decision is out of their hands and they’ll just get replaced or not hired to begin with. In the end, AWS and the cloud providers are laughing all the way to the bank to collect their (already generous) profits, now even more inflated by having their clients use 10x the amount of compute power that the business problem would normally require. Maybe the issue is the seemingly-infinite amounts of money being invested into tech companies of dubious value, and the solution would be to get back to Earth as to have some financial pressure coming from up top that incentivises using the simplest solution to the problem at hand?
- cutler 6y ago
  This is the main reason I refuse to entertain going perm in the tech sector. The amount of superfluous infrastructure and unquestioned use of SPA's is just an overwhelming time sink. I would honestly rather work with some 2-bit company's legacy PHP than this mountain of crap.
  - TameAntelope 6y ago
    For what it's worth, once you are proficient in the full end-to-end, navigating it is pretty easy, IMHO. It just takes years and lots of room to do basically nothing, and if something meaningfully shifts, you need a while to get back up to speed. I'm not saying it's efficient, or that you should dive in, but I did want to throw out there that there is a light at the end of the tunnel. People using React.js aren't flailing about in the dark the whole time.
MattGaiser 6y ago
The problem that nobody knows whether something will become the next Google Docs. Transitioning to an SPA from something like jQuery is basically a complete rewrite. To be willing to not use an SPA, you need to be willing to exclude certain options from day 1. Find me a product manager willing to do that.
- Nextgrid 6y ago
  > nobody knows whether something will become the next Google Docs How many times has it actually happened that some scrappy startup has 1) became the next big thing and 2) not being at the edge of over-engineering actually killed it or significantly impacted its revenue? This just feels like wishful thinking. Also keep in mind that even if you were on track to become the next Google Docs, this means your current product is usually good enough as-is and gives you time (and $$$) to improve it.
  - Hasu 6y ago
    I'm not sure that using React or another JS framework counts as 'being at the edge of over-engineering'. I agree with the rest of your point - the value of the product to end-users has little to no correlation with the underlying technology choices, which is a pretty controversial statement, but one that I think is true. A customer doesn't care if you built it in React, in one Perl file, or if you're sacrificing goats to retain the minimum requisite levels of dark magic to keep the system running. If it solves their problem they'll keep giving you money for goats.
    - Nextgrid 6y ago
      It depends on what the objective is. I've seen plenty of project where React was used just to have it as a buzzword, but otherwise provided no functionality and actually slowed development down and ended up being less reliable (we had to - poorly - reimplement behaviors like validation, pagination, etc that our backend framework already had for free).
- fendy3002 6y ago
cutler 6y ago
Kubernetes is the biggest joke. I remember working with a sysadmin who worked for The Guardian provisioning servers remotely as demand spiked. This is pre-AWS. He used Puppet and remarked that you would only ever need what he was using for managing massive fleets of servers. Then Kubernetes and Docker arrived, which were intended for even bigger deployments in data centres. Before you knew it, just as with SPA's, Kubernetes and Docker became the new requirements for web devs working on simple apps.
- Nextgrid 6y ago
  Also never underestimate the power of a single bare-metal server. Today everyone seems to be in the clouds (pun intended) and has seemingly accepted the performance of terrible, underprovisioned VMs as the new normal.
  - wvenable 6y ago
    Stackoverflow -- the website that every developer uses probably all the time -- is an example of a site running on a very small number of machines efficiently. I'd rather have their architecture than 100's of VMs.
    - systemvoltage 6y ago
      It’s remarkably efficient and simple: https://stackexchange.com/performance https://stackexchange.com/performance For those who are discouraged by the massive complexity of Kubernetes/Terraform and various daunting system design examples of big sites, remember you can scale to a ridiculous levels (barring video or heavy processing apps) with just vertical scaling. Before you need fancy Instagram scale frameworks, you’ll have other things to worry about like appearing in front of congress for a testimony :-)
      - Nextgrid 6y ago
        This is indeed the standard example I refer to to prove my point, and all my personal projects follow this model whenever possible. The huge advantage in addition to performance is that the entire stack is simple enough to fit in your mind, unlike Kubernetes and its infinite amount of moving parts and failure modes.
switz 6y ago
> developing became more and more inefficient Anecdotally I find the opposite to be true. I've been writing frontend code for over a decade, but I've never moved faster and wrote less buggy code than now. Is that because I've become a better developer? Sure, a little bit. But by and large, I don't believe that ultimately is the reason. I think it's the maturity in the technology. My growth as a programmer is hardly linear and the past 5 years have not matched the growth I achieved in my first 5. Frontend tooling has never been better than it is today. What I believe, is that the bar to build web applications has been lowered, and there are more programmers than today than ever before. You have people who are not experts in frontend development and javascript trying to build complex UIs and applications. So you take this person who doesn't have the requisite experience and put them to work on a paradigm with a lot of depth (frontend) using frameworks that are really simple and easy to get started with, but compound problems as they are misused. Another factor is that since SPAs are stateful, complexity mounts aggressively. Instead of a refresh on a stateless page every few seconds, one page causes bugs that rear their head for the duration of the session. These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti. But when designed properly, these problems are largely negated. I'm not advocating that SPAs are the solution to all problems. I think there's gross overuse of SPAs across the industry, but that is not an indictment of SPAs themselves. That is someone choosing the wrong technology to solve the active problem. With respect to angular (1, I never touched 2) specifically, I always found it extremely overengineered, poorly designed, with terrible APIs. But that's a problem with that specific framework and says nothing at all about SPAs at all.
- Nextgrid 6y ago
  > Frontend tooling has never been better than it is today. What's the library or design pattern to consume a REST API in React or any of the mainstream front-end frameworks? The only thing I'm aware of is Ember Data but Ember is apparently not cool anymore, and I couldn't find a suitable replacement. I'm asking because in all the projects I've been involved with, consuming the backend API always felt like a mess with lots of reinventing the wheel (poorly) and duplication of code. I can't believe in 2020 there's not some kind of library I can call that will give me my backend resources as JSON and transparently handle all the caching, pagination, error handling (translate error responses to exceptions), etc and people have to do all this by hand when calling something like Axios. In contrast, Django REST Framework handles all that boilerplate for me and allows me to jump right into writing the business logic. It's insane that ~30 lines of code with DRF (https://www.django-rest-framework.org/#example https://www.django-rest-framework.org/#example) gives me a way to expose RESTful endpoints for a database model to the web with authentication, pagination, validation, filtering, etc in a reusable way (these are just Python classes after all) but the modern front-end doesn't have the client equivalent of this.
ehnto 6y ago
Everyone looks to the bigger companies for tech trends, not realising that they have none of the problems ultra scale companies are trying to solve.
laichzeit0 6y ago
I also wonder how much of the SPA trend by mega corps was about shifting compute “client side” to save money on infrastructure. It’s kinda like modern data warehouses where storage/compute is now so cheap you do ELT and not ETL anymore. I probably wouldn’t do an SPA today unless I really had to.
cs02rm0 6y ago
When SPA's became the norm and even static web pages needed to be build with React I'm in a weird situation where I'm contracting into one organisation and they've contracted me out to another. The first organisation know me as a senior dev/architect with 15 years experience in a niche domain. The second organisation see me as brand new to them and despite paying an embarrassing day rate are giving me noddy UI tweaks to do. Extracting myself is proving to be slow somehow. Anyway, they wanted a webapp with a couple of APIs and nothing on the page than a button, the authenticated username and a line of text. Clicking the button opts you in/out of a service and the text changes depending on the state. The sort of thing people go to once, maybe twice. I used a mustache template on the server side to populate the values and I didn't even bother with any javascript, just did an old school form submission to the API when the button was clicked and a redirect back to the page. It was tiny but, obviously it was decided "we should be using a more modern framework" - code for React. It was the more word that got to me, as if there was an equivalent, dated framework I'd used. I didn't put up a fight partly because I was new to the team and figured they were hot on React and I wasn't. Somehow, they made a complete hash of it, they couldn't even figure out how to get all their inline styles (the only styles they used) working without help. I guess it's just those classics; people want to learn the hot new thing as they see it, their managers are happy that they've heard a buzzword they recognise and then everything becomes a nail for their new hammer.
- onion2k 6y ago
  Every time that sort of thing has happened to me it's been because there's some grand plan to build out more features that the people on the frontline don't know about. The plan rarely materializes but the idea that the foundation should be built in a way that supports it isn't completely stupid.
  - zachrose 6y ago
    It’s not stupid, no, but a “supporting foundation” is a largely just a seductive metaphor. It says, “Clearly software is like a building. Every building needs a solid foundation.” It doesn’t inspire engagement with other metaphors, like considering software to be a tree that must be grown incrementally and as a product of dynamic forces. It doesn’t map knowledge from the building domain to knowledge in the software domain.
throwaway189262 6y ago
React isn't so bad. It's fairly straightforward and the components are contained within the page. And it's more of a library than a framework. The core is small and easy to learn Angular is a giant confusing pile of magic. It's so complex you've gotta be a core developer to even understand how an app comes together. Stay the hell away if you can
marcus_holmes 6y ago
I don't think it's developers tbh. Or rather, it's another set of perverse incentives in the industry. To get a job, devs need experience in relevant tech. No company is willing to train their devs - they all have to hit the ground running. So devs have to have demonstrable experience in the tech that lots of companies use. Companies need to hire devs, and don't really care what tech is used. But using what everyone else uses makes their hiring easier because it's easier to find devs who want to work on that tech. So they advertise for devs with experience in a hot tech. The devs see this and try and move their internal projects to use the hot tech so that if/when they look for their next job they'll have experirence in it. The devs are just trying to stay relevant in a rapidly changing tech scene so they can get their next job. The companies who employ them don't care what tech is used, but find recruiting devs to be easier if they're working in the latest hot tech. The key point that could change all this is if companies were willing to train their devs in the tech stack they're using.

by cateye 6y ago

throw_m239339 6y ago

> I've always felt this problem from the first time I touched Angular. It was just so much more complex and fragile without actually a lot of benefit unless you wanted to make a really interactive async application like Google Docs or Facebook Chat. It sounds crazy to say that now but Angular became big because it was actually quite lightweight compared to other JS frameworks of this era, declarative 2 way databinding was cool, it was compatible with jQuery (thus its widget ecosystem) and it was also developed with testing in mind. So it was easy to move jQuery projects to Angular ones, and developers cared about this aspect and it helped organize code quite a bit. Angular 2 on the other hand never made sense and it was a solution looking for problem. React and JSX came along and allowed developers to use JS classes when a lot of browsers didn't support them. And unidirectional dataflow was all at rage. It was always the right solution of course, but I never heard about DOM diffing before that which to me is the main appeal to React. To this date, HTML API still do not have a native(thus efficient) DOM diffing API which is a shame. > When SPA's became the norm and even static web pages needed to be build with React, developing became more and more inefficient. I saw whole teams struggling to build simple applications and wasting months of time, while these used to be developed within a couple of weeks with just 1 or 2 developers, on proven server side opinionated frameworks. But that was no longer according to best practices and industry standards. Everything needed to be SPA, micro services, distributed databases, Kubernetes etc. These components and layers needed to be glued together by trial and error. IMHO the problem isn't React and co or even SPA. In fact writing an REST/Web API should be easier than writing a server-side generated HTML website (no need for templating language, ugly form frameworks,...). The problem is the horrible and complex NodeJS/NPM backed asset compilation pipelines and build tools that these framework often require in a professional setting, which incur a lot of complexity for very little gain.

Scarbutt 6y ago
In fact writing an REST/Web API should be easier than writing a server-side generated HTML website (no need for templating language, ugly form frameworks,...). Why is that easier? It's more work, you are now rendering two views instead of one, a JSON one(server) and HTML one(in the client) with all the JSON encoding/decoding that it entails. You are still using a templating language and, dealing with forms in React is more cumbersome than doing it server-side.
- IggleSniggle 6y ago
  To be fair, they only said writing an API should be easier than writing a server-rendered HTML form (1:1).
- deleted 6y ago
  [deleted]
- black3r 6y ago
  separation of concerns, easier testability, easier mocking..., the thing is especially in more complex applications the code that generates/validates the data and the code that displays them are usually written by two different people. nowadays once the json schema design is settled, they can work in parallel, each of them can test their parts without needing the other and the merges can be simpler, because the parts do work more or less stand-alone.
kccqzy 6y ago
> React and JSX came along and allowed developers to use JS classes Nitpick, but I doubt that was the reason developers are flocking to React back then. In the beginning browsers didn't support JavaScript classes and neither did React. You fake them by using a function known as React.createClass instead. There was also no transpilation required, as JSX was optional. In fact React was always about unidirectional data flow, and reasoning about state -> DOM elements rather than reasoning about changes to the DOM.
mixmastamyk 6y ago
> The problem is the horrible and complex NodeJS/NPM backed asset compilation pipelines and build tools Would like to hear more.

Nextgrid 6y ago

> Everything needed to be SPA, micro services, distributed databases, Kubernetes etc. These components and layers needed to be glued together by trial and error. This is a major problem with our industry. Unfortunately, the people with the power to curb this trend have their paycheck depend on it continuing. As a company, you are incentivised to have a large tech team to appear credible and raise funding, so you hire a CTO and maybe some engineering managers. Their career in turn benefits from managing large amounts of people and solving complex technical problems (even if self-inflicted), so they’ll hire 10x the amount of engineers the task at hands truly requires, organise them in separate teams and build an engineering playground that guarantees their employment and gives them talking points (for conferences or the seemingly-mandatory engineering blog or in interviews for their next role) about how they solve complex problems (self-inflicted, as a side-effect of an extremely complex stack with lots of moving parts). Developers themselves need to constantly keep up to date, so they won’t usually push back on having to use the latest frontend framework, and even if they do, that decision is out of their hands and they’ll just get replaced or not hired to begin with. In the end, AWS and the cloud providers are laughing all the way to the bank to collect their (already generous) profits, now even more inflated by having their clients use 10x the amount of compute power that the business problem would normally require. Maybe the issue is the seemingly-infinite amounts of money being invested into tech companies of dubious value, and the solution would be to get back to Earth as to have some financial pressure coming from up top that incentivises using the simplest solution to the problem at hand?

cutler 6y ago
This is the main reason I refuse to entertain going perm in the tech sector. The amount of superfluous infrastructure and unquestioned use of SPA's is just an overwhelming time sink. I would honestly rather work with some 2-bit company's legacy PHP than this mountain of crap.
- TameAntelope 6y ago
  For what it's worth, once you are proficient in the full end-to-end, navigating it is pretty easy, IMHO. It just takes years and lots of room to do basically nothing, and if something meaningfully shifts, you need a while to get back up to speed. I'm not saying it's efficient, or that you should dive in, but I did want to throw out there that there is a light at the end of the tunnel. People using React.js aren't flailing about in the dark the whole time.

MattGaiser 6y ago

The problem that nobody knows whether something will become the next Google Docs. Transitioning to an SPA from something like jQuery is basically a complete rewrite. To be willing to not use an SPA, you need to be willing to exclude certain options from day 1. Find me a product manager willing to do that.

Nextgrid 6y ago
> nobody knows whether something will become the next Google Docs How many times has it actually happened that some scrappy startup has 1) became the next big thing and 2) not being at the edge of over-engineering actually killed it or significantly impacted its revenue? This just feels like wishful thinking. Also keep in mind that even if you were on track to become the next Google Docs, this means your current product is usually good enough as-is and gives you time (and $$$) to improve it.
- Hasu 6y ago
  I'm not sure that using React or another JS framework counts as 'being at the edge of over-engineering'. I agree with the rest of your point - the value of the product to end-users has little to no correlation with the underlying technology choices, which is a pretty controversial statement, but one that I think is true. A customer doesn't care if you built it in React, in one Perl file, or if you're sacrificing goats to retain the minimum requisite levels of dark magic to keep the system running. If it solves their problem they'll keep giving you money for goats.
  - Nextgrid 6y ago
    It depends on what the objective is. I've seen plenty of project where React was used just to have it as a buzzword, but otherwise provided no functionality and actually slowed development down and ended up being less reliable (we had to - poorly - reimplement behaviors like validation, pagination, etc that our backend framework already had for free).
fendy3002 6y ago

cutler 6y ago

Kubernetes is the biggest joke. I remember working with a sysadmin who worked for The Guardian provisioning servers remotely as demand spiked. This is pre-AWS. He used Puppet and remarked that you would only ever need what he was using for managing massive fleets of servers. Then Kubernetes and Docker arrived, which were intended for even bigger deployments in data centres. Before you knew it, just as with SPA's, Kubernetes and Docker became the new requirements for web devs working on simple apps.

Nextgrid 6y ago
Also never underestimate the power of a single bare-metal server. Today everyone seems to be in the clouds (pun intended) and has seemingly accepted the performance of terrible, underprovisioned VMs as the new normal.
- wvenable 6y ago
  Stackoverflow -- the website that every developer uses probably all the time -- is an example of a site running on a very small number of machines efficiently. I'd rather have their architecture than 100's of VMs.
  - systemvoltage 6y ago
    It’s remarkably efficient and simple: https://stackexchange.com/performance https://stackexchange.com/performance For those who are discouraged by the massive complexity of Kubernetes/Terraform and various daunting system design examples of big sites, remember you can scale to a ridiculous levels (barring video or heavy processing apps) with just vertical scaling. Before you need fancy Instagram scale frameworks, you’ll have other things to worry about like appearing in front of congress for a testimony :-)
    - Nextgrid 6y ago
      This is indeed the standard example I refer to to prove my point, and all my personal projects follow this model whenever possible. The huge advantage in addition to performance is that the entire stack is simple enough to fit in your mind, unlike Kubernetes and its infinite amount of moving parts and failure modes.

switz 6y ago

> developing became more and more inefficient Anecdotally I find the opposite to be true. I've been writing frontend code for over a decade, but I've never moved faster and wrote less buggy code than now. Is that because I've become a better developer? Sure, a little bit. But by and large, I don't believe that ultimately is the reason. I think it's the maturity in the technology. My growth as a programmer is hardly linear and the past 5 years have not matched the growth I achieved in my first 5. Frontend tooling has never been better than it is today. What I believe, is that the bar to build web applications has been lowered, and there are more programmers than today than ever before. You have people who are not experts in frontend development and javascript trying to build complex UIs and applications. So you take this person who doesn't have the requisite experience and put them to work on a paradigm with a lot of depth (frontend) using frameworks that are really simple and easy to get started with, but compound problems as they are misused. Another factor is that since SPAs are stateful, complexity mounts aggressively. Instead of a refresh on a stateless page every few seconds, one page causes bugs that rear their head for the duration of the session. These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti. But when designed properly, these problems are largely negated. I'm not advocating that SPAs are the solution to all problems. I think there's gross overuse of SPAs across the industry, but that is not an indictment of SPAs themselves. That is someone choosing the wrong technology to solve the active problem. With respect to angular (1, I never touched 2) specifically, I always found it extremely overengineered, poorly designed, with terrible APIs. But that's a problem with that specific framework and says nothing at all about SPAs at all.

Nextgrid 6y ago
> Frontend tooling has never been better than it is today. What's the library or design pattern to consume a REST API in React or any of the mainstream front-end frameworks? The only thing I'm aware of is Ember Data but Ember is apparently not cool anymore, and I couldn't find a suitable replacement. I'm asking because in all the projects I've been involved with, consuming the backend API always felt like a mess with lots of reinventing the wheel (poorly) and duplication of code. I can't believe in 2020 there's not some kind of library I can call that will give me my backend resources as JSON and transparently handle all the caching, pagination, error handling (translate error responses to exceptions), etc and people have to do all this by hand when calling something like Axios. In contrast, Django REST Framework handles all that boilerplate for me and allows me to jump right into writing the business logic. It's insane that ~30 lines of code with DRF (https://www.django-rest-framework.org/#example https://www.django-rest-framework.org/#example) gives me a way to expose RESTful endpoints for a database model to the web with authentication, pagination, validation, filtering, etc in a reusable way (these are just Python classes after all) but the modern front-end doesn't have the client equivalent of this.

ehnto 6y ago

Everyone looks to the bigger companies for tech trends, not realising that they have none of the problems ultra scale companies are trying to solve.

laichzeit0 6y ago

I also wonder how much of the SPA trend by mega corps was about shifting compute “client side” to save money on infrastructure. It’s kinda like modern data warehouses where storage/compute is now so cheap you do ELT and not ETL anymore. I probably wouldn’t do an SPA today unless I really had to.

cs02rm0 6y ago

When SPA's became the norm and even static web pages needed to be build with React I'm in a weird situation where I'm contracting into one organisation and they've contracted me out to another. The first organisation know me as a senior dev/architect with 15 years experience in a niche domain. The second organisation see me as brand new to them and despite paying an embarrassing day rate are giving me noddy UI tweaks to do. Extracting myself is proving to be slow somehow. Anyway, they wanted a webapp with a couple of APIs and nothing on the page than a button, the authenticated username and a line of text. Clicking the button opts you in/out of a service and the text changes depending on the state. The sort of thing people go to once, maybe twice. I used a mustache template on the server side to populate the values and I didn't even bother with any javascript, just did an old school form submission to the API when the button was clicked and a redirect back to the page. It was tiny but, obviously it was decided "we should be using a more modern framework" - code for React. It was the more word that got to me, as if there was an equivalent, dated framework I'd used. I didn't put up a fight partly because I was new to the team and figured they were hot on React and I wasn't. Somehow, they made a complete hash of it, they couldn't even figure out how to get all their inline styles (the only styles they used) working without help. I guess it's just those classics; people want to learn the hot new thing as they see it, their managers are happy that they've heard a buzzword they recognise and then everything becomes a nail for their new hammer.

onion2k 6y ago
Every time that sort of thing has happened to me it's been because there's some grand plan to build out more features that the people on the frontline don't know about. The plan rarely materializes but the idea that the foundation should be built in a way that supports it isn't completely stupid.
- zachrose 6y ago
  It’s not stupid, no, but a “supporting foundation” is a largely just a seductive metaphor. It says, “Clearly software is like a building. Every building needs a solid foundation.” It doesn’t inspire engagement with other metaphors, like considering software to be a tree that must be grown incrementally and as a product of dynamic forces. It doesn’t map knowledge from the building domain to knowledge in the software domain.

throwaway189262 6y ago

React isn't so bad. It's fairly straightforward and the components are contained within the page. And it's more of a library than a framework. The core is small and easy to learn Angular is a giant confusing pile of magic. It's so complex you've gotta be a core developer to even understand how an app comes together. Stay the hell away if you can

marcus_holmes 6y ago

I don't think it's developers tbh. Or rather, it's another set of perverse incentives in the industry. To get a job, devs need experience in relevant tech. No company is willing to train their devs - they all have to hit the ground running. So devs have to have demonstrable experience in the tech that lots of companies use. Companies need to hire devs, and don't really care what tech is used. But using what everyone else uses makes their hiring easier because it's easier to find devs who want to work on that tech. So they advertise for devs with experience in a hot tech. The devs see this and try and move their internal projects to use the hot tech so that if/when they look for their next job they'll have experirence in it. The devs are just trying to stay relevant in a rapidly changing tech scene so they can get their next job. The companies who employ them don't care what tech is used, but find recruiting devs to be easier if they're working in the latest hot tech. The key point that could change all this is if companies were willing to train their devs in the tech stack they're using.