
Building a hackable editor in the browser - bjenik
http://bjenik.com/hackableeditor/
======
kjar
So AFAIK Electron is built on V8 JS engine. Last I looked that has a JIT
compiler, then I’d expect performance to increase as that ‘warms up’

~~~
saagarjha
It does, but you've still got to keep around the optimizing JIT compiler, its
JavaScript metadata, and a hundred other things around even after the
JavaScript has been partially compiled to native code.

------
awake
If you like this check out
[https://github.com/Webstrates/Codestrates](https://github.com/Webstrates/Codestrates)

------
kevingrahl
Could someone upgrade/update the link to include [https://](https://) please?

------
pier25

        script, style { display: block; }
    

I have no words.

~~~
teddyh
This is a discussion forum. Putting things into words is the purpose of
commenting. If you can’t, then maybe you shouldn’t.

~~~
pier25
I did put something into words, didn't I? ;)

Joking aside, I would have thought this was possible.

~~~
pier25
*never thought

------
atum47
nice, I did something similar to myConsole, except I did override some
functions and added some buttons to make it look like and app

[https://github.com/victorqribeiro/myConsole](https://github.com/victorqribeiro/myConsole)

------
pcr910303
Yeah, so it's basically emacs in the browser!

Changing editor capabilities on-the-fly!

------
Kaiyou
...how about moving things out of the browser? It's cramped as it is. And then
people wonder why their browser is so slow... "it's just displaying
documents!"

~~~
ajconway
For that we’ll need an adequate cross-platform (-ish) way of doing UI. I’m not
a fan of React Native, but it seems to be the technology we’re looking for,
though it doesn’t seem to be as ready for the desktop yet.

An all-native solution on top of a powerful modern language (rust?) would be
ideal, but that doesn’t seem to be the direction things are moving. We’ll
probably end up with Flutter/Native.

~~~
vbsteven
I've been thinking a lot about this lately and I'm trying to compile some
information on how others think it should work.

Can you elaborate on what you mean by an all-native solution on top of a
powerful modern language?

The way I see it is that a new toolkit like GTK or Qt is required in the
target language.

~~~
Crinus
> The way I see it is that a new toolkit like GTK or Qt is required in the
> target language.

The way i See it is that a new toolkit like GTK or Qt is required in C so that
it can interface with any language as to avoid unnecessary duplication between
languages (it is much easier to convince people switch toolkit than switch
programming languages), ensure no language-specific indirect dependencies
(especially if it is to included in OSes like OpenBSD that are traditionally C
oriented) and with a stable backwards compatible ABI to avoid wasting the time
and effort of whoever maintains the bindings (no need to rewrite them every
few years), whoever decides to learn the new API (no need to learn something
new for doing the exact same thing as before, only now in a slightly different
yet incompatible way) and perhaps hopefully become a "standard" API people can
target on Linux without having to carry 29892482923TB of libraries for a
trivial app since you cannot rely on anything outside of X11 being there (and
if GNOME people have their way, you wont be able to rely on even that). And of
course all that in a permissive license that leaves everyone happy.

Now guess how likely all of this is going to happen.

~~~
jcelerier
> and perhaps hopefully become a "standard" API people can target on Linux
> without having to carry 29892482923TB of libraries for a trivial app since
> you cannot rely on anything outside of X11 being there

so, uh, what would you depend on ? at the bare minimum you would need, for a
gui toolkit :

\- dependencies to X11 (xcb) and wayland (and cocoa and win32)

\- dependencies to xkb, etc.. for keyboard handling

\- dependencies on ICU for unicode text handling

\- dependencies on freetype, fontconfig, harfbuzz, pango, etc... for font
rendering

\- dependencies on GL to allow your users to have a GL viewport, and
potentiall on a software implementation of GL on windows because yes, even in
2019 this is still a problem on some user's computers

\- dependencies on cairo, skia, QPainter, or something like that to provide a
canvas-like API

\- dependencies on libinput because that's the modern way to get mouse input
on linux

\- you are going to want a library of useful datastructures that aren't
provided in C -> dependency to GLib or something else

\- dependencies on libpng,jpeg, etc.... because you want your users to be able
to have images in their app

\- dependencies on dbus to be able to provide desktop notifications, etc

and you aren't even starting to match all the useful functionalities of GTK &
Qt

~~~
Crinus
Of everything that list all you _really_ need is the X libraries and you do
not need to carry (meaning distribute) those since they are part of the every
single desktop environment and have a stable ABI. The rest aren't strictly
necessary, but i think Cairo has a stable ABI. I'm not sure if it is available
everywhere though. OpenGL (and Vulkan) can be provided via dynamic linking,
though only via an API that doesn't guarantee its existence (it doesn't exist
in all X11 desktops - AFAIK Raspberry Pi doesn't support them).

In any case, the dependencies i mean here are dependencies for the
applications that target your API, not the dependencies your API has. You can
make your API use whatever library you want to -e.g.- load PNG, JPG or
whatever, but that can be hidden from the user of the API (ie. their binary
will link against libyourapi.so.1 for yapi_load_image and what that specific
version of libyourapi.so.1 uses to load the requested image is an
implementation detail).

Note that this is in the context of making that API a standard people can
target, not a reusable library (and its own dependencies) people carry with
their binaries. Basically the equivalent of how you do not need to give
USER32.DLL on Windows to your users because you can pretty much expect that it
will be there.

Nowadays the only equivalent on Linux is the X libraries, anything else is
either not guaranteed to be there now, or not guaranteed to be there in ~5
years because thanks to CADT people cannot stick with an API and feel the need
to break everyone's programs to feel useful.

~~~
jcelerier
> Of everything that list all you really need is the X libraries and you do
> not need to carry (meaning distribute) those since they are part of the
> every single desktop environment and have a stable ABI.

both Debian and Fedora use wayland by default now. And wayland alone only
gives you the ability to open a viewport, so you are going to need a _lot_ of
stuff if you want your UI library to do something as simple as :

    
    
        #include <linux_ui.h>
        int main() {
            linux_window* window = linux_ui_create_window();
            linux_widget* label = linux_ui_create_label(u8"お早う御座います");
            linux_ui_widget_set_parent(label, window);
            linux_ui_widget_set_pos(label, 50, 50);
    
            return linux_ui_process_events();
        }
    

> Note that this is in the context of making that API a standard people can
> target, not a reusable library (and its own dependencies) people carry with
> their binaries. Basically the equivalent of how you do not need to give
> USER32.DLL on Windows to your users because you can pretty much expect that
> it will be there.

But almost no one makes Win32 apps with the Win32 API anymore anyways. The
majority of desktop windows apps created today are using WPF or UWP which does
not use any "native" stuff (that is, the win32 UI API), Qt or Electron. If
this model does not even work on windows, why would you want to port it on
linux instead of letting people ship their app as they wish ?

> Nowadays the only equivalent on Linux is the X libraries, anything else is
> either not guaranteed to be there now, or not guaranteed to be there in ~5
> years because thanks to CADT people cannot stick with an API and feel the
> need to break everyone's programs to feel useful.

Even if someone made this magical new library today, I would still have to
package it along with all its dependencies in an AppImage because I have users
still on ubuntu 12.04, 14.04, and 16.04 as well as debian stretch and jessie.

