@carnage4life@mas.to or questioning whether your approach that it ignored is actually wrong.
"would it not be better to do X?" followed by a "you're absolutely right" response from the LLM.
Ian
@soviut@hachyderm.io
mastodon
4.5.9
Full stack developer with a passion for frontend.
he/him, Canadian
0
Followers
0
Following
Joined November 23, 2022
Zamtools:
CreatorGuard:
Posts
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@Migueldeicaza Shows how dangerous they consider journalists to be.
0
0
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@adamshostack No kidding, they're not even offering a simulation for us to live in while they do it.
0
0
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@arstechnica I'm looking forward to the day when these towns start to actively sabotage these datacenters.
1
0
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@molly0xfff Think of all the AI token you'll be able to afford now!
0
0
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@gedeonm I feel like that's a trap intelligent people set for themselves; You're too competent to believe anyone could be that incompetent.
It's kind of like a conspiracy theory for sane people who are really hoping someone's in control.
It's kind of like a conspiracy theory for sane people who are really hoping someone's in control.
1
0
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
0
0
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@slightlyoff @sil I don't believe that at all. Unskilled developers in the frontend are significantly less dangerous than when they're granted access to the backend.
Just look at all the accidental leaks that have happened in Next when those same devs have direct access to the database and secret keys with server actions and such.
That doesn't mean solutions like SSR aren't viable. You get much better time to first contentful paint, avoid loading spinners and don't have to heavily modify your frontend app to accommodate it.
Point being, yes, you can optimize at the server, but it comes with risks that pure frontends don't.
Just look at all the accidental leaks that have happened in Next when those same devs have direct access to the database and secret keys with server actions and such.
That doesn't mean solutions like SSR aren't viable. You get much better time to first contentful paint, avoid loading spinners and don't have to heavily modify your frontend app to accommodate it.
Point being, yes, you can optimize at the server, but it comes with risks that pure frontends don't.
0
2
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@slightlyoff @sil What I'm saying is the stakes are even higher in the backend. Those same inexperienced developers who made a bulky frontend are now able to create real security vulnerabilities.
This isn't me speculating, I've encountered it several times. I had to pause a project because I discovered over 5000 SQL injection vulnerabilities in their API. The only reason they hadn't been utterly pwned is because their host had some rudimentary injection prevention middleware.
Had they used a framework, they wouldn't have been able to produce those vulnerabilities (at least not as easily as they did raw dawging it).
To summarize, servers are a luxury and should be treated as such. If your team is struggling to ride a bicycle, don't give them a motorcycle.
This isn't me speculating, I've encountered it several times. I had to pause a project because I discovered over 5000 SQL injection vulnerabilities in their API. The only reason they hadn't been utterly pwned is because their host had some rudimentary injection prevention middleware.
Had they used a framework, they wouldn't have been able to produce those vulnerabilities (at least not as easily as they did raw dawging it).
To summarize, servers are a luxury and should be treated as such. If your team is struggling to ride a bicycle, don't give them a motorcycle.
0
2
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@slightlyoff @sil Less catastrophic? Every major data breach for nearly a decade was Wordpress sites getting hacked. Even popular open source maintainers couldn't secure their PHP.
All I'm saying is, call out the actual culprits; in this case, React. Vue and Svelte are both are more efficient and better citizens in the space.
All I'm saying is, call out the actual culprits; in this case, React. Vue and Svelte are both are more efficient and better citizens in the space.
0
2
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@slightlyoff @sil If closer to the metal limited factors, then PHP sites would be a lot less prone to issues. Instead, it took a framework like Laravel to remove a lot of the PHP "foot guns".
I'm not disputing that showing a loading spinner on a benefits site is ridiculous. If you need one before you can even interact then you've already failed.
Building performant frontends isn't a hard thing to do, just something you have to be aware of. In my experience, this mostly boils down to saying no to "grid" components and no to charts libraries, haha.
I'm not disputing that showing a loading spinner on a benefits site is ridiculous. If you need one before you can even interact then you've already failed.
Building performant frontends isn't a hard thing to do, just something you have to be aware of. In my experience, this mostly boils down to saying no to "grid" components and no to charts libraries, haha.
0
2
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@slightlyoff @sil Not only have I seen way worse structural MPAs, but I've seen ones that are terrifyingly insecure as well.
The blast radius of a mistake in server side is so much worse. You see it now as server components and mixed client/server state accidentally leak because a convention got messed up.
These teams will exist no matter what and their impact will be worse the closer to the metal you put them.
The blast radius of a mistake in server side is so much worse. You see it now as server components and mixed client/server state accidentally leak because a convention got messed up.
These teams will exist no matter what and their impact will be worse the closer to the metal you put them.
0
2
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@slightlyoff @sil I don't think the "practice" cut against it. I think the only thing it cuts against is engineering philosophy and an academic mindset.
I believe it's important to be measuring this stuff, but I also treat performance as a feature, and features get cut all the time.
For example, the latest Pokemon games on Switch have terrible performance issues but it sold 5.8 million copies in its first week. The game was compelling enough that anyone who played it didn't care. The only ones loudly complaining were people who didn't really play them; the video game academics, so to speak.
My point is that teams are optimizing for their users and sometimes that means performance takes a hit.
I believe it's important to be measuring this stuff, but I also treat performance as a feature, and features get cut all the time.
For example, the latest Pokemon games on Switch have terrible performance issues but it sold 5.8 million copies in its first week. The game was compelling enough that anyone who played it didn't care. The only ones loudly complaining were people who didn't really play them; the video game academics, so to speak.
My point is that teams are optimizing for their users and sometimes that means performance takes a hit.
0
0
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@slightlyoff @sil I've worked several times with those teams who picked the wrong tech. They did so because they're cargo culting and would fare even worse with vanilla JS or an MPA.
The issue is many of them don't have deep web fundamentals. Not because of frameworks, but because the web is notoriously vast and constantly churning. I happen to like the churn but many find it exhausting and I don't blame them for that.
At the very least, Frameworks are well documented mostly static targets that let developers focus more on solving problems rather than fighting their browsers. Frameworks are solving a people problem more than a technical one.
The issue is many of them don't have deep web fundamentals. Not because of frameworks, but because the web is notoriously vast and constantly churning. I happen to like the churn but many find it exhausting and I don't blame them for that.
At the very least, Frameworks are well documented mostly static targets that let developers focus more on solving problems rather than fighting their browsers. Frameworks are solving a people problem more than a technical one.
1
2
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@slightlyoff @sil I wasn't being rude or sarcastic so there's no need for you to be; keep this civil.
I never said it was impossible to build those flows without a SPA, only that SPAs are intended to be applications, not sites. The examples I gave were just applications where a SPA could shine; not where it was somehow the only option.
Have sites been built as SPAs? yes. Is it the best use case for them? No. Just because a team chose the wrong tech to build something doesn't invalidate the tech.
I've built ordering systems back in the day as MPAs and their UX was never as nice as a stateful frontend app. And building a stateful frontend app is a lot nicer with Vue than vanilla JS. However, if I'm building a landing page, that's going to be Astro these days.
I never said it was impossible to build those flows without a SPA, only that SPAs are intended to be applications, not sites. The examples I gave were just applications where a SPA could shine; not where it was somehow the only option.
Have sites been built as SPAs? yes. Is it the best use case for them? No. Just because a team chose the wrong tech to build something doesn't invalidate the tech.
I've built ordering systems back in the day as MPAs and their UX was never as nice as a stateful frontend app. And building a stateful frontend app is a lot nicer with Vue than vanilla JS. However, if I'm building a landing page, that's going to be Astro these days.
0
2
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@sil @slightlyoff I acknowledged that some sites are SPAs when they shouldn't be.
Though, I'd argue that a restaurant site with any kind of online ordering capability is an application, just like UberEats, DoorDash, etc.
And even if a site is a SPA when it really shouldn't be, SSR solves that by giving you fast time to first paint before hydrating. So you can glance at the hours of operation. Most sites built as SPAs need SSR anyways for per-page SEO metadata.
That's the true indicator; if your project needs SEO, it's a site and if it doesn't it's an app (since most apps are behind a login anyways).
Though, I'd argue that a restaurant site with any kind of online ordering capability is an application, just like UberEats, DoorDash, etc.
And even if a site is a SPA when it really shouldn't be, SSR solves that by giving you fast time to first paint before hydrating. So you can glance at the hours of operation. Most sites built as SPAs need SSR anyways for per-page SEO metadata.
That's the true indicator; if your project needs SEO, it's a site and if it doesn't it's an app (since most apps are behind a login anyways).
0
2
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@sil @slightlyoff Typically SPAs aren't "sites", though. It's in the name, they're applications. Those are things you DO keep open for long periods; Calendars, email clients, forums, etc.
SPAs being shoehorned into sites and landing pages by teams that didn't know better at the time is unfortunate, but mostly mitigated by SSR these days anyway.
Also, let's not kids ourselves; it isn't SPAs that are the problem, it's React specifically. It's the slowest at DOM manipulation, has one of the heaviest runtimes, and seems to almost be designed to cause re-render issues.
SPAs being shoehorned into sites and landing pages by teams that didn't know better at the time is unfortunate, but mostly mitigated by SSR these days anyway.
Also, let's not kids ourselves; it isn't SPAs that are the problem, it's React specifically. It's the slowest at DOM manipulation, has one of the heaviest runtimes, and seems to almost be designed to cause re-render issues.
0
4
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@grumpygamer hidden intro in the remake? ;)
0
0
0
Ian
@soviut@hachyderm.io
Full stack developer with a passion for frontend. he/him, Canadian
hachyderm.io
@dogposting (assuming this is to the tune of Jolene)
cowabunga, cowabunga, cowabunga, cowabunga.
I'm betting that they foil all Shredder's plans.
cowabunga, cowabunga, cowabunga, cowabunga.
Oh please defeat the Technodrome and Krang.
cowabunga, cowabunga, cowabunga, cowabunga.
I'm betting that they foil all Shredder's plans.
cowabunga, cowabunga, cowabunga, cowabunga.
Oh please defeat the Technodrome and Krang.
0
0
0