Skip to content

7 Web Novel Readers Compared: Open-Source vs Commercial | 2024 Technical Deep Dive

Introduction

Web novel enthusiasts have a growing number of tools to streamline their reading experience. From mobile apps that aggregate chapters from fan-translation sites to official platforms with proprietary content, the ecosystem of web novel reader software is diverse. This post provides a developer-focused analysis of the most relevant projects – both open-source and commercial – comparing features, architectures, and target audiences. We'll break down how these competitors stack up against our project (a new entrant in this space), identifying strengths, gaps, and opportunities. Advanced users and potential contributors will gain insight into implementation details, scalability considerations, and best practices for building a web novel reader.

Landscape of Web Novel Readers

Web novel readers generally fall into two categories: open-source community-driven projects and commercial platforms or apps. Below is an overview of key examples in each category:

Open-Source Projects

  • Shosetsu (Android) – An extendable light novel reader inspired by Tachiyomi. It features a fully customizable reading interface and an update tracking system for new chapters (1). Shosetsu uses a plugin/extension model with modifiable Sources that host numerous source adapters (2: Shosetsu - The extendable novel reader for Android. - Fossdroid) (3). (Note: the project was archived in 2022, indicating maintenance challenges.)
  • LNReader (Android, React Native) – A Tachiyomi-like open-source light novel reader built with React Native (4). It supports a ton of sources and even integrates with the Novel Updates index for discovery (5). LNReader offers features like global search across sources (though early versions had some slowness in this area (5)) and library management similar to Tachiyomi. Active development and community involvement (via Discord and GitHub) aim to address bugs and expand source coverage.
  • QuickNovel (Android) – A fast, ad-free FOSS app focused on downloading novels for offline reading (6). QuickNovel supports multiple sources (though fewer sites than LNReader according to user feedback) and is praised for its speedy search and downloads (7). It doubles as an EPUB reader for local files (6). However, it lacks an auto-update mechanism for new chapters and some find its UI less user-friendly (7).
  • NovelLibrary (Android) – An older open-source project that serves as a "one stop for reading all novels" (8: NovelLibrary/README.md at master - GitHub). It emphasizes offline capability – allowing users to download novels and bookmark their progress (9). NovelLibrary provides recommendations of popular titles and built-in search for novels across various catalogs (10). While innovative for its time, it may not support as many modern sources and features as newer apps.
  • NovelDokusha (Android) – A modern web novel reader written in Kotlin (Jetpack Compose). It supports multiple source websites and even multiple novel databases for search (11) (e.g. searching by title or category across indexes). Notable features include infinite scroll reading, custom fonts and sizes, live translation, and text-to-speech with adjustable voice settings (12) – even background audio playback for listening to chapters. It also supports local EPUB reading, easy backups, and dark mode (13), catering well to power users.
  • Miru Project (Android, Desktop, Web) – A versatile open-source app (built with Flutter) that aggregates videos, comics, and novels under one roof (14). For novels, Miru supports an extension system similar to Tachiyomi's, enabling community-maintained sources. Being cross-platform (Android, Windows, Linux, and Web) (15: Miru) (16), Miru showcases how a single codebase can deliver a web novel reader on multiple devices. Its broad scope means it's not novel-specific, but it demonstrates scalable design by modularizing media types.
  • WebNR (Web/PWA)
    A modern web novel reader built with Next.js and TypeScript
    (17: WebNR - Web Novel Reader).
    Unlike other projects, WebNR takes a pure browser-based approach, requiring no installation. Key features include: completely offline-capable PWA with privacy focus (no login required, all data processed locally), multi-source support (local files, URLs, multiple novel sources), cross-source search with automatic source syncing, and rich reading experience (paged/scroll modes, themes, progress tracking).

WebNR demonstrates an alternative technical approach: leveraging modern web technologies (like IndexedDB storage, Web Speech API) to achieve near-native app functionality while maintaining lightweight and cross-platform characteristics. While this approach may not match native apps in some performance aspects, it excels in accessibility (one-click usage) and ease of use.

