Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Can You Afford It? Real-World Web Performance Budgets

infrequently.org

Post reply on HN
Print view View original

111–120 of 130 posts

Re: Can You Afford It? Real-World Web Performance Budgets

#111

Post by tomaskafka »

virmundi wrote: post #5

Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…

This. Several old-style 'server side rendered' pages I made seem superfast with https://github.com/turbolinks/turbolinks .

Re: Can You Afford It? Real-World Web Performance Budgets

#112

Post by zbentley »

naasking wrote: post #108
Can_Not wrote: post #105

Earlier quoted context omitted.

Credit card info, passwords...

You're already submitting it to the server. It's no less secure sending it back if there's a problem.

This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad. Hash them securely (well, as securely as you can on the client side). Sending them twice is worse. Storing them with the session data on the backend so that they can be sent back to the client to repopulate a form is way worse, since more than one webserver may be handling a session, that plaintext data will have to be stored in a centralized database (e.g. memcached), which is really really bad, even if that storage is temporary.

Some web forms get around this by just sending back the lengths of the individual fields so they can be masked when the form is repopulated, but that's less common and is something that doesn't occur to lots of developers (store the length, but don't send the whole string). Instead, it's easier to follow the mantra of "never store the passwords in plaintext, never send them over the wire in plaintext". Which is why most web forms clear out the sensitive fields when repopulated via the server.

TL;DR it is much, much less secure to do this.

Re: Can You Afford It? Real-World Web Performance Budgets

#113

Post by jrs95 »

sanderjd wrote: post #30
jrs95 wrote: post #29

Earlier quoted context omitted.

Even the full page loads aren't necessary with Turbolinks or PJAX. If I had a choice, thats definitely what I'd be using for what I'm working on now at an ecommerce company. But the boss insists on microservices, and the once the advantages that come with a monolith are gone the SPA is just a better approach imo

Correct me if I'm wrong, but don't Turbolinks and PJAX work through JS as well?

Yes, but way less. Turbolinks in particular basically just requires you to add the library, which is very lightweight, and then you get page changes without the bad visuals of the whole screen flashing white, and it's not too difficult to keep it fast too.

Re: Can You Afford It? Real-World Web Performance Budgets

#114

Post by discreditable »

pcmaffey wrote: post #104
mrighele wrote: post #75

Earlier quoted context omitted.

I would love to have a way to tell the browser "don't throw away the current DOM, Just apply the differences". It would work nicely in non-js page to make the experience smooth (and would probably work terribly if there was a lot of J's, of course)

This is exactly what React's virtual DOM does. Maybe the future is making the virtual DOM native to the browser? Bundle React with Chrome? Or how about a browser package manager that could cache and reuse all these common js libraries used on so many sites?

DecentralEyes does just that.

Re: Can You Afford It? Real-World Web Performance Budgets

#115

Post by naasking »

zbentley wrote: post #112
naasking wrote: post #108

Earlier quoted context omitted.

You're already submitting it to the server. It's no less secure sending it back if there's a problem.

This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad. Hash them securely (well, as securely as you can on the client side). Sending them twice is worse. Storing them with the session data on the backend so that they can be sent back to the client to repopulate a form is way worse, since more than one webser…

> This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad

What are you talking about? Who said anything about plaintext? And no one said anything about sessions either.

If you're submitting to the server in plaintext, then returning in plaintext is no less secure, but you're stupid for not submitting over https which is free.

If you're submitting to the server over https then it's definitely no less secure to return the data.

Re: Can You Afford It? Real-World Web Performance Budgets

#116

Post by TeMPOraL »

christophilus wrote: post #93
gjjrfcbugxbhf wrote: post #85

Earlier quoted context omitted.

But you still need to do the server side valuation.

Yes, but from the end-user perspective, it's nice to not have to do a round-trip to find out that you entered something wrong.

Fair enough.

Still, validating a form client-side doesn't require a JavaScript framework; it would only require the server to send small snippets of JS for each field with the form.

Re: Can You Afford It? Real-World Web Performance Budgets

#117

Post by tboyd47 »

kakarot wrote: post #101
tboyd47 wrote: post #97

Front-end developers could solve all of this by just learning the base technologies of HTML, HTTP, CSS, and JS really well and ignoring everything else. We're at a beautiful point in web development where browsers are finally unified on open standards, and we're all too locked into these outdated JS frameworks to take advantage of it.

It's important to strike a healthy balance between reinventing the wheel and locking yourself into a bulky framework. Whether you are building a personal project, or working on another's time, in the early phases your #1 concern should be speed of development. If a compact, properly modularized, battle-tested tool that completes your desired task is readily available, should you really be wasting your time writing so…

But you are missing my main point: what are all these frameworks for?

I bet if you asked any front-end developer what the main benefit of their chosen framework is, they will say something like code organization or file structure.

It used to be that you needed a framework to abstract away all the browser incompatibilities. But that was in 2009 -- look up any given W3 standard on CanIUse these days and you will find support across all major browsers.

What if we could just get by without a framework? And just organize our own code? Is that so far-fetched?

Re: Can You Afford It? Real-World Web Performance Budgets

#118

Post by samsonradu »

zbentley wrote: post #112
naasking wrote: post #108

Earlier quoted context omitted.

You're already submitting it to the server. It's no less secure sending it back if there's a problem.

This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad. Hash them securely (well, as securely as you can on the client side). Sending them twice is worse. Storing them with the session data on the backend so that they can be sent back to the client to repopulate a form is way worse, since more than one webser…

Think you're a bit confused about how it all works. There is no need to use plaintext, we'll assume we're using https by default. You are already sending the data from the client to the server, I can as well echo it back with a couple of validation errors.

I don't see the security hole in this situation, you do realise that regardless of the obfuscation you see in your password input fields, which by the way only protects from over-the-shoulder peeking, you are willingly sending data to the server and it will end up there unencrypted anyway. Otherwise there wouldn't be possible to do any operation at all.

Re: Can You Afford It? Real-World Web Performance Budgets

#119

Post by youngtaff »

olegkikin wrote: post #54

His argument is based on an example where he puts JS in , when it's been a recommendation for ages to put JS at the very end of .

JS at the end of the body is quite an out of date approach these days the recommendation is to use defer or async attributes.

Challenge is will all these approaches is JS will generally still delay Time To Interactive

Re: Can You Afford It? Real-World Web Performance Budgets

#120

Post by Can_Not »

samsonradu wrote: post #118
zbentley wrote: post #112

Earlier quoted context omitted.

This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad. Hash them securely (well, as securely as you can on the client side). Sending them twice is worse. Storing them with the session data on the backend so that they can be sent back to the client to repopulate a form is way worse, since more than one webser…

Think you're a bit confused about how it all works. There is no need to use plaintext, we'll assume we're using https by default. You are already sending the data from the client to the server, I can as well echo it back with a couple of validation errors. I don't see the security hole in this situation, you do realise that regardless of the obfuscation you see in your password input fields, which by the way only pro…

Security operates in layers. TLS isn't the end-all, be-all for security. It's one layer that prevents a category of attack vectors. Every extra unnecessary sending or storing of sensitive data is an attack vector.
Post reply on HN