I think Wails is an alternative to Electron, and it has many advantages that Electron does not have. I like go and I like Wails, in the past month, I developed a static blog writting app. [Swallow]: https://github.com/rangwea/swallow-wails
I think Wails is an alternative to Electron, and it has many advantages that Electron does not have. I like go and I like Wails, in the past month, I developed the same app using A, B, and C separately.
- [swallos-wails](https://github.com/rangwea/swallow-wails)： Base on [wails](https://wails.io/) framework using Go. - [swallow-pywebview](https://github.com/rangwea/swallow-pywebview)： Base on [pywebview](https://pywebview.flowrl.com/) using Python，the frontend base on [alpinejs](https://alpinejs.dev/) and [tailwindcss](https://tailwindcss.com/)。 - [swallow-pyside](https://github.com/rangwea/swallow-pyside)： Base on [Pyside](https://doc.qt.io/qtforpython-6/).
I've been working on an app using ReactJS to build a web UI for a toolset I've written in Go and am really happy with the workflow and overall architecture so far. At present I can run a binary which starts a http server, then access a bootstrap index page with a browser. I use React / JQuery to send REST calls to query the data model and build simple views, or send requests to trigger specific commands.
I've thought about building a separate standalone GUI version with an embedded browser like Atom editor. I've also heard of people embedding webkit for similar results. I'm new to application programming (server and cli util developer, with some web experience), so think this model fits my skillset and workflow better than learning a UI toolkit like Qt (comments suggesting otherwise are welcome).
Is there anything I need to be aware of working with an embedded browser vs what I'm doing now? Specifically, will React's virtual DOM be supported? (From what I understand, the JS engine would handle things like any other browser, right?) I don't need any JS integration with my app itself, I'm happy serving files and REST calls for the data bindings.
Any advice or suggestions is much appreciated, thanks hackers.
I've been working on publishing Lama2, a Plain-Text Powered REST API Client for Teams, for the past few months. Initial work on Lama2 started after my dissatisfaction with existing tools such as Postman/Insomnia. I wanted a text-powered and git-friendly system with a lightweight GUI layer on top so that I could onboard beginners/newcomers quickly into my team while also maintaining control over data. Today, we use Lama2 extensively internal to Hexmos; almost every internal code review tends to have a `.l2` API file attached now. It has worked great for us. More about the approach with Lama2 below.
TLDR: - Approach: "Markdown for APIs" (Design philosophy - https://hexmos.com/lama2/reference/philosophy.html) - Store APIs in plain-text files in human friendly syntax. (Examples - https://hexmos.com/lama2/tutorials/examples.html) - Simple CLI to execute API files - VSCode extension to launch requests right from within your editor - Collaborate with team over git - Good documentation + Extensibility - Import from Postman into Lama2 files - Fun Implementation :) Hand-crafted recursive descent parser in Golang; integrated flexible JSON parser
Background story: The story begins more than a year back, when our team at Hexmos wanted to collaborate on APIs in a simple and straightforward way. Our engineering infrastructure is split into dozens of self-contained software services. We deal with 100s of internal APIs, and so felt a need for a robust workflow for defining, sharing and updating APIs within our teams.
Traditional solutions such as Postman/Insomnia implement the collaboration features within their applications, and also tend to charge a fee for collaboration. We felt using git is the right way to collaborate on APIs, rather than any custom built solution. So, in a matter of 2 days we got a regex-based prototype DSL language to store API files.
Lots of issues cropped up over time, but we kept making improvements to Lama2 as needs arose. We accumulated 100s of API files over time. Then, we decided that the tool deserves to be out there, benefiting teams that want to collaborate on APIs over git. So, to make it happen, first we invested into formalising the grammar, and implementing the DSL as a hand-written recursive descent parser. Then we invested into helpful documentation, demos and so on. Once we had the basics, we released Lama2 into the world.
Future tasks: - Create human-friendly syntax for specifying websocket APIs, basic testing, etc - Integration with more editors + deeper/richer integration
Hi everyone - Posting on HN for the very first time. I am working on an open-source project called Gmail-TUI that aims to replicate the Gmail Web-UI in a TUI-Environment. As of now, users can Login, navigate within this app and compose & send mail.
Just a few days after I had installed Ubuntu, I lost the access to the GUI due to a failed and interrupted update. This led to me being forced to use the TTY-environment (started using the ctrl+alt+fkeys combination) and ending up feeling helpless for a long time as I had never used even the most basic Linux commands.
Months later, this experience led me to look into TUI or Terminal based User Interfaces, which run on Terminals and are like lighter versions of GUIs. This is where the idea of creating my own TUI-Application for Gmail came into mind as I was unable find one that could fit my use-case.
Expected Functionalities
To complete this lack of TUI-Application, I would like the Gmail-TUI to borderline replicate the web-version of Gmail, allowing users to perform most of the core tasks by providing following features/functionalities in it:
-> [DONE] A login page for entering email-ID and password
-> [DONE] Composing and sending mails
-> [WIP] Listing received emails with email-IDs in the Inbox
-> [WIP] Opening the content of the received mail after clicking it
-> [WIP] Viewing sent email in Sent-Box
-> [DONE] Area to choose from the Compose, Inbox, Drafts, Sent buttons
For sending composed mails and validating login, I am using SMTP-Protocol. The logic for validating login is:
> If a login alert email can be sent to the same email address entered in the Email-ID and Password fields, the user will be considered logged in and allowed to access the app dashboard. The dashboard includes options for composing emails (and checking the inbox, drafts, starred mails, etc. in future)
Networking is a new concept to me and I am still working on properly understanding the IMAP-Protocol for implementing the Inbox-feature and will be adding it along with a support for allowing the user to send a well formatted email with attachments using this app.
I know this isn't a finished project and there are lots of features that are still lacking but still, please provide your feedbacks, opinions or any constructive criticism that may have come in your mind while reading this.
Is there anything wrong with my approach or the direction that I can be taking? Please share your honest thoughts, all will be really appreciated.
Wanted to check out Golang so built a simple local RSS Digest reader, using any markdown reader as its GUI. I've been using it for the last 4 months and I am quite content with it, especially since my markdown files are synced on all devices, I can consume my daily brew from anywhere and anytime without any FOMO.
Features: - RSS Digest: show only previously un-generated articles - Interested Topics/Keywords (through Google News) - Daily Weather - Bookmark to Instapaper - Show hot articles / comments link for Hacker News posts
Upcoming Features: - Terminal mode - Quote of the day (from r/quotes) - Perhaps a daily calendar, to show today's meeting - Accessing non-rss feeds (Twitter) - Configurable for Weekly digest instead of Daily
Hi, I'm looking for a free text editor/ IDE that supports C#, Golang, YAML (Optional), Vlang (Optional), Rust I am looking for the following features:
Code autocompletion
Syntax highlighting
An Integrated terminal - (Optional)
A sidebar explorer (To browse files in a project)
A GUI (I just need mouse support really) - (Optional, but heavily preferred)
Near Native performance, (I'm recording my code on a really weak system, So electron apps are usually not a viable option due to intensive memory and CPU usage)
I've tried VS Code, I have stated why I "cannot" use it above
I have tried Emacs, but I was too overwhelmed and didn't know where to begin
I am currently using Sublime text, but Code completion is very confusing to set up and isn't useful when it actually works, as a lot of functions in most languages are straight up missing.
(Windows 10/11)
I don't mind if there is a learning curve as long as there is easy to follow documentation and as long as it's not too time-consuming to learn
I realise I am looking for an "Eierlegende Wollmilchsau", but I have been made aware that there are in fact heavily extensible and lightweight text editors for programming
So my question is: Is there a text editor that meets my requirements? If said text editor has a "big" learning curve, are you aware of a non-time consuming tutorial/ docs
OPA/Styra founder here. I've long held the belief that part of the reason declarative languages are useful is that non-experts can use them without needing to learn the ins-and-outs of programming. That by restricting the language's expressiveness, we can build compilers/interpreters/evaluators/... that deeply inspect and understand the code, e.g. resulting in automatic performance optimization that in traditional languages developers would be doing themselves.
If that's true, then what we really want is a way to give everyone a syntax they are most comfortable with, so they have the shortest learning curve. Some people like declarative languages; some like imperative; some want configuration files; some dislike learning languages and want a GUI; some want to use natural language. So in the end we'll end up with N syntaxes (broadly-construed), each tailored to their audience. A declarative language is (often) all about logic after all, so why does the syntax actually matter?
I pushed this thesis a bit and designed a YAML syntax for Rego (OPA's policy language), in addition to the DSL OPA has supported for years. More interestingly, I put together a translator that moves the logic back and forth between the YAML version and the DSL version. The idea being that people can write policy in whichever syntax they prefer, and tooling can translate between. Not complete yet, but far enough along to get a feel for it. Longer term, I could imagine a python-inspired syntax; one for golang; etc.
It'd be great to get feedback on a couple of things.
1. Overall value of multiple syntaxes for a (declarative) language with tooling to translate between.
2. Thoughts specifically on whether adding the YAML version of Rego demoed here seems beneficial.
I am writing some tutorials on things like GitHub and using Golang with Google Cloud SQL. I want to make sure I can start from scratch fairly often because I want to recreate the new user experience: Creating SSH keys, installing MySQL from scratch, etc. It's awfully easy to assume a user experience that the novice cannot recreate easily. I am doing multiple tests to keep those problems to a minimum.
My host systems are MacOS and Windows. Ideally I could do the docs for Ubunutu (is that the most common denominator?) or Fedora. Most of the tutorials are on the command line, not the GUI.
What's the best way to create reproducible environments that I can tear down and reset to zero quickly? I am thinking that Docker would be a good way to go, but maybe Windows support isn't there yet? Or does Windows 10 have some kind of hypervisor that would let me blow away subshell or something?
I think the best way to do this probably Docker, but I don't know how to make the Windows shell a docker image.
Or maybe Virtual Box is the way to go? I have the luxury of a brand new Windows 10 laptop, if that makes a difference.