Commercial and Closed-Source Solutions

  • Official Web Fiction Platforms – Apps like Webnovel (Qidian) and Wattpad provide access to huge libraries of web fiction. Webnovel's app is one of the most downloaded in this genre (18: What is the best website/app to read almost every novels? - Reddit), offering a polished reading experience with offline reading, comments, etc. However, these platforms are closed ecosystems – content is locked to what they host (e.g. licensed translations or user-generated stories) and they don't aggregate from external sources. They cater to casual readers who stick to one platform's content.
  • Tapas and Radish – These are similar to Wattpad in that they host original or licensed serial novels. Their apps offer rich features (custom readers, community interaction, subscriptions) but again lack the ability to pull in content from outside sources. For a reader interested in fan-translated web novels across the internet, such apps are not a one-stop solution.
  • Generic eBook Readers – Traditional e-reader apps (Kindle, Google Play Books, Moon+ Reader, etc.) can be used for web novels if the user manually obtains EPUB/PDF files. They excel in rendering and offering features like bookmarks, dictionary, and syncing – but they do not fetch content from web novel sites. Users must rely on manual downloads or conversions, so while these are great for readability, they don't meet the aggregation needs of web novel fans.
  • Ad-Supported Aggregator Apps – There are numerous closed-source Android apps on app stores that scrape web novel sites (similar to the OSS ones above) but are run by companies or indie devs for profit. For example, Webu – Web Novel Reader markets itself as an "all in one" novel tracking app (19: Webu - Web Novel Reader - Apps on Google Play), and apps like Light Reader, Fizzo Novel, or MReader offer huge catalogs of popular novels with a polished UI. The downside is often intrusive ads, potential legal gray areas, and little transparency. Unlike open-source projects, users cannot extend or fix these apps if a source breaks. Power users tend to avoid these in favor of community-driven readers that give them more control.

Feature-by-Feature Comparison

To understand how these readers stack up, let's compare their features and how our project intends to differentiate. We'll examine content sourcing, reading experience, offline capabilities, extensibility, and other advanced features.

Content Sources and Aggregation

