Web App or LAMP?

Hi guys, and ladies.

I am a freelance and I have a project, a website with a catalog of proudcts, profiles and "mini-stores" within the same website. The boss wants a web app.

All sponsors say Web App.

Is it a good idea, a Web App for public access and production?

Comments

[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.

[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. 🙇

[Alejandro Bonilla]

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

[Angel Daniel Munoz Gonzalez]

I would try to get a little bit more of insights, I'd say when the system expects a lot of user interaction (navigating, clicking, moving, scrolling, updating, etc) I would tend to go for a SPA (Web App), because Web Apps tend to be more flexible in terms of user interaction, at least on my experience.

If the system is more about getting/showing data, with great amount of content inside each view/page I would rather go for a Server Side based option, and add libraries that allow me to add dynamic stuff where it is needed

often, web apps are easier, but that doesn't mean they are the correct solution, in the end whatever you choose to do, if you keep a good design in the backend, the front may be changed and fixed as needed for your client if it ever needs fixing