New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTML rewrite? #1285
Comments
I guess the idea makes sense to some degree. However I assume it might have issues with scaling. Some projects from users are rather big with many different files. All of them would need to be uploaded (into memory at least) and downloaded to be used inside a web application. This might increase hardware spec requirements actually and it might make the application more annoying to use overall. Web browsers have changed a lot over time but they still lack features of native applications. For example our plugin system wouldn't work and integrating currently used Python libraries would at least be extremely difficult. |
@kingsuper195 has written:
I know where the Hype for Web-Apps coming from, it's a relative cheap way, to port a real Web/Cloud application, to a Smartphone/Desktop. With that in mind, why should we want to rebuild a running Program to a new technology, just to follow the Hype-Train? For me, as a web-developer, by profession, I see no need for this! I have started a real Web-Application1, a website, for authors, also some Tools too run with it. There I will use HTML/CSS/JS for the frontend, PHP/D for the backend. I will rather write a Plugin for Manusskript, then a simple HTML/CSS/JS based App for Authors, because the performance and a lot of other Problems I see with such kind of Application! @TheJackiMonster has written:
Right performance, also, the GUI, there are no real Sets of defined GUI-Elements, there are libraries, but all have their own way to do things. @TheJackiMonster has written:
We have at the moment enough Problems with performance, Just try to edit a 80k or 100k word text in a text Area, or even more evil, with a WSYWIG-Editor. I have done both and the lag was really not bearable2! Also, there are some Tools which are going this route. Manusskript has its shortcomings, but, at least for me, is the best Tool for this kind of Job. With the upcoming GTK rewrite and the resulting performance boost and the plugin-api, Manusskript is on the right Track for the future. A part of me, thinks, when we should leave python, we should go for a compiled, performant language, like C++, RUST, D or so on. I have a project, just shy 1 million words and when I last try to see the exact number, Manusskript was more than half an hour working, until the next click is noticed. This is, I know a Problem of the core concept of Manuskript and the Data is managed, I know it and I have my workflow build around it, so the limitations want to bother me. With a rewrite with HTML/CSS/JS, the limitation will be even bigger and lesser possibilities to find ways around them! That is also why, I haven't moved to any other authoring-tool, where I have no real problem, to write my own features and solutions! I have tried so simply every authoring-software, which runs on Linux, the result was, everything begins to fuck up everything, when you have more than 150 Characters, 500 Places and 500k Words3. Sometimes so spectacular, that while the Import, 16G of RAM, 64G of SWAP was not enough, for the Import, from the 6 days of letting the Desktop running, to do his thing.... Footnotes
|
My thought is that Manuskript is a python program. There may be plenty of good reasons to have a writing app use HTML or c++ or Rust but that's not Manuskript. If someone wants to make their own software that's compatible with .msk files I'd support that. It might even make sense seeing the current circumstances but Manuskript was supposed to be a free open source python based writing program. |
Progressive web apps can be installed on most systems. If manuskript was translated/rewritten into html/JavaScript/css, it could have much better mobile support and ability to port. It is just an idea, I know it would take years of work to do. Building it would also be possible.
The text was updated successfully, but these errors were encountered: