HN user

cettox

8 karma
Posts8
Comments16
View on HN

This is one of the reasons I've started building https://formpress.org. Seeing the bloat in many form builder apps/services, I've decided there is need for a lightweight and open source alternative.

How we achieve lightweightness? Currently our only sin is, our inclusion of jquery, that is just to have some cross browser way of interacting with DOM, then we hand craft required JS code based on features used in the form builder. We then ship a lightweight runtime, whose whole purpose is to load necessary JS code pieces to have a functional form that is lightning fast. Ps: we havent gone to the last mile in optimizations, but we definteley will. Even with current state, it is the most lightweight form builder out there.

It is open source, MIT licensed, built on modern stack(react, node.js, Kubernetes and Google Cloud) and we are also hosting a freemium version.

I think, there will be ever increasing need and market for lightweight products, as modern IT means a lot of products coming together. So each one should minimize their overhead.

Give our product a go and let us know what you think?

Location: Turkey

Remote: only option (international travel every 2-3 months is possible)

Schedule a chat: https://calendly.com/gkemaldag/interview-with-kemal

Willing to relocate: No

Technologies: Kubernetes, GCP, Node.js, React.js, Terraform

Linked.in: https://www.linkedin.com/in/kemaldagdotjs/

email: gkemaldag@gmail.com

I'm a math graduate, self-taught myself programming. I'm in the web development business for over 13 years. I've been working in every part of the stack, but last 6 years is focused heavily on SRE/Platform Engineering/DevOps related work.

I agree, it is almost ignored in most tutorials and I only see implementation examples in some neat projects, and always left with a wondering mind.

As many pointed that out using Pidgeon Hole principle, it is not practical to create a compression index(A lookup index where you map actual data with some kind of adresses preferably smaller than sequences), using every possible n byte sequence of your data!

Because your index size would be at least equal or higher than your original data.

The only way you get a smaller compression index, you have to look for recurrences, and try to only include most recurring sequences up to a number(there would be a tradeof and an optimal number for compression ratio) and left other sequences uncompressed. Only this way you can achieve compression ratio's smaller than 100%.

Firstly, I loved the project when I see the simplicity of it, secondly, it is good to have alternatives in case that, they got shut down, and maybe go down a wrong path, thirdly I was the first person ever to fix and distribute a working binary version :). BTW, I also linked to repo you mentioned, not to let my users in the dark :)