Too bad it's electron. I'm working on a just-for-fun markdown editor using GtkSourceView and GtkWebkit and, despite a slight learning curve getting familiar with gtk, it's been a pleasure to work on. Ugh...electron? Really??
Too bad it's GTK, which is an atrocious toolkit. Why didn't you write yours in Qt?
See, there's always more to complain about. I don't think your comment is productive here. Electron is not a perfect choice but what exactly does your comment add to the discussion about "just for fun" projects?
The OP is not singing the praises of Electron, in which case criticism about it would be welcome. They're trying to show off something they built. If a kid shows you a drawing they're proud of, do you criticize the drawing for not having a good color palette? (Rhetorical: It's not appropriate to do so, unless they're specifically asking for that kind of feedback)
I currently migrate from ghostwriter[0] to VNote[1] (both are Qt-based). VNote look very nice, but some refactoring needed + some features (that I'm waiting for) still missed. Hope, VNote development will be active, as it's developer[2] promised on HN[3].
These kinds of dismissive comments make me wonder if the writer ever created anything of substance in their life.
For example, notice how this project is actually accessible for people to try today. Building something in the privacy of localhost is pretty worthless if you think it equips you with the power of judgement. That's the easiest part of building something. Congratulations on your unreleased hobby project that doesn't use Electron.
Let's keep this sort of comment off HN. You'll notice it only squanders interesting discussion from the pool.
In fact, that it's built with Electron suggests that the core can be factored out into a library that you can embed in a website or another project, and that's great.
One, you're replying to a guy with thousands of stars on his released github projects.
Two, there are tradeoffs in using electron, and it's not unreasonable to discuss those. This place would lose a lot of its value if we're not allowed to discuss the pros and cons of technical decisions that go into a project.
It’s weird, but I think you’re both right. My first reaction to anything html/javascript/etc is a mix of “ew” and “that’s not very impressive“. But I also think it’s important to be inclusive and flexible. Society’s best off when people fight past their internal prejudices, but my past experiences with html/JavaScript put a bad memory in my mind.
Ultimately, this looks like a well executed program from the screenshots. I say kudos to the developer of it. They did something productive and made something useful.
> These kinds of dismissive comments make me wonder if the writer ever created anything of substance in their life.
Ad hominem [0].
And he has. I use the things he has built in production. He has contributed to Python community (and SQLite) to a great extent. Some of the amazing things he built [1], [2], [3].
People are entitled to their opinions, and they are entitled to share them on HN. There are plenty of reasons to like Electron, and there are also plenty of reasons to say "ugh, Electron".
Instead of saying "Let's keep this sort of comment off HN" because you happen to disagree with the guy's opinion, why not just ask him why he's so dead set against using Electron for this sort of app?
People usually have strong opinions for a reason -- it isn't always because they are ignorant, or because they are arrogant jerks (yes, sometimes that happens, but not always). You might even learn something about Electron from the guy's explanation (depending, of course, on what his reasons are).
"We all know why one might prefer something over Electron."
Actually, that's not true. There are most likely some folks reading who don't know much about Electron. Also, just because there are a number of well known reasons why someone might dislike Electron doesn't mean that they are this person's reasons for disliking it. Perhaps he has reasons for disliking it of which you are unaware. If you don't want to bother asking him that's fine, but that doesn't make the question not worth asking to everyone else.
"'Ugh, the color blue! Me no likey!' Does it really matter why they don't like blue, or whether I agree with them?"
Not liking the color blue isn't even close to the same thing. Peoples likes and dislikes about colors are very subjective, and people often don't have any definable reason for why they like or dislike a color.
That is very rarely true about development tools, frameworks and libraries. If a developer does not like them, they usually have a particular list of reasons why. You may disagree with their reasons, or the way they present them, but you still might learn something of value from hearing their list.
"It's just a worthless comment."
It's only a worthless comment to you because you made assumptions about why the comment was made. I understand why you might be put off by the way the original comment was worded, and yes I would have preferred that they elaborate more about the reasons for their dislike of the choice of Electron up front. However, I think it is a mistake to assume that you could not have learned anything of value from engaging with the person who left that comment (instead of assuming you already knew what the reasons behind it were.)
Agreed. It's a fact of life that Electron will become increasingly popular. If every discussion of an app that uses Electron degenerates into snarky comments about Electron, the opportunity for a valuable conversation about the app itself is wasted.
"It's a fact of life that Electron will become increasingly popular."
Very likely, perhaps, but it is not "a fact of life", especially in the long term -- Electron's popularity in the future is far from a decided fact. I think it has a very good shot at lasting a long time, but in this industry things often do not go the way you think they will.
If indeed "every discussion of an app that uses Electron degenerates into snarky comments about Electron" then maybe it is time to look seriously at problems with Electron. One of the best things about HN is that discussions about the technologies used to implement applications happen.
Now if someone comes into the conversation, snarks, and then is unwilling to engage in discussions about why they dislike the choice, that's a different matter.
I do think, however, that discussions about the technologies chosen by a developer to implement their application are worth having, even if they person starting the conversation is not terribly diplomatic about the way they start it. There does come a point (different for different people) where you decide a conversation is not worth having. I am merely suggesting that it could well be worth your time to not assume you've reached that point so early in the conversation.
I'm the kind of guy who loves Electron. It lets more developer get software on the Desktop. That's pretty cool, right?
But here's the thing. My current Markdown editor is Typora. Visually, it's all I want. But on the performance side, well, you can feel it's powered by Electron.
So I'm going to give a go to Abricotine (I mean, it's even open source, so that's great!). But I really want a markdown editor than can render a 100Ko file without difficulties.
Edit: Now that I've tested it, it's effectively way faster than Typora on the files I regularly uses. So I'll probably switch right way.
This is cool but it makes me wonder about all of the electron apps that are coming out. Is there something more efficient that could do the same? Why are QT and GTK not nearly as popular?
Because the people who are building and releasing these Electron apps are not interested to learn GTK/Qt; simple as that. Same reason why JavaScript is so "popular" because it's easy [1] to learn and — with the help of these other projects, Electron just being one of them — it becomes very easy to develop "cross-platform" applications.
Imagine being a 12 years old interested to become a desktop application developer, and then someone comes and gives you the option to spend several hours learning GTK/Qt with C++/Python, and then another person gives them the option to learn JavaScript (a language that is daily giving something to talk about) with Electron, what would be your choice?
[1] If you disregard all the ambiguity of the language.
"More efficient" how? At saving developer time? At producing shippable end products? At debugging? Will using GTK result in a better product that increases the end-user's "efficiency" more? Or will it really result in the developer shipping a product with 1/10th the features, or nothing at all?
Funny how you mentioned nothing of the computing resources required to run any of these. Sometimes it's alright to spend more time creating a product when the end result uses less CPU and less memory. It's not all or nothing.
If it makes no notisable difference to the user and cost you more time, you are just wasting time that could have been spend better on improving the users experiance.
Is the editor really a problem to solve for Markdown? Philosophically I regard Markdown as a language in the text-only-editor-unimportant family.
I recently built a (simple, only works for me) filter for pandoc that allows for formulas in Markdown tables. org-mode features is what Markdown is missing, but without the marriage to the editor.
At the same time: an editor like this makes Markdown more accessible for non-hackers, which is always good.
> Is the editor really a problem to solve for Markdown?
I don't think it's a "problem to solve" i think it's an opportunity to grasp.
I love markdown and can read it just fine without an editor like this, but I, and many others, find it useful to have headings actually be darker and bigger. There's value to those typographical changes. There's value to links being a different color. Having an editor that can provide your eyes with helpful things.... helps.
On a related note: I’ve recently started using https://hackmd.io/ for markdown. It supports the full gh markdown and more. The best part is the collaborative editing. Big thumbs up to the guys working on the product - I haven’t missed desktop apps for markdown at all. I’m looking forward to trying their slideshow features.
Disclosure: I have no affiliation with them :). I’m just a fanboy at this point.
I think the way electron apps abound when there are possibly better alternatives is similar to the way markdown abounds in spite of other better 'lightweight' markup alternatives.. after years of using markdown, I've migrated to asciidoc and couldn't be happier that I don't have to rely on custom extensions..
I guess it's a mindshare thing and a learning curve thing.. I guess markdown is good enough for the vast majority of cases.. but when it isn't, it becomes a pita..
This looks really awesome! I really wish I could use it as a library and embed it into my SaaS app. Is there a way to extract just the rendering functionality and add it to a website?
I'm not sure if it's exactly the same features but I've had success with https://simplemde.com for rich Markdown entry on the web.
I like that it's usable by people who want to click buttons -- and that by showing users both the formatting and the Markdown that caused it, it teaches how to skip the buttons in the future. At the same time, if you're a Markdown user doing everything on the keyboard, it's completely unobtrusive. Everybody wins.
Just tested it and it seems really promising. Great work!
I wish it could replace the formatting syntax as you type, like Typora [1] does. The document becomes much cleaner to read while still being efficient to write.
Anyone know of a markdown editor that has quick, notational velocity style file search/creation and just saves files to the hard disk? (So I can sync the directory via Dropbox or Google drive myself)
>nvALT 2 is a fork of the original Notational Velocity with some additional features and interface modifications, including MultiMarkdown functionality.