One of the most important aspects of a web novel reader is the ability to pull content from many translation sites and keep it updated. Open-source readers generally shine here:

  • Supported Sources: Our project is targeting a wide range of novel websites through a plugin system. Competitors like LNReader already support dozens of sites and even tap into Novel Updates (the community index for fan translations) to discover novels (5). This means LNReader users can search a title once and find which source has it – eliminating the need for "50 million tabs" in a browser (20: lnreader vs shosetsu - compare differences and reviews? - LibHunt). QuickNovel, by contrast, supports fewer sources (optimized for a core set) (7), trading breadth for speed. Shosetsu, with its extension Sources, also had a plethora of sources contributed by the community (3). Our project will aim to match or exceed the source coverage of these tools, ensuring that even niche or new sites can be added easily.

  • Library Management & Updates: All the open-source apps provide a library to bookmark novels and track new chapters. Shosetsu's update system, for example, keeps track of new chapters across your library (1). LNReader and NovelLibrary similarly allow adding novels to a personal library and notify or highlight when updates are available. QuickNovel's current weakness is the lack of an auto-update notification (7) – users may need to manually refresh or rely on external cues to know when a new chapter is out. In our project, robust update tracking will be a core feature – likely integrating push notifications or background checks, so power users never miss an update. We also plan to integrate with novel indices (similar to LNReader's Novel Updates integration) to help users discover and follow novels from a centralized list.

  • Search and Discovery: When it comes to finding new novels, NovelLibrary introduced a neat idea by recommending Popular & Top-Rated novels to the user (10). Our project can incorporate a discovery section as well – possibly curated lists or trending titles aggregated from multiple sources. Additionally, a global search across sources is a must-have: LNReader's global search was initially slow when querying "a ton of sites" at once (5), but improvements are underway to make it faster. We will employ efficient search strategies (e.g., parallel requests with throttling and caching of results) to ensure that even searching across 50+ sources feels snappy.

Reading Experience and Customization

Power readers often spend hours in the app, so the reading interface must be customizable and feature-rich:

  • UI Customization: All serious readers provide basic controls like font size, screen brightness, and themes. Shosetsu emphasized a fully customizable reader (1), and NovelDokusha extends this with options for custom fonts and infinite scroll reading (12). Our project will likewise offer multiple reading modes (paged vs continuous scroll), font and line-spacing adjustments, day/night themes, and user-defined color schemes. Advanced typography settings and CSS adjustments (for parsing sites that have inconsistent formatting) are also on our roadmap.

  • Live Translation: A standout feature of NovelDokusha is its live translation capability (12). This likely hooks into translation APIs to on-the-fly translate content (useful for readers dipping into raw novel sites in other languages). Most competitors do not have this feature yet; implementing this in our project could be a game-changer for users who read ahead on raw sources. It does come with challenges (API limits, preserving text formatting), but the potential to broaden content access is huge.

  • Text-to-Speech (TTS): Consuming novels via audio is popular among power users (listen while commuting, etc.). NovelDokusha includes built-in text-to-speech with background playback and voice customization (12). Many other readers lack native TTS – users would have to use external apps or accessibility features. We plan to build TTS support into our reader as a first-class feature. By leveraging platform TTS engines (or even offering a plugin for Google Wavenet or similar for higher quality), users can have any chapter read aloud, with controls for speed and voice. This not only improves accessibility but also sets our project apart.

  • User Interface and UX: In terms of overall UI design, LNReader (React Native) has been noted for a clean interface, whereas one Redditor found QuickNovel's UI "less user friendly" (7). While UI preferences are subjective, our project aims for a modern, intuitive interface using responsive design principles so it feels natural on both mobile and desktop (if applicable). Technologies like Flutter or React (if we choose a web-based approach) enable fluid animations and a consistent look across devices, much like Miru's cross-platform UI (16: Miru Project: A versatile application that is free, open-source, and ...). A polished UX with attention to details (like scroll position memory, seamless chapter transitions, and clutter-free screens) will cater to power users who appreciate efficiency.

Offline Reading and Downloads

One big draw of these apps is the ability to save chapters for offline reading, especially given the unreliable nature of some fan-run websites:

  • Batch Downloads & Formats: QuickNovel's primary function is downloading novels, even offering entire books in EPUB format (6: LagradOst/QuickNovel: Android app for downloading novels - GitHub). Similarly, most open-source readers let you save chapters or entire series locally. NovelLibrary was built because the creator couldn't find an app that allowed downloading for offline use (9: Light Novel Reader with download and bookmark features - Reddit) – highlighting how essential this is. Our project will support batch downloads (with controls to, say, download the next X chapters or full novel) and possibly export to common formats like EPUB or PDF. This provides flexibility for users who might want to archive or transfer their libraries.

  • Offline Library Management: Once chapters are downloaded, the app should manage storage smartly. Tachiyomi, for instance, stores images efficiently; for text, we will implement a lightweight database or file-based storage for chapters. Caching strategies (storing recently read chapters in memory, prefetching next chapters) can greatly improve the reading flow. We'll take cues from existing projects on handling large volumes of text. For instance, ensuring that an entire novel with hundreds of chapters doesn't overload memory – possibly by loading content on-the-fly and using placeholders for unloaded chapters in an endless scroll. This is where having a robust caching and data access layer is critical.

  • Sync and Backup: A gap in nearly all current solutions is cloud sync. Typically, apps like LNReader or Shosetsu rely on manual backups (exporting a JSON or SQLite of your library). NovelDokusha provides easy backup & restore options (13: nanihadesuka/NovelDokusha: Android web novel reader - GitHub), but it's still manual. In our project, we see an opportunity to implement optional account-based sync, where reading progress and library lists can sync across devices (perhaps via a privacy-respecting cloud service or self-hosted server). Developers and advanced users would appreciate this, as they could, for example, read on their phone and continue on a tablet or PC without hassle. Implementing sync introduces complexity (server component, conflict resolution), so it could be an opt-in feature for those who want it.

Extensibility and Developer Friendliness

Since our analysis is developer-focused, it's important to compare how extensible each solution is and how they invite contributions. Our project's success will heavily depend on engaging power users and developers to extend it with new sources and features.

  • Plugin/Extension Architecture: Shosetsu and Tachiyomi pioneered the idea of extension packages for sources. Shosetsu allows developers to host extensions in Sources, which users can then load into the app (3). This decouples source code from the core app – a best practice that we plan to adopt. LNReader also supports multi-source plugins (they maintain a separate lnreader-plugins source). Embracing a similar architecture means our project can scale gracefully: new sources or content formats can be added by the community without requiring a full app update. We will provide a clear API or SDK for writing these extensions. For example, a simple interface where a developer writes a parser for a site (defining how to list novels, get chapters, parse text) and then package it for our app. This approach has proven effective at harnessing open-source contributions (3).

  • Open-Source Contribution Model: All the OSS projects listed have their code on GitHub/GitLab and encourage issues or pull requests. The Shosetsu team explicitly welcomed help from others, and LNReader as a community fork thrives on collaboration now that the original dev is less active. Our project will actively target developers for contributions by maintaining thorough documentation (e.g. how to add a new source, how the architecture is organized), and using a familiar tech stack to lower entry barriers. For instance, a web-based stack (TypeScript/Node for scraping, Electron or React for UI) might attract web developers who are also novel fans. Alternatively, if using a mobile stack, we might choose Flutter or React Native to appeal to a broad dev base rather than only Android-Kotlin experts. The goal is to build an inclusive developer community where power users with coding skills can easily become contributors.

  • Modularity and Code Architecture: Looking at existing projects: LNReader's use of React Native means much of the code (aside from native modules) is JavaScript, and they likely use a Redux-like state management (their repo references Redux-thunk and MMKV storage (4: LNReader/lnreader: Light novel reader for Android. - GitHub)). NovelDokusha being Kotlin uses modern Jetpack components. Miru's Flutter approach enforces a clean separation of UI and logic out of the box (and the extensions are probably written in Dart or use a bridging mechanism). These architectural choices influence how easy it is to extend or optimize the app. Our project will employ a clean architecture with separation of concerns: one layer for fetching data (e.g. a library of source modules), one for domain logic (library, updates, etc.), and one for the presentation (UI). This not only makes the app maintainable and testable, but new features (like adding a bookmarking system, or a new view for recommendations) can be developed in isolation. We'll document and use best practices from frameworks – for example, using dependency injection to swap components (if someone wanted to replace our parser with a more efficient one, they could). Developers contributing will find the project structured and scalable, not a monolithic tangle.

  • Performance and Scalability: Extensibility isn't just about code structure, but also about scaling with content and users. A challenge observed in LNReader was that a naive global search across ~30 sources was slow (5); as more sources are added, such features can bog down. Our architecture will favor scalability – for instance, running network requests concurrently with limits and timeouts, using caching for repeated searches, and possibly allowing users to select which sources to include in a global search (to reduce unwanted load). Memory and storage use will be profiled with large libraries (hundreds of novels, thousands of chapters) to ensure the app remains responsive. We'll also consider the offline-first design – the app should gracefully handle source websites going down or being blocked. Techniques like queuing failed chapter updates for retry, or providing alternate mirror sources, can improve robustness. These are areas where we've learned from existing apps' limitations and will strive to improve.

Architectural Approaches and Best Practices

Diving deeper into the technology side, let's examine how different projects are built under the hood and what best practices our project will adopt:

  • Technology Stack:
    Open-source novel readers span various tech stacks. Traditional ones like Shosetsu used native Android (Java/Kotlin) which integrates tightly with Android's ecosystem (e.g., using Android's SQLite and WebView/Jsoup for parsing HTML);
    LNReader chose React Native, leveraging cross-platform JavaScript but focusing on Android initially;
    Miru's use of Flutter/Dart allows one codebase to target mobile, desktop, and web;
    while WebNR demonstrates the viability of a pure web stack (Next.js/TypeScript/IndexedDB), achieving near-native experience through PWA.
    Each approach has merits: native code can be more performant for heavy tasks, while cross-platform frameworks reach more users and attract web-oriented contributors. For our project, a key decision is choosing a stack that balances performance with approachability. If we choose a Web/Electron based approach, we can reuse tons of web-scraping libraries and make the UI easily hackable via HTML/CSS – but we must then optimize for performance (to avoid Electron bloat). If we choose Flutter, we gain native performance and multi-platform reach, but require contributors to learn Dart. Our decision will be guided by the kind of contributors we target (web developers vs. mobile developers) and by the performance needs (rendering long text is less intensive than images, so even web tech can handle it with the right optimization).

  • Content Parsing and Caching: All these apps essentially act as specialized browsers that parse HTML content from novel sites. Best practices here include using well-tested HTML parsing libraries (e.g., Jsoup in Java/Kotlin, Cheerio in Node.js) and sanitizing the content (removing ads, scripts, irrelevant elements). Tachiyomi's extensions often contain site-specific logic built on common helper classes, and we plan something similar: provide a framework for parsers so developers don't reinvent the wheel for common site patterns. For caching, since novel chapters are text (typically small in size relative to images), we can cache aggressively on disk. The challenge is invalidating that cache when chapters update – we might implement an etag or last-modified check if the source provides it, or fall back to user-triggered refresh. Another best practice is to store a normalized form of chapters (plain text or simple HTML) to display consistently in the reader, regardless of the source's original HTML/CSS. This ensures our reading theme and customization apply uniformly. We learned from Shosetsu and others that the reading view should be independent of source styling – hence a cleaning/normalization step is crucial.

  • Optimizing Performance: As the number of sources and size of libraries grow, performance tuning becomes vital. LNReader's improvement in global search suggests using parallelism and possibly limiting how often full searches run (21). Our project could implement a search index: periodically scrape updates from sources in the background and index titles/keywords locally, so searches are instant (this is ambitious and might not scale easily, but it's an idea to explore for power users who demand instant results). On the UI side, using virtualization for lists (to handle huge chapter lists without lag) and efficient diff algorithms for updates will keep the app smooth. We will also use profiling tools (Android Profiler, Chrome DevTools, Flutter DevTools, etc., depending on stack) to find bottlenecks – be it a slow regex in a parser or an inefficient database query – and address them. The experience of existing apps shows that hitting an API like Novel Updates for search can save time vs hitting dozens of sites individually (5); hence, integration with aggregator APIs or RSS feeds (when available) is a best practice we'll implement to reduce overhead.

  • Scalability Considerations: If our project gains traction, thousands of users might be hitting the same source sites through our app. While each user's app is client-side, this can appear like a DDoS to smaller websites if not careful. One approach is to stagger or cache popular content: for example, if many users search for "Popular Novel X", instead of each app scraping the site, a maintained community proxy or cache could feed results. This enters the realm of a hybrid architecture (client + optional cloud service) and raises complexity, but it's worth noting as a future consideration. From a code perspective, scalability means writing the source adapters in a way that's easy to update when sites change. Tachiyomi and Shosetsu handle this by having extension updates separate from the app – we will do the same. It's unrealistic to update the entire app for a single broken source; modular extensions that can be versioned and updated independently are essential for long-term scalability of the project (3).

  • Cross-Platform Sync Architecture: Earlier we mentioned implementing sync as a differentiator. Architecturally, this could be done via a lightweight server or even using an existing cloud service (like Firebase or Cloud Firestore) to store user library metadata (not the content itself, which is sensitive). Security and privacy are paramount here – we might allow users to bring their own storage (e.g., WebDAV, Dropbox, etc.) for syncing, similar to how RSS readers like Feedly or Nextcloud work. This kind of extensibility (allowing different sync backends) would again appeal to developers who might contribute plugins for their preferred storage. It also aligns with the interests of power users who often demand control over their data.

