Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Native all the way, until you need text

justsitandgrin.im

Post reply on HN
Print view View original

321–328 of 328 posts

Re: Native all the way, until you need text

#321

Post by Klonoar »

msephton wrote: post #310
Klonoar wrote: post #308

Earlier quoted context omitted.

> 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 sever…

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…

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.

Re: Native all the way, until you need text

#323

Post by msephton »

Klonoar wrote: post #321
msephton wrote: post #310

Earlier quoted context omitted.

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…

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.

Re: Native all the way, until you need text

#324

Post by msephton »

basch wrote: post #309
dataflow wrote: post #288

Earlier quoted context omitted.

I definitely need to edit files that are hundreds of thousands of lines once in a while. Nothing wrong with it, I think you're just assuming it's source code or such when it isn't. It's often data manipulation (CSV, JSON, etc.) and it feels like torture when the editor can't handle it. I've even opened multi-gigabyte text files in my editor and needed to edit them sometimes.

Did you look at the app? It's a todo list. The idea of a multi gigabyte todo list makes me uneasy.

Good point! It's a plain text outliner, but i use it as for tasks/todo. Most features were added for people other than me!

Re: Native all the way, until you need text

#325

Post by kenferry »

Bolwin wrote: post #264
kenferry wrote: post #206

Earlier quoted context omitted.

The native Apple libraries are terrific at rendering rich text, it’s one of their strongest assets. The poster’s issues seem to be specifically because they want to use markdown as the backing. The native rich text backing for native Apple views is attributed strings. They could translate the markdown to attributed strings, but seems like they don’t want to.

..where did you get that impression? The web also requires you to convert to html. I don't see how this is different

I have this impression because I know the native controls are terrific at rich text, so for some reason that support isn't done in a way the author wants to use. The source code of the TextEdit app on Mac is actually published as an example project for the frameworks. Everything in there is provided by the native framework controls.

It would make sense, for example, if you wanted to allow editing of the rich text and have the markdown be directly accessible by the user. The conversion of markdown -> attributed strings -> markdown would not produce the same raw text, which is a problem if the user can directly edit or view the markdown. The user hitting cmd-B in the text view to make something bold might end up scrapping some explicit formatting they did to the raw markdown.

Re: Native all the way, until you need text

#326

Post by tclancy »

masklinn wrote: post #293
tclancy wrote: post #159

Earlier quoted context omitted.

That doesn’t track at all. Markdown was created as a simpler way to mark up text than HTML. They are both ways of encoding a document that provide ways to convey intention. HTML is no one’s end goal.

First sentence of the announcement / introduction of markdown: > Markdown is a text-to-HTML conversion tool for web writers. HTML embedding was also integral to it: https://daringfireball.net/projects/markdown/syntax#html > Markdown’s syntax is intended for one purpose: to be used as a format for writing for the web. […] For any markup that is not covered by Markdown’s syntax, you simply use HTML itself.

Understood. What I was trying to say but elided pretty well is I think it's now become something else. Almost its own in-between format that provides a fair bit of marking for clarity with a level of security and the ability to extend as needed. Definitely my own perspective as it's my default for working in Slack and Teams, I keep notes in Obsidian, etc. At no point do I think of those as places I am trying to write HTML, just places I am trying to write with the ability to add more context.

Re: Native all the way, until you need text

#327

Post by kenferry »

Klonoar wrote: post #272
kenferry wrote: post #208

Earlier quoted context omitted.

You’re confusing iOS and Mac OS here. The Mac never used WebKit for NSTextField rendering. When iOS was first written, WebKit was used as the text renderer everywhere initially, including in UIKit controls (the “sweet solution”). This proved to be too heavyweight / cumbersome and the coretext/appkit text rendering approach was brought over.

Also NSAttributedString would invoke WebKit under the hood if you went to render an HTML string.

On what platform? It invoked WebKit always on iOS in the early days, html or not. On Mac, AppKit could import html to attributed strings before WebKit existed.

Re: Native all the way, until you need text

#328

Post by Wowfunhappy »

tardedmeme wrote: post #304
stavros wrote: post #300

Earlier quoted context omitted.

Right, but he clearly didn't mean HTML, otherwise he wouldn't be trying native elements in the first place.

He means Markdown, but Markdown is mean to turn into HTML. Rendering it any other way than converting it to HTML gives a different result, and if anyone complains about it, it'll be your fault since you didn't render it the proper way. It turns out a lot of things are like this. Another commentator mentioned Slack messages.

I feel like Typescript is a good analogy here. Typescript is its own language, but it is intended to be transpiled into Javascript. Yes, you could probably create a JIT that executes Typescript directly—but you would do so at your own peril. Reaching for an existing Javascript interpreter such as JavaScriptCore or V8 is the logical choice.
Post reply on HN