481–490 of 875 posts
This puts all the computational load on the server. Imagine 10s of thousands of clients requesting millions of HTML fragments be put together by a single server maintaining all the states while all the powerful high end computing power at the end user's fingertips goes completely to waste. Not convinced.
Earlier quoted context omitted.
In this situation code for a good strength meter is going to be an order of magnitude or two more complicated than the boolean validity check. Porting 50x as much code to the server is significantly worse than having two versions or having one shared function and one non-shared function.
You shouldn't have to port anything. If you mean in the opposite case of two separate languages between client and server side then yeah, of course - by definition you're rewriting everything and there is no way to reuse code. I'm not clear how you're reaching anywhere near 50x complexity though. You're writing something like this on the client side (please excuse the lazy checks): function basicValidatePassword(pass…
Earlier quoted context omitted.
I remember that all the web shops in my town that did Ruby on Rails sites efficiently felt they had to switch to Angular about the same time and they never regained their footing in the Angular age although it seems they can finally get things sorta kinda done with React. Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript. If the real…
Or even skip the DSL and use JS for both client and server, just independently. Validation functions can/should be simple, pure JS that can be imported from both.
Language and runtime decisions really need more context to be useful. JS everywhere can work well early on when making a small number of devs as productive as possible is a goal. When a project scales parts of the stack usually have different priorities take over that make JS a worse fit.
Earlier quoted context omitted.
I definitely associate it (Angular) with Python BE devs for some reason.
It was/is quite popular with .NET developers due to TypeScript being very similar to C# and implementing similar patterns like dependency injection (I know dependency injection/IOC isn't .NET specific).
Earlier quoted context omitted.
Ouch! I’ve worked in two kinds of organizations. In one of them when there is a ‘small’ ticket from the viewpoint of management, one programmer is responsible for implementation but might get some help from a specialist (DBA, CSS god, …) In the other a small ticket gets partitioned to two, three or more sub teams and productivity is usually reduced by a factor more than the concurrency you might get because of overhe…
I’ve worked at the same company for a long time. For about 15 years, my team was embedded in a business team and we managed things however we wanted. We could move very quickly. Then, about 5 years ago, we were moved into the tech organization. We were forced to adopt agile, sprints, scrum masters, jira, stand ups, etc. It probably takes 10 times longer to get the same amount of work done, with no improvement in qual…
Tech orgs and those standards exist because:
- tech generally doesn't understand business - the business struggles to express it's needs to tech
Embedding worked for you, but how big was your team? Could that scale?
I'm not questioning your success or your frustrations, but how unique was the situation for your success?
I'm sorry, but these arguments are so tired. > SPAs have allowed engineers to create some great web applications, but they come with a cost: > Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks. Yes, better quality software usually packages a bit more complexity. SPAs are popular, just like native apps, because people don't…
> _Yes, better quality software usually packages a bit more complexity._ That view (+quality = +complexity) is actually flip sided, isn't it? [1] [1] https://www.infoq.com/news/2014/10/complexity-software-quali...
Earlier quoted context omitted.
You're thinking just of the amount of data sent, not the amount of work that's done on the back end. Just because it's only showing you the most recent 40 messages or something doesn't mean it isn't doing a significant amount of work on the back end to determine what those messages are. Not having to scan through all your email and sort by date nearly as often is a significant win.
That is an at rest choice that should be identical in both. I presume you are thinking of rendering? But, again, that is largely done client side in both cases.
As a simplisit ecanple, imagine an app which on login has to do an expensive query which takes five seconds to return because of how intensive it is on the back end. If you can just redisplay the data that's already in memory on the client, optionally updating it with a much less expensive query for what's changed recently, then you're saving about five seconds of processing time (and client wait time) by doing so.
Yiu could use localStorage to do something similar without it being a SPA, but that's essentially opting into a feature that serves a similar need.
Client side caching is a strong point of SPAs, so it makes sense that a use case that can leverage that heavily will have benefits.
Earlier quoted context omitted.
That is an at rest choice that should be identical in both. I presume you are thinking of rendering? But, again, that is largely done client side in both cases.
No, I'm talking about back end processing cost. If the main page of the app has a significant server cost in the determining what data is being sent, being able to just redisplay the data you have when you browse back to the main page instead of request it again, which could incur that large processing fee, is a large gain. As a simplisit ecanple, imagine an app which on login has to do an expensive query which takes…
> Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks. You have to learn something. You can claim bloat in JS frameworks, but that isn’t solved by simply moving it to the server. Is htmx lean and nice today? Probably! But does it handle the same use cases that the React users have? What happens to it under pressure of featur…
> Finally, we cut to the chase. This is 100% true, and we should be talking about this, because it’s still not settled: do we want web pages or web apps? If both, where is the line? Can you expect something like Slack to work without JavaScript? What about a blog with interactive graphs? Should everything degrade or should some things require JS/WASM? BINGO. At times, it seems everyone is talking through each other b…
Glad to hear. Yes, it seems like the post and the comments are largely missing the functional issue at play.
> the blog post we are talking about which displays awful without running JavaScript
Yeah, case in point, perhaps.. I mean if you have two paths (incremental and full) to reach the same state, you better be careful to ensure those are functionally equivalent. This is surface are for bugs, so the very least you need to do is turn off JS and test all flows. To me, the value add of SPAs is the snappy UI, and offline-capabilities, so if you’re gonna roundtrip to the server anyway, then you may as well just re-render the entire page old-school to greatly reduce complexity.
> the biggest problem I have with these is that they exist as web clients in the first place: the world would be a different place if approaches such as wxWidgets has paid off and gotten adopted, imagine how many slow and bloated web apps could've been beautiful and fast native applications.
I actually disagree with this (the opinion, not the problem statement). The main players, Apple, Microsoft, Google, have known about the cross-platform issues and haven’t done jack in decades (perhaps flutter deserves an honorary mention though). Meanwhile, the web, with all its problems, have gotten so much better. Getting the web to the point of native standards seems much more feasible than establishing new open standards for app development. The bloat issue is largely a red herring imo. A well made web app is snappy, and importantly, can be sandboxed. The issue is that people don’t care. You can find equally shitty and bloated apps in the sea of crap on the app stores. With webview support in the OS, bundles can be small. I have an app based on Tauri which is web based, and the msi is 10Mb. It’s never had any perf issues.
Earlier quoted context omitted.
It works out of the box on SPAs too. It doesn't require reimplementation by said bad developer.
We’re way too far into a thread for me to have to restate the original point I made in the first post. If what you’re saying is true we’d never see bad implementations of history in SPAs yet we do all the time. But look, whatever. It’s Friday afternoon, I’m out of here. Have a good weekend.