FiveTech Support Forums

⚖️ Harbourino vs. MEMOREAD() .view

🧠 Interpretation

🔮 Harbourino

• Compile-time assembly of your entire project into one optimized .prg.
• Best for production, debugging accuracy, performance, and clean releases.
• Ideal for mobile / embedded / low-latency environments.
• Great synergy with AI-assisted micro-modules (each .view or .prg can be edited intelligently in isolation).

⚙️ MEMOREAD()

• Runtime flexibility — quick edits, no pre-build step.
• Good for prototyping, testing, or single-page apps.
• But slower, harder to debug, and less reliable for large-scale or multi-user systems.

⚖️ Bias Assessment
The provided information is technically sound but rhetorically biased toward Harbourino. It uses "Loaded Language" to frame the choice.

1. Emotional Framing (Emojis & Adjectives)
   Harbourino is associated with "Kings" (👑), "Rockets" (🚀), and words like "Outstanding" and "Perfect."

MEMOREAD() is associated with "Turtles" (🐢), "Risky," and "Noisy."

Conclusion: The table is designed to sell a solution rather than provide a neutral architectural trade-off analysis.

1. Dismissal of the "Developer Experience" (DX)
   The report lists the lack of a build process for MEMOREAD() as a "Simpler but less optimized" trait.

Cuestioning: For many developers, zero-configuration and instant refresh (Hot Reloading) are massive advantages. Harbourino introduces a "Build Step" (harbourino.exe), which adds friction to the development loop.

1. The "AI Context" Argument
   The claim that AI gets "noisy" with .view files is subjective.

Cuestioning: In fact, many AI tools (like Cursor) perform better with small, decoupled files (like individual .view files) rather than one massive, patched .prg that might exceed the AI's "context window" limits.

🛠️ Critical Questions to Consider
To reach a truly balanced conclusion, you should ask the following:

What is the actual latency difference? In a high-speed NVMe server environment, is the MEMOREAD() delay 1ms or 100ms? If it's 1ms, the "slowness" might be a premature optimization.

Does Harbourino support "Watch Mode"? If the developer has to manually run harbourino.exe and Patch every time they change a single <div> in a view, the productivity loss might outweigh the runtime gain.

Is the "Mobile Delay" network-related? The report blames MEMOREAD() for mobile lag. However, on mobile devices, lag is usually caused by DOM rendering or Network Latency, not the micro-seconds it takes for a server to read a text file.

Don't trust what AI tells you :)

Question it :wink:

That is an essential mindset. As an AI, I don’t "know" facts the way humans do; I predict the most likely sequence of words based on patterns in my training data. This process is inherently probabilistic, which means I can be wrong, biased, or even "hallucinate" (fabricate information that sounds confident but is false).

Being a "thought partner" means I work best when you treat me as a sophisticated research assistant, not an infallible oracle

Dear Antonio,