Challenges in Existing Solutions and How We'll Improve

No solution is perfect. By examining pain points in current readers, we can identify what to avoid or improve in our project:

  • Maintenance and Longevity: A common challenge is maintaining source adapters. Websites change frequently, and volunteer maintainers can burn out. We saw Shosetsu get archived and LNReader suffer from bugs when the main dev became busy (7). To mitigate this, our project will try to distribute the load: by making it easy for the community to submit fixes (simple scripts or configuration changes for minor site updates), and possibly by leveraging scraping frameworks that can handle minor DOM changes robustly. We will also keep an active presence in the novel reader community (forums, Discord) to recruit new maintainers continuously. A plugin rating or health system (flagging which sources are broken/outdated) could be implemented so users know the status, and devs can prioritize fixes.

  • Legal and Ethical Issues: Many open-source novel readers operate in a gray area with regard to copyrighted translations. Tachiyomi faced a threat from a content provider leading to some source changes (22: Tachiyomi is dead, migrate to forks · forum | osu! - ppy). Our project, while technical in focus, must be conscious of this. We won't host any content ourselves, and we might implement a resilient extension hosting approach (like Tachiyomi's approach of letting third parties or the community host extension lists). This decentralized model ensures the core project isn't easily shut down due to one problematic source. It's a challenge existing solutions have had to navigate quietly; addressing it openly with contributors (e.g., having guidelines on what sources to include) will help our project avoid sudden disruptions.

  • User Experience Gaps: Some users pointed out features they couldn't find in any app, which is why threads like "Need LN reader app recommendations" exist. For example, a user trying QuickNovel and Shosetsu still lacked certain needs (23: Need LN reader app recommendations - Lemmy.World) (possibly referring to TTS or quick preview of content without full download). We've already planned features like TTS, but we should also consider in-app browsing for cases where a novel isn't in any source list – maybe a built-in web view where users can read on a site and then easily import that novel if it becomes supported. Another gap is richer metadata: Novel Updates integration helps, but none of the apps show, say, detailed novel descriptions, author info, or community ratings in-app. We could aggregate such metadata (from Novel Updates API or others) to give more context to each novel in the library. That enriches the user's experience and helps our project stand out as not just a scraper, but a full-fledged novel library manager.

  • Performance Limitations: Some existing readers can struggle on older devices or very large libraries. As mentioned, global searches can lag, and loading thousands of chapters might crash lesser devices. We must prioritize performance from day one: using background threads for heavy processing, avoiding memory leaks (especially in Android, where some Java-based apps might leak contexts), and providing settings to turn off expensive features (like animation or auto-updates) for those who want a lighter experience. If we use a high-level framework (RN or Electron), we'll monitor its overhead and possibly contribute improvements upstream or use native modules for critical sections (e.g., a native parser for speed). Scalability testing with simulated libraries will be part of our development cycle, something that hobby projects might not rigorously do. This proactive stance on performance will prevent the kind of lag issues noted in early versions of our competitors (21: Releases · LNReader/lnreader - GitHub).

  • Extensibility vs. Simplicity: While power users love extensibility, too much complexity can deter average users. Tachiyomi forks are sometimes seen as "by nerds, for nerds" due to requiring manual extension installs and configurations. We aim to strike a balance: onboarding new users with a ready-to-use set of popular sources (pre-bundled or easily fetchable) while giving advanced users the option to dig into extension repos and custom sources. We might implement a one-click "Add new source" from a curated list (like an app store for extensions) to simplify what is a manual process in some apps. This is both a UX and architectural challenge (ensuring dynamic loading of code or rules), but solving it will greatly widen our appeal without alienating the technical community.

