search

pegjs / website

Source code of the PEG.js website
http://pegjs.org/
MIT License
55 stars 20 forks source link

Wanna do some changes #27

Closed reverofevil closed 6 years ago

reverofevil commented 6 years ago

So, it's been years since I've started using /online and I wanted to see some changes, but they never came. Here're some things that came to my head first:

Which of these do you think you will never let into master?

futagoza commented 6 years ago

PEG.js 0.11 drops support for IE8, so I was originally planning to update the website and editor around this, but judging from the Google Analytics for pegjs.org, it is safe to completely drop support for IE on the website, but I'm not completely sure yet on this, as IE is the default browser on Window OS's before Windows 10, so dropping support for it might not be a completely good idea.

Burn the jQuery. Replace it with React

I keep fumbling over React, and with the little experience I've had with it, found it harder to use. Since I plan to completely rewrite the editor, this would mean that even after updating the website, I would be modifying the code, but thinking of React puts me off (don't know why 😆), so would prefer to stick with jQuery here.

Get rid of EJS on server

The EJS should, without doubt, be burned 🤣

Restyle website

I agree with restyling but would prefer the changes to the website layout and its features be implemented separately, that way it will be easier to change the style (doing a redesign of the style won't be as simple as one PR). I'm guessing layout templates are the way to go here.

change to darker background

I want to say no 🛑, but tbh this is only because of my personal preference

Use CodeMirror for output

What do you mean?

Add a button to switch between CM and treeview for output

Since I plan to implement Stage 1 of pegjs/pegjs#523 for 0.11, I was thinking on working on this after that, unless you know of a way to implement it that would allow future compatibility with multiple grammars (would be implemented as tabs in the online editor)

Put execution into webworker, so that infinite loops do not destroy code in Chrome

How would this work on IE9 (if I decided to not drop support for IE, that is)

Add a combobox to select examples from the list

You do mean a drop-down list, don't you?

Fix incorrect CM config (2/4 spaces depending on action)

The spacing seems fine to me

Add lodash into scope

Rather than adding it to the scope, an options dialogue to add external js libs when executing the compiled parser would be a better way forward for this (I know I'm not the only one who doesn't use lodash)

select examples from the list ... Collapse options

I was thinking of adding an option to the editor that would allow the user to choose between the released version of PEG.js (currently v0.10) and the latest dev release (either via unpkg or GitHub directly), but examples and options will need to change accordingly then.

reverofevil commented 6 years ago

PEG.js 0.11 drops support for IE8, so I was originally planning to update the website and editor around this, but judging from the Google Analytics for pegjs.org, it is safe to completely drop support for IE on the website, but I'm not completely sure yet on this, as IE is the default browser on Window OS's before Windows 10, so dropping support for it might not be a completely good idea.

React supports IE8+, so this shouldn't be a problem.

I keep fumbling over React, and with the little experience I've had with it, found it harder to use. Since I plan to completely rewrite the editor, this would mean that even after updating the website, I would be modifying the code, but thinking of React puts me off (don't know why 😆), so would prefer to stick with jQuery here.

jQuery is not an option in 2018. I'd rather stick with plain DOM methods than use a library with 20 years of kludges and bugs, which adds absolutely no value for the last 5 years at least (even on IE).

Facebook have completely broken React documentation recently. It was way simpler several years ago, so I perfectly understand your confusion. I can reassure you that it's way easier to use than everything else on the market. I'd recommend to eat the pill and use it, but I'm fine with DOM methods too.

