Turbolinks... so it’s a less elegant implementation of [Portals](https://web.dev/hands-on-portals/)?
If Not SPAs, What?
181–190 of 456 posts
Re: If Not SPAs, What?
#182Earlier quoted context omitted.
Blazor is certainly a very interesting and promising piece of technology. However, Blazor Server hosting mode is prone to latency issues and requires always-on connection to run an applications (so, no offline mode). On the other hand, the alternative Blazor WebAssembly mode requires clients to download a sizeable mix of .NET runtime and other system DLLs on the first use of the application (even a lightweight demo a…
2 MB should not be an issue nowadays. Considering 5G roll out & substantial coverage in most mature markets, in say, 2 - 3 years, 2 MB is acceptable.
While this may be true in most first world countries, 2mb are still a lot in development regions (and sadly also in Germany)
Re: If Not SPAs, What?
#183I'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 simpl…
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, Kub…
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.
Re: If Not SPAs, What?
#184One entry in this space that doesn't get a lot of attention is ASP.NET Blazor [1]. Blazor gives you the option of writing views in C# that will actually compile to WebAssembly and run in the browser, or run on the server and send DOM updates over a SignalR connection, a lot like LiveView. [1] https://docs.microsoft.com/en-us/aspnet/core/blazor/
Blazor is certainly a very interesting and promising piece of technology. However, Blazor Server hosting mode is prone to latency issues and requires always-on connection to run an applications (so, no offline mode). On the other hand, the alternative Blazor WebAssembly mode requires clients to download a sizeable mix of .NET runtime and other system DLLs on the first use of the application (even a lightweight demo a…
I believe the runtime is under 1 MB before compression. As you stated, they're working hard to reduce that size.
At the same time, while not condoning it, I just scrolled to the bottom of Amazon's front page and downloaded over 30 MB.
Re: If Not SPAs, What?
#185I'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 simpl…
> 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 databindin…
> 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.
Re: If Not SPAs, What?
#186I'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 simpl…
> 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 l…
> These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti.
I think this is one area where front end tooling can be painful for the average dev. The bar to writing idiomatic JS for a given framework can get pretty high quickly, especially when you look at some of the really popular tools out there (i.e. redux).
Front end work has become so much harder to grok because the patterns around things like state management still have a lot of warts. The terminology of redux drives me crazy because it’s really difficult to explain things like reducers.
Re: If Not SPAs, What?
#187I'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 simpl…
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.
> 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.
Re: If Not SPAs, What?
#188Earlier quoted context omitted.
> 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…
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.
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.
Re: If Not SPAs, What?
#189Earlier quoted context omitted.
> 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 l…
> 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…
The graphql frameworks - like Apollo - give you that. I haven't used it. For basic caching the state management frameworks work pretty well, but it is a lot of layers when you add Redux or Vuex to your stack. It works well for us though and I find it much easier to reason about than the old jquery spaghetti code style.
Re: If Not SPAs, What?
#190Earlier quoted context omitted.
> 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…
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.
Food for thought: the tech sector is much larger than the trendy dumpster fire of web development. You don't have to work at some startup on some website. There is still lots of real programming to be done.