DEV Community

Discussion on: Web App or LAMP?

cjbrooks12 profile image
Casey Brooks

It sounds like you're using "Web App" to mean single-page Javascript app, and "LAMP" to mean a server-side rendered website.

Obviously, there is never a "one-size fits all" for any project, and there is nothing inherently better about a server-side rendered app vs a single-page app. But for an e-commerce platform, performance is crucial, as page loading times directly impact sales, and quite dramatically too. You really don't want to get bought into a technology stack and then find it cannot hold up and deliver quickly under high load, so don't just take my word for it, and don't necessarily pick a web app just because the client wants it. A single-page app might be the best choice, it might not be; it's just a hard choice, and one you really need to investigate and see how well they work for your particular use-case.

That being said, I mentioned that performance is crucial and directly correlated to sales, but there are several ways to measure performance.

  • Time to First Byte - The time to first byte is a metric of how long it takes a server to begin sending you data after you navigate to the page. Pages that are rendered on the server will necessarily have a longer TTFB, because they must run code to assemble the HTML before they start sending it out. Effective caching mechanisms can make this almost negligible, but it is also difficult to do caching well. In contrast, a single-page app is likely to have a much faster TTFB, because it isn't doing much server-side processing on the initial request.
  • Time to First Paint - This is a metric of how long it takes to get stuff to show up on a webpage after the browser has started receiving data. Before the browser can "paint" anything to the screen, it must download all Javascript and CSS required, parse it, and then start executing it. For this reason, sngle-page apps tend to have a longer TTFP because of the work they need to do after they start receiving data. Again, caching mechanisms and progressive web-apps can mitigate this metric, but server-side pages definitely have the advantage here, because its more likely that they can start displaying stuff the moment it arrives at the browser.
  • Time to Interactive - After the browser has started painting stuff to the screen, you then need to wait for the page to become "interactive". If you are using a server-rendered page, then it is typically interactive immediately, while single-page apps need to have their javascript parsed, and then usually need to make one or more HTTP calls to fetch your store data before the user can actually interact with it.

So as you can see, there are lots of ways to measure performance, and one isn't necessarily more important than the other. And you're also not limited to a "pure" server-rendered application, or a "pure" Javascript application. There are "isomorphic applications" which aim to render an page on the server that is fully interactive, and can download the Javascript later to just improve the experience. You might also try combining a "static site generator" with Snipcart to get an unbeatable TTFB and complete freedom over store design, with many fo the benefits of server-side rendering, and then only the cart is a Javascript app.

ab0nilla profile image
Alejandro Bonilla Author

Thanks Casey Brooks!!! nice comment!!!

Exactly, my client has a One Page Apps user, he say: "web pages that adapt to everything". And I said "the implementation should not be based solely on your experience and personal decision".

He insists on making a one page app, because it's modern, beauty, and blah blah.

I agree with him, but I do not agree to use it based only on that.

When a client thinks he knows what he needs, it's a bit annoying

the_fln profile image
Francois Lanthier Nadeau

💯@Casey Brooks, thanks for mentioning Snipcart!

@Aljandro Bonilla we have this post on the blog that might come in handy in your situation. 🙇