I agree with restyling but would prefer the changes to the website layout and its features be implemented separately, that way it will be easier to change the style (doing a redesign of the style won't be as simple as one PR). I'm guessing layout templates are the way to go here.

"Separation of logic and markup" or whatever it was called 15 years ago is an unfortunate misconception, based on misunderstanding of the talk one of the typographers gave half a century ago. Neither HTML, nor CSS are well-designed to separate styles, data and code, and whoever decided to pursue this false goal ended up in problems.

I will surely do a separate PR for the style, but I would definitely not use templates, because that approach just doesn't work.

I want to say no :stop_sign:, but tbh this is only because of my personal preference

No, I didn't mean it to be dark as in dark themes, but just not white. Pure colors are considered bad taste by (most of) designers.

What do you mean?

Stupid me. I meant text input on /online, the right-top part. Currently it's just a <textarea>.

Since I plan to implement Stage 1 of pegjs/pegjs#523 for 0.11, I was thinking on working on this after that, unless you know of a way to implement it that would allow future compatibility with multiple grammars (would be implemented as tabs in the online editor)

I actually meant that in most cases result is some non-string JS value ({type: 'smth', children: [...]}), and printing JSON for it is not helpful at all. Treeview that displays JSON (the same kind Chrome uses when you console.log object or array) doesn't really depend on the grammar. Having multiple grammars shouldn't have anything to do with it either. What do you mean?

How would this work on IE9 (if I decided to not drop support for IE, that is)

In case web workers are not available, it can run with eval, the same way it runs now.

You do mean a drop-down list, don't you?

Yes, a dropdown.

The spacing seems fine to me

Rather than adding it to the scope, an options dialogue to add external js libs when executing the compiled parser would be a better way forward for this (I know I'm not the only one who doesn't use lodash)

Yeah, I didn't think of it. The problem I see is that it's hard to put CDN links every time /online gets opened. It's fine for jsfiddle where the code is stored, but not here. Also I have no idea how to let users save code in a secure way, even after I took a look on jsfiddle's source code.

I was thinking of adding an option to the editor that would allow the user to choose between the released version of PEG.js (currently v0.10) and the latest dev release (either via unpkg or GitHub directly), but examples and options will need to change accordingly then.

That's a really good idea. Ever since the website went online it was unclear which version of library it's running, and how does it compare to npm and master.

The main stress of this item was that I never used either "parser variable", or "use cache", and downloaded the grammar only several times to take a look on the way PEG.js currently generates code. It's pretty much useless for a person that visits online version, and I'd remove the "Download parser" feature completely. Probably I should start with PR with a call to analytics on that button, so that we know for sure nobody uses it.

futagoza commented 6 years ago

I'd recommend to eat the pill and use it, but I'm fine with DOM methods too.

If there's a higher level API around the portions that use React (something similar to the Three.js Editor), then I don't mind the usage of React.

I will surely do a separate PR for the style

I'm fine with this.

I actually meant that in most cases result is some non-string JS value ({type: 'smth', children: [...]}), and printing JSON for it is not helpful at all. Treeview that displays JSON (the same kind Chrome uses when you console.log object or array) doesn't really depend on the grammar. Having multiple grammars shouldn't have anything to do with it either. What do you mean?

Whoops, thought you were talking about syntax diagrams as that was what I was planning to add.

  • Put cursor before the first if on line 9, press Tab. It will get indented 4 extra spaces.
  • Select several lines and press Tab/Shift-Tab. The fragment will be (un)indented 2 spaces.

Isn't this because of the way the rules in the PEG.js example are formatted? The default value of 4 spaces is being used by the Codemirror Editor, and since I've nearly always used 4 spaces, I didn't change this option, but maybe we can add an option to the PEG.js Online editor's options that change this value?

The problem I see is that it's hard to put CDN links every time /online gets opened. It's fine for jsfiddle where the code is stored, but not here. Also I have no idea how to let users save code in a secure way, even after I took a look on jsfiddle's source code.

Can't we just use localStorage (html5) and/or cookies? If that's not enough, we could always implement an import and export system, that way it would be up to the user to keep the code secure, and we can just concentrate on the editor's features. Of course, we'de have to make the import/export system easy to use, so maybe:

  1. User clicks "Export"
  2. Edit gathers all data (grammars, settings, external js libs, CDN used, etc)
  3. Editor sends relavent data to server
  4. Server zips of the data and sends it back
  5. User downloads zip file

With a lot of HTML5 features found in most browser's today, I realise we can actually take the server backend out altogether and use a client-side zip library, which would simplify this even more (not to mention be faster in most cases), but this probably won't be doable in IE9/10, so how about a warning then if the user is using an untested browser?

reverofevil commented 6 years ago

I didn't change this option, but maybe we can add an option to the PEG.js Online editor's options that change this value?

I remember it's a pain to set up CM to handle spaces consistently. I'll do it.

Can't we just use localStorage (html5) and/or cookies?

It's funny that I forgot about that, because I even mentioned it in the first comment in this topic. LocalStorage is the way to go here. Export/import is kinda more for a full-fledged JS editor over web. Creating zip files on frontend is an easy thing to do, and works very consistently over the wide range of browsers (everything where data URIs can handle more than 64KiB. That's IE8+, if I remember it correctly), but we don't really need it :)

StoneCypher commented 6 years ago

i'd be happy to handle the react part, and willing to handle the codemirror part