Hello! Let's dive into the world of web apps.
Defining a Web App
A web app is typically browser-based. Key characteristics include:
- Platform independence (no reliance on specific operating systems)
- Runs on any device, including mobile
- Internet-dependent (at least for initial loading)
- Dynamic content (frequent updates)
Technologies Behind Web Apps
Essential technologies for web apps include:
- Frontend: HTML, CSS, and JavaScript (WebAssembly is emerging but not yet widespread)
- Backend: Various languages like Node.js, Python (with Django or Flask), Java, etc.
- Databases: SQL and NoSQL options (e.g., MongoDB, PostgreSQL)
Examples of Web Apps
Some popular web apps we use daily:
- Gmail
- Google Docs
- Trello
- Slack (even when used as a desktop app, it's web-based)
- Online banking
- Admin dashboards
Security in Web Apps
Web apps benefit from built-in security features, such as HTTPS for encrypted data transmission. This pre-existing infrastructure saves developers from building security measures from scratch.
What's Not a Web App?
To better understand web apps, let's look at what doesn't qualify:
- Native mobile apps
- Native desktop apps
- Command-line interfaces
- Embedded systems (e.g., microwave software)
- Most games (though some use web technologies)
- Simple websites**
- SEO-friendly websites** (these often prioritize static or server-rendered content)
The Server-Side Rendering Debate
** There's ongoing discussion about server-side rendering (SSR) versus client-side rendering for web apps. Some companies push for more SSR, partly because they have an incentive to sell server infrastructure. However, for many web apps, client-side rendering is often sufficient and can provide a better user experience.
Loading Times: A Reality Check
Let's consider loading times for web apps:
- First load: ~7-8 seconds
- Subsequent loads: ~1 second (thanks to caching)
For most web apps, these loading times are acceptable. Users typically don't mind waiting a few seconds for an app they'll use for an extended period.
The Hybrid Approach
At Quave, we often use a hybrid approach:
- A website to present and sell the idea (optimized for SEO)
- A web app for the actual product (optimized for user experience)
This combination allows us to leverage the strengths of both approaches.
Conclusion
When deciding on your app's architecture, focus on your specific needs rather than following the latest trends from big tech companies. Consider your app's requirements and user experience goals, and choose the approach that best serves your project.
Remember, technology is a big industry, and companies must make money. However, your priority should be solving your unique problems, not aligning with someone else's business model.
Think critically, and make decisions based on your app's principles, not the latest market push from big companies.
See you in the next one! Bye bye.
This content is part of the AI Proof Dev Web Apps course.
Top comments (7)
Simple websites and SEO-friendly websites can be Web Apps.
Try our website greenersoft.fr and you'll see that it's possible, even with a static website, which is what our website is. And it's even a PWA!
Furthermore, to say that “Some companies push for more SSR, partly because they have an incentive to sell server infrastructure” is an exaggeration.
As far as we're concerned, client-side rendering is a bad thing from an environmental point of view, because in addition to being slow, it consumes too much energy. A web browser is extremely optimized for displaying HTML, so running JavaScript to produce the HTML of a web page is ridiculous. See a demonstration on our site here.
The HTML-first approach is the future.
Yes but we don't talk about simple websites. Webapps != Websites and PWA is a specific term, while webapps refers to a complex app being accessible through web technologies. We talk about things like slack, canva, figma. This is CSR at its peak level and there are lots of optimization techniques for CSR as well to optimize loading, preloading, initial HTML etc. which is why the hybrid approach is the most realistic for these apps.
Finally it's not an exaggerating at all that companies want to make profit and if Ssr means more profitable then it's a no brainer to push Ssr.
Exactly. And that's fine for companies—everyone wants to make money. But we (developers) shouldn't base our decisions on others' incentives. We should focus on our own goals.
You have a strange definition of what a Web App is. A Web App is accessible via a URL, so it's basically a website! And conversely, you could say that a Web site is a Web application! Anything that runs in a Web browser is a Web application.
Eventually, it's in terms of functionality that we could say: this is a Web App and this is a Web site!
Whether it's rendered in JavaScript or HTML is another story.
And look at Hey, an equivalent of Gmail (a Web App). Well, it's not client-side rendering, but HTML-first.
True, but in the context of my text and AI Proof Dev courses, we treat Web Apps and Websites/SEO-Friendly as separate issues. We use different stacks and decision models for each.
Maybe a bit exaggerated, but not much. It's actually the primary reasons companies such as Vercel + Netlify (and others) push this.
This is not accurate. JavaScript is usually (= framework such as Angular or React) not used to produce HTML (e.g., generate a string and then set
innerHTMLor similar), but rather manipulate the DOM. There is a huge difference. Parsing HTML is actually quite expensive and just manipulating the DOM is not (it's super cheap; what's expensive is re-rendering, i.e., taking the DOM + CSSOM to produce the render tree = drawing the page). I get your point - but I think its a bit parallel to what the author is talking about (you both have valid points, but I am not sure if both refer to exactly the same scenarios).Of course it does, React or Angular generate HTML, obviously not with innerHTML but with createElement() inserted into the DOM with append() or other DOM manipulation functions. And generating HTML elements in this way is far more expensive than parsing HTML text and producing HTML elements ready to be injected into the DOM.
This is what we demonstrate here. The test shows that starting from a JSON describing a list of items to produce a version in HTML elements ready to be added to the DOM is much slower than starting from a block of HTML text parsed by parseFromString().