Hi @pchampin , about https://github.com/pchampin/sowasm/issues/4 I tried running the Monaco editor using the ESM import, and it worked without any issue! (the problem I faced in my app was due to a HighlightJS import conflict). The API to manipulate the Monaco editor is quite straightforward, so I went ahead and updated the app:

• Use the Monaco editor for input and output, it works exactly like before, but now uses the Monaco editor instead of textarea
• Enabled automatic language change when the input/output format changes. It switches between xml, json, and sparql (works for every w3c syntax: nt, turtle, quads...)
• Used the solarized-dark theme from https://github.com/brijeshb42/monaco-themes/tree/master/themes
• Changed the layout to use flexbox, center items, and make it responsive: on medium and large screen the input and output editor will be displayed side by side, on small screen they will be displayed on top of each other
• Added the w3c RDF logo as SVG to use as favicon (feel free to change if you have a better idea in mind)

There is still the placeholder in the input editor to implement, I added a comment with a pointer on how to do it

Here is what it looks like with the solarized-dark theme:

And with the solarized-light theme:

Let me know which changes you would like to do next. I am thinking about this:

• increase the height of the editors depending on screen size
• reduce the size of the title to gain space for the rest, and make it more informative. Something like "SoWasm - RDF playground based on Sophia: validate, convert, canonicalize" on 1 line

This PR follows up on https://github.com/pchampin/sowasm/pull/12 by making more consequent improvements to the UI

After a bit of usage it feels like having the 2 editors side by side on medium screen is really hard to read

The 1st example (JSON-LD) is readable, because really small. But the 2 others examples with XML are a pain to read

We should try to optimize the screen space used, I propose to:

• Integrate the "SoWasm" title in the intro paragraph
• Only put the editor side by side on large screens. From my experience I found it much more enjoyable to use it this way. It is nice to be able to properly read the RDF and edit it if necessary. Having the editors side by side don't have much advantages apart from being able to really quickly see or copy the converted RDF without the need to scroll
• Change the editor height to be 70vh, this will make the editors takes about 70% of the actual user screen, and prevents the editor from being bigger than the screen (which can be confusing). This way the editor are always large enough for users with medium to small screen, and they can better switch between the 2 editors (each editor takes most of the screen, which prevent confusion and improve focus). Editors also extend properly if the user have a large screen so they can make use of this awesome largeness and comfortably contemplate 2 large RDF files in one glance

A few minor UI improvements:

• Improve margin around the load URL input
• Fix some indentations in the HTML
• Update the body font-family to use sans-serif, which is more adapted to normal text in websites than serif
• Make the cursor a pointer when hovering the Advanced options expandable div

The addition of the monaco-editor (in response to #4) is very nice (line numbering, syntax and error highlighting...), but it take a significant time at startup.

It is all the more of an issue when we automatically load content from a URL, because the loading of the URL starts only when the monaco-editor is entirely set up.

Proposed solution:

• reinstate the textareas for input and output as they were before PR #9, i.e. all the rest of the application depends on them (and not on the monaco editor)
• however, they will be kept invisble
• the monaco-editors will keep in sync with the corresponding textareas, which will be the only "interface" between them and the rest of the application
• the monaco-editors will be visible (as soon as they are ready)

Advantages:

• when the application starts, we don't need to wait for the monaco-editors to be ready to start the rest of the application (init SoWasm, setup event listeners, start loading the URL if any)
• we can even add a checkbox in the advanced options to disable monaco-editors completely, for people who prefer good-old textareas

When corsproxy.io encounters a redirect, it redirects to the "bare" destination, while we would want to use corsproxy.io again for the redirected URL.

So we should use the redirect: manual parameter of fetch for this.

On big inputs, the WASM functions sometime take a non negligible time, causing responsiveness problems.

An alternative would their execution into a worker.

Currently, syntax guessing is performed by trying to parse the whole file. If the file is not valid in any syntax, it is reported as "could not be guessed". This has several drawbacks:

• it can be relatively long on big input, which hurts responsiveness ;
• when 'guess' is checked, no useful error message is displayed (it either succeeds to parse, or fails with "could not be guessed")

An alternative would be to parse only a subset of the string, and result to the syntax that accepts the longest part of the fragment (in other words, that fails the furthest down the road).

The drawback is that the guessing would be less precise: it would need to always favour N-Quads over N-Triples, even if the sample contains no quad (because the input beyond the sample may still contain quads...). Likewise for TriG and Turtle. Actually, if the sample contains only N-Triples triples, it is impossible to decide with certainty between N-Quads and Turtle/TriG.

The error messages often contain the location of the error. This location information should be extracted and presented in a more uniform and readable way.

If/when #4 is implemented, it would even be better to highlight the error directly in the input editor.