I'm a software engineer and I truly believe there is no better way to interact between humans and computers than the command line. I've been coding all my life and I do as much work as I can in the terminal so I'm here to drive you into a quick walk through about WEBCLI and invite you to play with it. It's under development and it will always be. As Adam Savage says "It's a process, not a project".
I crafted: webcli.dev
Is' a command line on the web where I continuously add tools that I use regularly like hashing, parsing, encoding and more and it's also my profile page.
Philosophy behind it
I'm a Linux user so WEBCLI is heavily influenced by it having commands like ls, cd, cat and also having a similar directories structure and navigation.
Currently it has three main mechanisms to use.
- Static content
- Single input/output commands
- Programs
Static content
All static content is implemented via markdown files and I also use this mechanism for site sections. For example the about page is a markdown file. To check it you can do --about which is an alias for cat /home/elias/about.md. You can also explore any other .md file like my resume by doing cat /home/elias/resume.md. It will take the file, parse the content and prompt it in the terminal.
This way I can add lot of text based information with ease in a normalized way.
Single input/output commands
These are commands that you run passing them some input and they will produce an output. For example sha1 abc123 will give you the sha1 hash for the text you pass in. Notice that cat is also one of these input/output commands. You pass the file path you want to check and it'll prompt its content. There are also commands which does not take params and just retrieve some content like uuid which prompts a 128 Bits UUID.
Programs
Small programs can be executed in order to have some more complex experience than just input/output based commands. For example the "feedback" form is implemented as a program, you can open it by doing run feedback. To close any program just press ctr + c. Imagine this as any other command line application like htop or vim in Linux.
Tips a tricks
Explore the directories structure using ls and cd. Aliases are also available with the --aliasName format, for example --upcoming is an alias for cat /home/elias/news/upcoming.md that you can use to peek on upcoming updates.
Review all commands, programs and more using --help.
Technology behind it
WEBCLI is mainly crafted with Svelte, SQLITE and Node. So here are the reasons why I have chosen this stack.
Svelte
I just love its purity, performance and scalability. You can build very diverse Front-end projects with ease. It communicates with a Back-end which is not yet in Svelte Kit but it will be very soon.
The platform based philosophy Svelte follows is what I have been looking for a very long time. You write JS code in JS files, HTML code in HTML files and CSS in CSS files with the power of trully reactive content. If you have used other Front-end frameworks you know what I mean.
SQLITE
You can do way more than you think with SQLITE. It's a robust and very efficient database to the contrary of what some people think. It's absolutely suitable for this kind of single-tenant projects.
I don't need to manage concurrency, no need for a huge database setup and I just need a basic way to store some content. However SQLite can do way more so It allows me to scale when needed.
Node
The Back-end is a Node + Express based API since I wanted to keep the same JS stack all across the project just for simplicity purposes. I could have chosen GO, Python or PHP but didn't want to mix technologies in this case, I want to keep it as simple as possible so far.
The reason I did not build also the Back-end using Svelte Kit is just about reducing costs. I'm hosting the Front-end for free in Vercel but the Back-end is in a different low cost server. WEBCLI is in the very early stages and I want to minimize costs as much as I can in this stage.
Code insights
I'm going to public the source-code in GitHub soon but I'm still brainstorming, debugging and testing so I need some more time until I feel confident releasing the first version.
Analytics and tracking
I believe in user privacy on the web so I don't use services like Google Analytics. I created a 20 lines script that collects anonymous basic information which is publicly available from the browser like user-agent, device type (mobile or desktop) screen size (for responsiveness) and the region used from the timezone setup Intl.DateTimeFormat().resolvedOptions().timeZone. I also preserve the commands that people writes in the terminal like the .bash_history.
This helps me understand where and how WEBCLI is being used.
I'm working to make site stats and bash history public very soon! so anyone can drill down onto this information (check status on --upcoming or --latest). This will be implemented as a program.
Feedback
I would love to hear your thoughts, I take users feedback seriously and I reply to all of them. So feel free to use the --feedback, write answers here, email me or contact me at Github. Sharing the knowledge is not just a way to live, it's the only right way to live.
This is one of my experiments and the result of my every-day desire to build things, not just with Bits but also in the tangible world.
If you reached this line I really want to thank you and I hope to have sparked something on you get down to work on your ideas. Creating keeps the brain focused and healthy.
I don't want to extend any more with words, just check webcli.dev and enjoy!.
Top comments (0)