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

Pell – A simple and small rich-text editor for the web

github.com

Post reply on HN
Print view View original

71–80 of 106 posts

Re: Pell – A simple and small rich-text editor for the web

#71

Post by roryisok »

lmm wrote: post #57
roryisok wrote: post #45

Earlier quoted context omitted.

so in that case isn't it a good idea to try and reduce your overheads wherever possible? And in the case of windows store apps, the runtime is already on the users systems and they're just downloading the packaged JS/HTML

> so in that case isn't it a good idea to try and reduce your overheads wherever possible? I think it's the opposite: if you're using react-native or electron you might as well give up on optimizing the size of your own code, because it's not going to make a dent in your overall level of bloat. Enabling your codebase to be used from the user's own browser would have a much better return in bloat-reduction, even if it…

> Enabling your codebase to be used from the user's own browser would have a much better return in bloat-reduction, even if it meant writing more of your own code.

Not every app can be ported to the browser. For instance, if I wanted to make a local file manager (like fman) I couldn't do that in the browser. This is why native apps exist.

Re: Pell – A simple and small rich-text editor for the web

#72

Post by roryisok »

agentgt wrote: post #70

I have always wanted a rich text editor where you could see the markdown as well as the formatting it produces at the same time (and in the same edit pane... ie not realtime rendering in a pane above). That is if you typed: **blah** It would show blah and still show the asterisk but in bold (apologies for using code format but HN will strip the asterisks). There are of course some editor plugins, and IDEs that do thi…

And simpleMDE, mentioned on this thread

Re: Pell – A simple and small rich-text editor for the web

#73

Post by codebeaker »

I'm surprised to see no mention of the Trix editor here amongst the comments about how contentEditable is the root of all evil. Trix has a nice solution, from their readme:

  Trix sidesteps these inconsistencies by 
  treating contenteditable as an I/O devi-
  ice: when input makes its way to the ed-
  itor, Trix converts that input into an 
  editing operation on its internal docum-
  ent model, then re-renders that document
  back into the editor. This gives Trix 
  complete control over what happens after
  every keystroke, and avoids the need to 
  use execCommand at all.
Trix is from basecamp, and has a super healthy plugin/extension ecosystem - https://github.com/basecamp/trix

Full disclosure: not affiliated at all, but the rare times I need a WYSIWYG editor I tend to look for Trix and be very pleased.

Re: Pell – A simple and small rich-text editor for the web

#75

Post by jaredreich »

marijn wrote: post #40

Nonsense, I've written a much smaller one: `function tinyEditor(element) { element.contentEditable = true }` That, plus a few crude buttons, is all this does. As several other comments point out, there's good reasons why real WYSIWYG packages are bigger—the user experience of working with a plain contentEditable element is still terrible, the output HTML still a complete mess. If you don't care much about that, you d…

The last thing I want for notable developers of high quality WYSIWYG editors is to get upset. Take this with a grain of salt. Continue doing the great things you do with ProseMirror and your other valuable open source contributions. But don't get upset. Try getting inspired, to move with the times, to trust browsers more, to make YOUR projects smaller, lighter, and easier to use.

P.S. Just because something is small, doesn't mean it's a crude afternoon hack :)

Re: Pell – A simple and small rich-text editor for the web

#76

Post by lmm »

roryisok wrote: post #71
lmm wrote: post #57

Earlier quoted context omitted.

> so in that case isn't it a good idea to try and reduce your overheads wherever possible? I think it's the opposite: if you're using react-native or electron you might as well give up on optimizing the size of your own code, because it's not going to make a dent in your overall level of bloat. Enabling your codebase to be used from the user's own browser would have a much better return in bloat-reduction, even if it…

> Enabling your codebase to be used from the user's own browser would have a much better return in bloat-reduction, even if it meant writing more of your own code. Not every app can be ported to the browser. For instance, if I wanted to make a local file manager (like fman) I couldn't do that in the browser. This is why native apps exist.

Sure, but even for that kind of app, if you were looking to reduce the bloat then I'd look to try to cut down the runtime you were shipping (i.e. maybe you can build some stripped-down version of electron that contains only the parts you need) before trying to cut your own code, because the runtime is where most of the bloat is.

Re: Pell – A simple and small rich-text editor for the web

#77

Post by [deleted] »

roryisok wrote: post #71
lmm wrote: post #57

Earlier quoted context omitted.

> so in that case isn't it a good idea to try and reduce your overheads wherever possible? I think it's the opposite: if you're using react-native or electron you might as well give up on optimizing the size of your own code, because it's not going to make a dent in your overall level of bloat. Enabling your codebase to be used from the user's own browser would have a much better return in bloat-reduction, even if it…

> Enabling your codebase to be used from the user's own browser would have a much better return in bloat-reduction, even if it meant writing more of your own code. Not every app can be ported to the browser. For instance, if I wanted to make a local file manager (like fman) I couldn't do that in the browser. This is why native apps exist.

[deleted]

Re: Pell – A simple and small rich-text editor for the web

#78

Post by roryisok »

lmm wrote: post #76
roryisok wrote: post #71

Earlier quoted context omitted.

> Enabling your codebase to be used from the user's own browser would have a much better return in bloat-reduction, even if it meant writing more of your own code. Not every app can be ported to the browser. For instance, if I wanted to make a local file manager (like fman) I couldn't do that in the browser. This is why native apps exist.

Sure, but even for that kind of app, if you were looking to reduce the bloat then I'd look to try to cut down the runtime you were shipping (i.e. maybe you can build some stripped-down version of electron that contains only the parts you need) before trying to cut your own code, because the runtime is where most of the bloat is.

> maybe you can build some stripped-down version of electron that contains only the parts you need

if you're using electron in the first place, I think its safe to assume that re-inventing electron is not within your skillset.

Re: Pell – A simple and small rich-text editor for the web

#79

Post by roryisok »

codebeaker wrote: post #73

I'm surprised to see no mention of the Trix editor here amongst the comments about how contentEditable is the root of all evil. Trix has a nice solution, from their readme: Trix sidesteps these inconsistencies by treating contenteditable as an I/O devi- ice: when input makes its way to the ed- itor, Trix converts that input into an editing operation on its internal docum- ent model, then re-renders that document back…

QuillJS also does this, I believe

Re: Pell – A simple and small rich-text editor for the web

#80

Post by lmm »

roryisok wrote: post #78
lmm wrote: post #76

Earlier quoted context omitted.

Sure, but even for that kind of app, if you were looking to reduce the bloat then I'd look to try to cut down the runtime you were shipping (i.e. maybe you can build some stripped-down version of electron that contains only the parts you need) before trying to cut your own code, because the runtime is where most of the bloat is.

> maybe you can build some stripped-down version of electron that contains only the parts you need if you're using electron in the first place, I think its safe to assume that re-inventing electron is not within your skillset.

Build in the sense of "compile" more than in the sense of "write"; I'm not advocating reinventing it from scratch, just customizing it a little.
Post reply on HN