<Comment deleted by user>
For a start, here is my WASM board:
example use case ( used to present Atomic World Championship bracket with ability to load and analyze the games ):
serversideapps.github.io/index.html
source:
github.com/typescriptstudies/wasmboard
It is written in TypeScript ( optimized for Visual Studio Code ), for move generation/PGN parsing it uses WebAssembly, which is the latest web technology.
example use case ( used to present Atomic World Championship bracket with ability to load and analyze the games ):
serversideapps.github.io/index.html
source:
github.com/typescriptstudies/wasmboard
It is written in TypeScript ( optimized for Visual Studio Code ), for move generation/PGN parsing it uses WebAssembly, which is the latest web technology.
<Comment deleted by user>
You have to decide on what platform you want to implement your PGN viewer.
It is a viewer so it has to be a GUI application. A console application ( which is far easier to program ) can only present textual output. Viewing the board as text and try to manipulate it through typed in commands is definetely not what you want.
Once it is a GUI application, you again have two choices.
One is to have it as a Web application. Then for the purposes of the GUI you use the browser, and the language then has to be Javascript ( TypeScript is just typed Javascript ), WebAssembly ( upcoming technology, not fully capable of yet, needs Javascript glue code ) or any language that compiles to Jacascript/WebAssembly ( if you compile an other language to Javascript, then the Javascript code tends to be large and/or unreadable, so apply this approach with care ).
Secondly you can have a stand alone GUI application, which runs independently of the browser. There is JavaFX if you into Java/Scala, or OpenGL if you are into C++ for example. If you do it stand alone, you can the enjoy a powerful langage but you certainly cannot upload it to the Web and share it with others easily.
I personally prefer a Web applicataion because HTML + Javascript makes a powerful GUI and it is easy to upload it to the Web and make it instantly available to others. Even speed is not a great concern because WebAssembly ( or even just asm.js ) lets you have close to native processing speed.
It is a viewer so it has to be a GUI application. A console application ( which is far easier to program ) can only present textual output. Viewing the board as text and try to manipulate it through typed in commands is definetely not what you want.
Once it is a GUI application, you again have two choices.
One is to have it as a Web application. Then for the purposes of the GUI you use the browser, and the language then has to be Javascript ( TypeScript is just typed Javascript ), WebAssembly ( upcoming technology, not fully capable of yet, needs Javascript glue code ) or any language that compiles to Jacascript/WebAssembly ( if you compile an other language to Javascript, then the Javascript code tends to be large and/or unreadable, so apply this approach with care ).
Secondly you can have a stand alone GUI application, which runs independently of the browser. There is JavaFX if you into Java/Scala, or OpenGL if you are into C++ for example. If you do it stand alone, you can the enjoy a powerful langage but you certainly cannot upload it to the Web and share it with others easily.
I personally prefer a Web applicataion because HTML + Javascript makes a powerful GUI and it is easy to upload it to the Web and make it instantly available to others. Even speed is not a great concern because WebAssembly ( or even just asm.js ) lets you have close to native processing speed.
<Comment deleted by user>
When it comes to HTML + Javascript I regret that I have ever learned "HTML" in the sense of writing a file with HTML extension and expect this to be the basis of a web page.
What I really should have learned from the getgo is DOM + Javascript and this is what I strongly recommend to anyone approaching a Web from "tabula rasa".
HTML is none other than the serialized version, a descriptive language to create a DOM document. When you learn HTML you learn a serialization instead of the "thing".
DOM stands for Document Object Model. The idea behind this is that you can manipulate a document having a structure ( in particular a tree structure ) through standard procedure.
The naive way to manipulate a document would be for example to use a regulare expression to replace some text in the document. If you have a field "Name: Joe Doe", search for the pattern Name: *some name* and replace *some name* with an other name, The problem is you may have other parts in the document where the string "Name:" appears. In DOM you can have an element clearly identified which holds this name, and can manipulate directly this element ( for example a SPAN element with an ID and then use something like document.getElemenById(ID).innerHTML="Joe Doe2" to change it).
Any non trivial application, especially a GUI application will make heavy use of manipulating the DOM through Javascript, so it makes sense to build the whole document using Javascript and forget about HTML alltogether. In my app the actual HTML is only a DIV with and ID, and the script builds everything in this DIV from scratch. HTML with inline code ( with event handlers like onclick="do_something();" ) runs into difficulty when you have content security policies in place and anyway this is just old fashioned and non idiomatic.
For a complete beginner I recommend to study the DOM and try to build little structures with plain Javascript code.
I definitely not recommend using libraries like JQuery or D3.js to "make things easy". By today Javascript implements many features ( like selections, or manipulating style elements separately ) for which you needed a library in the old days.
Learn to solve things in pure Javascript. Build little structures from scratch ( like a BUTTON and a DIV which has a size and a backround color ) and try to make them interactive ( like when you push the BUTTON change the bacground color of the DIV to a random new color ).
When you have a feel for the DOM, Javascript ( and CSS for styling ), it is just a matter of scaling up to a more complex application.
What I really should have learned from the getgo is DOM + Javascript and this is what I strongly recommend to anyone approaching a Web from "tabula rasa".
HTML is none other than the serialized version, a descriptive language to create a DOM document. When you learn HTML you learn a serialization instead of the "thing".
DOM stands for Document Object Model. The idea behind this is that you can manipulate a document having a structure ( in particular a tree structure ) through standard procedure.
The naive way to manipulate a document would be for example to use a regulare expression to replace some text in the document. If you have a field "Name: Joe Doe", search for the pattern Name: *some name* and replace *some name* with an other name, The problem is you may have other parts in the document where the string "Name:" appears. In DOM you can have an element clearly identified which holds this name, and can manipulate directly this element ( for example a SPAN element with an ID and then use something like document.getElemenById(ID).innerHTML="Joe Doe2" to change it).
Any non trivial application, especially a GUI application will make heavy use of manipulating the DOM through Javascript, so it makes sense to build the whole document using Javascript and forget about HTML alltogether. In my app the actual HTML is only a DIV with and ID, and the script builds everything in this DIV from scratch. HTML with inline code ( with event handlers like onclick="do_something();" ) runs into difficulty when you have content security policies in place and anyway this is just old fashioned and non idiomatic.
For a complete beginner I recommend to study the DOM and try to build little structures with plain Javascript code.
I definitely not recommend using libraries like JQuery or D3.js to "make things easy". By today Javascript implements many features ( like selections, or manipulating style elements separately ) for which you needed a library in the old days.
Learn to solve things in pure Javascript. Build little structures from scratch ( like a BUTTON and a DIV which has a size and a backround color ) and try to make them interactive ( like when you push the BUTTON change the bacground color of the DIV to a random new color ).
When you have a feel for the DOM, Javascript ( and CSS for styling ), it is just a matter of scaling up to a more complex application.
<Comment deleted by user>
This topic has been archived and can no longer be replied to.