Putting Devs Before Users: How Frameworks Destroyed Web Performance

Re:Putting Devs Before Users: How Frameworks Destroyed Web P... by mikekchar on Thursday January 02, 2020 @04:01AM (#21933906)

For me the main appeal to SPAs are testing oriented. Assuming I need some kind of interactive functionality that can't be done using a form, testing across the browser interface is difficult when doing HTML view production on the server side. If you are doing HTML view production on the client side, suddenly it's much easier. I test that the server produces the correct data given a request and I test that the client renders the correct views given the data. In Michael Feather's parlance, I've got a viable "seam" for testing against.

[ Parent | on HN ]

Re:Putting Devs Before Users: How Frameworks Destroyed Web P... by cousin_it on Thursday January 02, 2020 @04:51AM (#21934071)

But if something can be done with links and forms, SPA makes it harder to test. So I prefer using JS only for islands of interactivity within specific pages, not making the whole application one big island.

[ Parent | on HN ]

Re:Putting Devs Before Users: How Frameworks Destroyed Web P... by ericb on Thursday January 02, 2020 @08:46AM (#21935270)

I mean, yes, but from a broader perspective, didn't you create your "seam" by adding in an entire second application?

[ Parent | on HN ]

Re:Putting Devs Before Users: How Frameworks Destroyed Web P... by xg15 on Thursday January 02, 2020 @06:49PM (#21941321)

Out of couriosity, how is testing on the client easier?

I'd think you still have to verify the same way that the results are correctly rendered - except now you have to verify that the DOM is correctly generated as well.

[ Parent | on HN ]