Hacker News new | ask | show | jobs
by msephton 32 days ago
You're assuming the text editor component alone took 8 months, but of course it did not! That would be crazy. There's a whole app built around the text component, which is what took my time, and the reason people are buying the app.

Development is ongoing for the features around the text component. I added folding lists which took a while, and because I offer outliner features I added focus/hoist which was also quite complicated.

Performance profiling and adjustments were measured and solved when I was almost done, because premature optimisation is a bad idea.

I don't consider what I did fighting any sort of limitations, so I guess it's a point-of-view thing. I wanted to use system components, and the only way to do that whilst maintaining performance is to do it with due care and attention. Nothing comes for free.

1 comments

Nothing comes for free, but OP’s entire point is that the price to pay for even halfway decent native markdown rendering is too high - and thus a reason why people often give up and go to Electron.

They could not have made their point more clearly but people like you are up and down the thread wanting to call “skill issue”. The reality is that nobody gives a shit and they want to ship interesting things fast; if OS makers won’t get the hell in line and offer APIs to do it, then these developers are going to just pick Electron.

Life is way too short to sit down and write half a damn text editor when all you wanted to do was shit out a basic application with blobs of markdown.

So now it's personal and I'm the bad guy because I happened to have already done what the OP says is not possible? Deeply uncool.The price is not high at all, and it's not an opinion or theory because I've proven it by shipping an app. The OS makers already offer "APIs to do it" and, as with any type of component or framework, if you bend it the wrong way you'll get bad results. If you abuse Electron you'll also get bad performance there, it's no silver bullet. This is not ground-breaking information, just common sense.
> So now it's personal and I'm the bad guy

It's not personal, but yes, you're being intentionally obtuse to OP's point.

> and it's not an opinion or theory because I've proven it by shipping an app

You are once again downplaying the level of effort difference that OP is describing, thus missing the point entirely.

> if you bend it the wrong way you'll get bad results

OP did not bend it the wrong way, they tried several different approaches because it wasn't working as intended off the bat (i.e, without bending).

OP's point was never that things were "not possible", it's that it's a stupid amount of effort for table-stakes functionality. If you don't get that point by now then I don't think you'll get it at all.

I'm not being obtuse, on the contrary I am bright and focussed enough that my experience building an app around TextKit 2 was opposite to the premise of the OP. It's a few lines of code to add a TextKit2 component to an app, and it just works. It is what the developer does with it afterwards that will make or break it. The same goes for Electron, it is not a panacea. That's just software development, the developer is responsible for the code they write.

So the reader is free to accept my story about my shipped app and my assurance that it didn't take unreasonable effort, or accept a blog post complaining how difficult things are that has no code or shipped app at the end of it.

Judging by the color of the text on your comment (currently downvoted gray), I think it's pretty clear how readers are taking it. I would encourage you to take a wider view of the problems in the UI ecosystem and why people make tradeoffs like they do.
The comment has one downvote. The wider view is that TextKit 2 works out of the box and its up to the developer to mess it up, or not. I made an app using it, quite easily, it's selling very well, thanks! No tradeoffs needed.