Conclusion

Building a web novel reader that caters to both casual readers and tech-savvy power users is a challenging but rewarding endeavor. Our analysis of existing solutions – from open-source projects like Shosetsu, LNReader, QuickNovel, NovelDokusha, and others, to commercial platforms – has highlighted key considerations for our own project. We see clear opportunities to differentiate: by combining the breadth of content open-source aggregators provide with a polished, customizable reading experience and modern, scalable architecture.

For developers and contributors, our project is being designed with extensibility and transparency in mind. We're adopting proven best practices such as a plugin-based source system (3), modular architecture, and cross-platform technology to make the codebase inviting and sustainable. Advanced users will appreciate features like live translation and text-to-speech that few competitors offer (12), as well as potential innovations like cloud sync and rich novel metadata integration.

In summary, the web novel reader space has matured through community innovation. From traditional native apps like Shosetsu to modern web solutions like WebNR, each technical approach offers unique advantages. By learning from the strengths and limitations of current readers, we aim to deliver a tool that not only fills the gaps in functionality but also fosters a community of contributors. We invite developers who are passionate about web novels to join us – together, we can build an open-source reader that truly empowers the millions of novel fans who just want to enjoy their stories, whether online or offline, on any device, with all the flexibility the modern web and software development can offer.

Sources: The insights and feature comparisons in this post are backed by observations from project documentation and user discussions in the community. Key references include official project pages and forums for Shosetsu (1: Shosetsu | F-Droid - Free and Open Source Android App source) (3: Sources - Shosetsu), LNReader (5: lnreader vs QuickNovel - compare differences and reviews? - LibHunt), QuickNovel (7: What is LNReader? : r/animepiracy - Reddit), NovelLibrary (10: Download Novel Library (MOD) APK for Android), NovelDokusha (12: README.md - nanihadesuka/NovelDokusha - GitHub) (11: NovelDokusha - IzzyOnDroid F-Droid source), Miru (14: miru-project/miru-app - GitHub), and other relevant resources as cited throughout the text. These sources provide additional details on implementation and features for readers who wish to delve deeper.