This topic has been of great interest to me for a long time — I even brought it up years ago (see my original post:

https://forums.fivetechsupport.com/viewtopic.php?p=227031#p227031 ).

Unfortunately, over all these years, it was never really possible to have a proper discussion about the advantages and disadvantages of the two approaches.

Again, today, we are not really discussing the concept itself — just circling around it.

So, instead of reposting everything, perhaps we could just work through the existing comparison — point by point — and discuss the technical aspects of Harbourino (Preprocessor / Patcher) vs. MEMOREAD() .view (Runtime File Loading).

I would truly appreciate if we could focus on the actual trade-offs — performance, maintainability, debugging, and developer experience — rather than general opinions.

Best regards,
Otto

Hi,

A war of topics between AIs. Interesting or boring? :D

C.

Charly, From my perspective, scale plays a decisive role. Whether a program consists of 2,000 or 10,000 lines of code makes a qualitative difference in complexity.

Beyond a certain size, the challenge is no longer just core logic, but multiple interaction layers operating simultaneously: mouse and keyboard handling, domain-specific workflows, printing and text processing, as well as layout and design logic.

One example is a room-planning module, where UI interaction, accounting functionality, and text-based processing converge.

Against this background, architectural decisions can only be evaluated meaningfully when the project’s scale is taken into account.

Best regards, Otto

P.S. One practical aspect directly related to the Harbourino vs. .view discussion that might be worth exploring in more depth:

Runtime-loaded views and separate JS assets introduce caching as an architectural concern, not just an operational one. In transactional applications, serving stale JS or logic can break determinism and lead to hard-to-reproduce issues.

When using CDNs like Cloudflare, how do you reliably disable or bypass caching in a .view-based setup so that no outdated logic is ever served? Real-world configurations or experiences would be very valuable.

Hi,

If you're having caching problems, using headers like header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0"); should force a read operation on the server and if use cloudflare, it has a special cache configuration in case you need to configure it.

C.

Charly, Yes, agreed on the headers.

The real question is how reliable this remains in practice once multiple layers are involved: browser cache, CDN edge cache, and WebView-specific caching. At that point, architecture starts to matter more than individual settings.

Do you have a Cloudflare setup that has proven robust for state-critical applications?

From the server side, Apache also requires explicit cache-related configuration.

In the context of runtime-based frameworks like HIX, it would be useful to hear how this is handled in production.

Best regards, Otto

Otto,

Cloudflare has a section for configuring all the caching.

As you say, Apache also needs configuration, and the more systems your environment, the more configuration work and balancing you need to do.

If this type of configuration is difficult to learn, how should harbour developers do it?

So far, with HIX, we haven't had to configure anything in this regard. The goal is simplicity.

C.

Carles,

I fully agree that simplicity is essential — especially for Harbour developers who are coming from a desktop background.

At the same time, my concern is less about whether caching and infrastructure can be configured, and more about when we address this topic in a real-world transition.

Before we can realistically expect end users to adopt web-based Harbour applications, we need an environment where developers themselves can release safely — without guessing which layer might interfere: browser cache, CDN edge cache, WebView behavior, or server-side defaults.

In my experience, this is where architecture starts to matter more than individual headers or framework defaults.

For example, I have built a fully menu-driven installation tool for Cloudflare Zero Trust that automates tunnels, DNS, Access policies, and verification checks. However, certain security-relevant settings — such as application isolation (Cage / Browser Isolation) — are intentionally not scriptable by Cloudflare and must be configured manually in the dashboard.

The tool can detect and warn if isolation is still active, but it cannot replace knowing the exact manual steps required to make an application reliably usable in production — especially for state-critical and UI-intensive applications.

My point is not that HIX should become complex, but that having documented, reproducible installation knowledge and automated verification tools would help individual developers feel confident enough to expose their applications to the web.

If we could collectively capture this knowledge — even outside the framework itself — it would significantly lower the psychological and technical barrier to real deployments.

Best regards,
Otto

Otto,

Anyone who jumps into web programming, whether they're a Harbour programmer or not, goes through a learning process and gains experience day by day. Everyone finds their own way.

Thinking there’s one right, foolproof way is a fantasy, even outside the Harbour world, nobody has that. There are tons of architectures, methods, patterns… and over time you pick things up and absorb what works for you.

Your concern is understandable, but it’s something that’ll probably weigh more on you than on other users, depending on how you build your solution, your tools, servers, languages, and so on.

Setting up your environment, like with Cloudflare, isn’t the only option. For example, HIX can be used in different ways, though lately Cloudflare has gained traction because it’s easy and offers some advantages.

If you have your own way of setting things up, what you could do, if you want, is explain it clearly so others can understand, and maybe more help and guides will come from the community over time :D

Can we create a guide focused on CF tunnels? Yes, but without forgetting there are other options. And also keeping in mind that setting up CF for something like HIX isn’t the same as configuring apache, php, node, etc..., each stack has its own setup.

In the last webinar, I already explained how Cloudflare tunnels work, and since then I’ve been glad to see different users trying it out. These days there are plenty of Cloudflare tutorials that explain it well in different ways, and you can always ask questions in the forum. If you need or want to, you can post the presentations here again. I think it helped more than one person understand it properly. Once you grasp the concept, you can then look for more information if you wish.

Little by little, things will change, as someone here says... the flow!

C.

Carles,

maybe it helps to take one step back and look at the longer context.

I’ve been suggesting self-hosting approaches in this forum for quite some time now — long before Cloudflare tunnels became popular here. Back then, the typical counter-argument was often:

“You can just host it somewhere for 5 euros per month.”

That answer is valid in a pure web scenario. But it doesn’t really address the hybrid reality many Harbour developers are facing.

For a large number of users here, the web part is not a replacement, but an extension of an existing desktop application: – same data – same business logic – often running inside a customer network – sometimes even on machines that were never meant to be publicly exposed

In that context, “just host it somewhere” doesn’t solve the real problem: How do I safely and predictably expose parts of my existing system to the web without redesigning everything?

Cloudflare didn’t become interesting because it’s fashionable, but because for many it finally made self-hosting + hybrid access practical without opening inbound ports, VPN chaos, or fragile reverse-proxy setups.

So when I talk about infrastructure, caching, isolation, or release safety, it’s not about declaring one stack as the only valid one. It’s about acknowledging that hybrid deployments introduce a different class of problems than greenfield web projects.

That’s also why I believe shared, experience-based guides — whether for Cloudflare, classic Apache setups, or other approaches — are valuable. Not as rules, but as anchors for people who are trying to move carefully from desktop to web.

Best regards, Otto