3 ms·

For the vast majority of web users the only sites they ever visit that really need any of these front end frameworks are their webmail and social network platfo

by hanoz 7y ago

For the vast majority of web users the only sites they ever visit that really need any of these front end frameworks are their webmail and social network platforms of choice. For everywhere else a combination of backend processing with a smattering of vanilla javascript, or jquery, would provide a far superior user experience.

Zelphyr 7y ago
I don't see what's wrong with this post that it should be downvoted like it has been. I personally agree with this sentiment. It's like the developers who immediately rush to massive scale when all they've been asked to build is effectively a prototype. I've seen it time and again... they get bogged down in making sure the app can scale when they have yet to have a single paying customer for the product. At that point, they don't even know if there is even a market for the product and they're trying to build something that millions of users can use right out of the box. The priorities are off. If a combination of back-end processing with some vanilla javascript, or jquery will get you to market for your first 100-1000 users (which, we know it will because that used to be the only way we could do things, on much less powerful hardware no less) then I say go with that. In the mean time you can work with the stakeholders to put together a strategy for scaling up as demand increases.
- lukevp 7y ago
  I replied to one of your other posts about how great I think React development is, but I want to also state my wholehearted agreement with this thread. For things you would use a SPA framework for, it’s really the types of thing that are apps that happen to be hosted through a web browser. They’re very distinct from web pages. Most user facing websites should be built with backend server processing and js/query. React is nice because you can progressively enhance particular components, so it works well as a complement to a backend language, but in that case the tooling overhead is pretty high for what you get. So in those cases I typically go the jQuery route as well.
- philbarr 7y ago
  > It's like the developers who immediately rush to massive scale when all they've been asked to build is effectively a prototype. I just finished working in the public sector and it's absolutely terrible for this. We had a microservice based event-driven architecture, all on AWS, load balancers everywhere. It was so complicated not a single person knew the entire architecture. Current number of users: 65 Expected maximum number of users ever: 8000
yen223 7y ago
I'd love to see how Google Sheets would be implemented with a smattering of vanilla JavaScript
- bryanrasmussen 7y ago
  I don't think Google Sheets falls into the category what most web sites need to work.
- simianparrot 7y ago
  It's about using the right tool for the right job.
onion2k 7y ago
... a far superior user experience. It's incrediy subjective obviously, but in my 25 years of web dev (full stack) rendering speed has been the number one gripe from users. I've spent thousands of hours optimizing web things. The biggest impact on user perception of speed was the move to Web 2.0 eg JS apps that fetch data with 'ajax' and update the DOM. If my experience is anything to go by users absolutely prefer client side rendered apps (with SSR, hydration, caching, memoization, optimal data structuring, etc, etc). No doubt a huge amount of client side JS is garbage, and users would be better served by a server rendered website than a bad client side rendered app, but they'd be even better off still with a good client side rendered site.
- GordonS 7y ago
  I often use a mix, with ASP.NET Core MVC doing most of the work, but using Javascript to load some things at the client-side - for example, table data. This provides fast page loads, with the ability to load additional data without reloading the whole page.

by hanoz 7y ago

Zelphyr 7y ago

I don't see what's wrong with this post that it should be downvoted like it has been. I personally agree with this sentiment. It's like the developers who immediately rush to massive scale when all they've been asked to build is effectively a prototype. I've seen it time and again... they get bogged down in making sure the app can scale when they have yet to have a single paying customer for the product. At that point, they don't even know if there is even a market for the product and they're trying to build something that millions of users can use right out of the box. The priorities are off. If a combination of back-end processing with some vanilla javascript, or jquery will get you to market for your first 100-1000 users (which, we know it will because that used to be the only way we could do things, on much less powerful hardware no less) then I say go with that. In the mean time you can work with the stakeholders to put together a strategy for scaling up as demand increases.

lukevp 7y ago
I replied to one of your other posts about how great I think React development is, but I want to also state my wholehearted agreement with this thread. For things you would use a SPA framework for, it’s really the types of thing that are apps that happen to be hosted through a web browser. They’re very distinct from web pages. Most user facing websites should be built with backend server processing and js/query. React is nice because you can progressively enhance particular components, so it works well as a complement to a backend language, but in that case the tooling overhead is pretty high for what you get. So in those cases I typically go the jQuery route as well.
philbarr 7y ago
> It's like the developers who immediately rush to massive scale when all they've been asked to build is effectively a prototype. I just finished working in the public sector and it's absolutely terrible for this. We had a microservice based event-driven architecture, all on AWS, load balancers everywhere. It was so complicated not a single person knew the entire architecture. Current number of users: 65 Expected maximum number of users ever: 8000

yen223 7y ago

I'd love to see how Google Sheets would be implemented with a smattering of vanilla JavaScript

bryanrasmussen 7y ago
I don't think Google Sheets falls into the category what most web sites need to work.
simianparrot 7y ago
It's about using the right tool for the right job.

onion2k 7y ago

... a far superior user experience. It's incrediy subjective obviously, but in my 25 years of web dev (full stack) rendering speed has been the number one gripe from users. I've spent thousands of hours optimizing web things. The biggest impact on user perception of speed was the move to Web 2.0 eg JS apps that fetch data with 'ajax' and update the DOM. If my experience is anything to go by users absolutely prefer client side rendered apps (with SSR, hydration, caching, memoization, optimal data structuring, etc, etc). No doubt a huge amount of client side JS is garbage, and users would be better served by a server rendered website than a bad client side rendered app, but they'd be even better off still with a good client side rendered site.

GordonS 7y ago
I often use a mix, with ASP.NET Core MVC doing most of the work, but using Javascript to load some things at the client-side - for example, table data. This provides fast page loads, with the ability to load additional data without reloading the whole page.