> In many ways, the reason front end developers moved to SPAs was that they could better control their own tooling in ways that are difficult in the traditional web application frameworks.
Partially, but let’s not pretend our field is more rigorous than it actually is. Most it was following fads: the cool kids at some big tech companies were building HUGE apps with tons of logic as SPAs and a lot of people wanted to say “us too!” without considering how similar their apps are or comparing staffing. The natural arc I’ve seen is that teams who didn’t pick an SPA for solid technical requirements end up delivering results which are no better at considerably slower speed because they’re supporting a lot of non-domain complexity and still end of changing their backends in lock-step with the front end. That tends not to leave time for things like accessibility or performance.
>> but I recently did some work with a front-end contractor
All no-framework-needed examples seem to boil down to having a simple enough problem needing just one (or few) front end developers. Would be good to hear how a larger team (say 10+) managed without one.
> You're going to integrate your code into their proprietary platform, so they need the integration to be as straight forward as possible. Thus an SPA is a very good candidate.
MVC all the way, because otherwise you're never going to finish it. Doing a separate backend + SPA is an insane amount of work compared to a traditional full stack framework. Just thinking about validations (both server and client) make my brain hurt. Also you'll have to rewrite the frontend before even finishing it given how fast the landscape changes.
And even being a small team and not just yourself, I'd only think of an SPA if 1) You need an offline first experience, or 2) You don't have full stack engineers at hand and you only have backend people which don't want to touch JavaScript and frontend people which only want to work with JavaScript..... but this is more of a people problem than technical one.
I've done a lot of Django in the past, then a lot of SPAs for the last 6 ~ 8 years, and now I'm back to Laravel + Livewire and I'm living in a dream right now. Everything is so easy that I feel I've been cheated the last few years.... so much time and money (from my employers) wasted...
> And with more recent technologies like Phoenix LiveView, there is very little need to use any of those front-end frameworks.
Sure, if you choose to buy in to a backend framework.
I'm not knocking Phoenix, but it's a tradeoff. I'd rather be able to write the backend without a framework and use the framework where I want to spend the least amount of time figuring things out, which is usually on the frontend/GUI. But everyone is different.
>You can actually see this with new frontend devs. They know only full SPA frameworks, ......
Around I guess 2017 or even 2016? I used to think this is some sort internet troll comment about people never seen a dump of an HTTP message, until......
>Because they started with assembly.
It wasn't necessary starting with assembly or something low level. ( Although that certainly helped ) We have less entertainment, more time, and no Internet ( for most part ). Things also dont work all the time. And we have to spend time figuring it out ourselves. That is where all the knowledge comes from.
> but definitely start with one and stick with it for a bit
Devs are paid quite a bit of money to play russian roulette with their tool choices.
Frameworks are an abstraction and not really key to understanding anything. And devs need to understand, at least conceptually what the framework is doing (or attempting to do) without too much magical BS. Ideally that starts with working with the dom and seeing first-hand the pains and joys of adding and removing elements, functions, sync and async behaviours, data handling, objects etc.
Then only will frameworks click and make sense, and so choose the right tool for the right job.
> No react, no reduce, no apollo or graphql. No typescript, etc.
All of these bring 10 benefit but add 12 problems back. It makes developing project slow at start, slow at medium term, and super garbage at long term. If developers get paid $100k+, I think they should be able to write good codes and have a good team instead of using these to save them from mediocrity.
If you have to really do SPA, pick something that's not bloat, not slow, not flaw .. instead of "hiring pool" BS.
> everything is repeated every six months to two years
Same feeling looking at the new Vercel SQL library. Oh wow now you can write SQL right next to your client-facing code, such convenient. You have just rediscovered PHP.
To be fair, frontend frameworks solve a problem. Application can get too big that you cannot manage all the states imperatively. Declarative UI building really help to keep the UI separated from the logic. But then management get greedy and and try to shove all the features they can think of into one single big app. Like, if you went to a page and click a button, going to another page will let you know that you clicked that button and shows up some nice CTA so you won't forget. Frontend people scramble around trying to create new abstraction to keep their working surface manageable. Then you get workflows where to get the result of an API call you have to dispatch a thunk action so it would update in the global store (my example may be antiquated, I'm away from React & Redux for a little while), instead of just, you know, call it and `.then()` update the UI.
Maybe if you have an app that is twice bigger than a normal app, maybe, I don't know, split it into two apps instead? The problem of web development app right now, I think, is because people are being monolithic where it should be independently modular, and then try to cut up your backend service into pieces when a single monolith works fine.
> BTW, someone had the "great" idea of not using a framework for an internal admin portal. It turned immediately into a huge ball of mud.
It's never the case that you "don't use a framework" for something like that. You'll use a framework, alright. The choice is between using something well-built based on best practises as we know them, or... building it yourself. Other than in very rare circumstances, I fail to see the point of reinventing that wheel. UI frameworks (web front-end or not) are a quagmire of edge cases and other infinite time sinks.
> If it were, developers would not be flocking en masse towards SPAs and the like.
Argumentum ad populum. That's not an indicator of something being better. I do like using the modern SPA frameworks for well, (web)apps but I strongly disagree with using them in every case.
> Long story short, if you are working on a personal project, please, consider the most dumb setup.
This is not limited to personal projects. I can’t recall more than a single project I’ve worked on during the last decade where front-end code was really useful. Some cool stuff, ok, but never worth the pain.
I acknowledge it can be useful. For some real time project. Not for your crud-for-a-living.
>SPA's suck! Here's my ad-hoc replacement architecture that you should totally just use!
Really though, this is a dead horse. SPAs are just a tradeoff like everything else in engineering. We trade the simplicity of a monolith for the ability to parcel out work efficiently between large disparate teams of frontend/backend engineers.
> And honestly, I would be more concerned about hiring someone who built their own bespoke framework from scratch than someone who used an existing one. Building frameworks rarely adds business value.
Hum... My experience is that whatever framework a business use in any widespread manner, I do always have to build another one on top, because generalist libraries completely suck for productivity. Unless you are a single app shop, then you can just hard-code everything.
I don't get how improving development speed does not add business value.
> As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it.
I actually see this as a negative and we've been looking at Uber/Fx for more support. DI frameworks don't do anything you can't do without it, but it takes significantly more experience and technological/organizational maturity that I find the average developer doesn't have to do it without framework support.
In the current zeitgeist of being towards the "micro" scale of the spectrum, that "average developer" support is necessary. If you have more modular monoliths or many high quality examples, maybe its better.
And document it yourself, and maintain it yourself, and build an ecosystem of extension for it yourself, and create video tutorials for it yourself, and ...
A minimalist off-the-shelf framework can go a long way.
I like frameworks that do not do much more than provided by their libraries that get exposed by it. So I can always swap out libraries, or carry a long certain libraries after moving on from the framework.
> nor is there trivial integration for JS assets/asset pipeline functionality
...WHY would anyone ever want that?! I thought that splitting an app into one frontend-app and one backend-app, each in its separate repository too and runable alone is the very minimum everyone does nowadays.
(Yeah, later you may go on and chop the backend into microservices, but for starters you at least keep these two sepratate - why would you want to impose knowledge of Python or Django as requirement for your frontend developers?! Even if you start with a couple full-stackers, you'll want to later be able to hire more narrow focused specialists.)
Only if you go the SPA route.
reply