Re: Just Clipboard Manager
HTML схожий на хоч якийсь платформонезалежний стандарт для форм з кнопками. Будь-що інше для цієї задачі — це як прямий доступ до відеопам'яті замість stdin i stdout для вводу/виводу в консолі.
Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → Ваші проєкти → Just Clipboard Manager
Для відправлення відповіді ви повинні увійти або зареєструватися
HTML схожий на хоч якийсь платформонезалежний стандарт для форм з кнопками. Будь-що інше для цієї задачі — це як прямий доступ до відеопам'яті замість stdin i stdout для вводу/виводу в консолі.
Чому ж тоді автори JVM не вкрутили HTML? І порівняння я не зрозумів?
Немає нічого ідеального. Кожну мову, технологію, проект і код можна розкритикувати.
Звісно програміст має писати чистий і оптимізований код. Конкретно в даному випадку вихідний код займає 1 мб (це врахлвуючи файли тестів, іконки і т.п.), отже все решта додає компілятор, значить треба критикувати Visual Studio чому скомпільований проект для десктопної програми так багато важить ).
З усім з годен а з оцим не згоден бо 1мб коду != 1мб програми бо як туда на імпортувати бібліотек то можна зкомпілити і гігову програму.
Чому ж тоді автори JVM не вкрутили HTML? І порівняння я не зрозумів?
На той час html був молодим і мав досить бідні можливості, а Java-аплети просувались як заміна того, чого в чистому html не вистачає. До нашого часу аплети вмерли, але ті ж класи, що в аплетах, продовжують використовуватись у десктопній джаві.
Узагалі, це непогана ідея — компілювати html у java-клас віконної форми. Не здивуюсь, якщо хтось уже розробив щось подібне.
Аналогія відсилає до програм для DOS, що працюють у текстовому режимі екрану. Така програма може виводити текст, записуючи його в відеопам'ять екрану безпосередньо, або ж вона може виводити текст через stdout. Прямий запис у відеопам'ять має свої переваги, ним можна робити різні цікаві ефекти, якийсь час це було модно і круто — але така програма буде залежною від конкретної платформи (чи навіть конкретного заліза), перенести її на іншу ОС чи машину з іншою архітектурою буде складно. Тоді як стандартний вивід використовується на багатьох різних платформах, і програму, розраховану на роботу з ним, можна без суттєвої переробки перенести на інші платформи. Повертаючись до наших формочок, практично будь-яка бібліотека для них — це бібліотека однієї платформи, код для якої складно перенести на іншу платформу чи переписати на іншу мову — набір класів різний, схема взаємодії з ними різна. У той же час, html є скрізь — можна оформити програму, наприклад, у вигляді веб-сервера на локалхості, що взаємодіятиме з користувачем через браузер — таку програму можна буде запустити на безлічі різних систем, і вона скрізь зможе виконувати свою роботу, не вимагаючи окремих фронтендників для віндовс-десктопу, лінукс-десктопу, мобільних платформ тощо.
Звучить дещо шизуфато.
У той же час, html є скрізь — можна оформити програму, наприклад, у вигляді веб-сервера на локалхості, що взаємодіятиме з користувачем через браузер — таку програму можна буде запустити на безлічі різних систем, і вона скрізь зможе виконувати свою роботу, не вимагаючи окремих фронтендників для віндовс-десктопу, лінукс-десктопу, мобільних платформ тощо.
HTML є скрізь лише в тому смислі що переглядач для HTML є скрізь і штука в тому що навіть попри те що переглядач HTML є скрізь ніколи не зустрічав такого щоб розповсюджували HTML–файлик з програмою на JavaScript який відкриваєш в HTML–переглядачем і от тобі кросплатформенна програма. Вебщики розповсюджують свій монстроузний Electron (окремий фронтендник) і вже в ньому користувач запускає їхню програму а це рівнозначно програмам на таких кросплатформенних штуках як JVM, GTK, Qt, WxWidgets, Python, Tcl, Perl і будь–чому іншому що надає прослойку не привʼязану до ОС прослойку та програмою. Єдина суттєва відмінність між Electron та рештою полягає в тому що взяти якого–небудь верстальщика–явасценариста яких зараз розвелося стільки що куди не плюнь, обовʼязково влучиш в одного.
Задумка з HTTP–сервером якось занадто близька до божевільної ідеї писати під одну ОС, але потім розповсюджувати програму разом з ОС всередині файлу для віртуальної машини, але як бути у випадку коли потрібно не просто з БД взаємоідяти і в файлики писати а ще й робити якісь речі які HTTP–сервер чи браузер зробити не дозволить?
Спробу схвалюю, але 50мегабайтне одоробло-менджер буферу обміну це занадто.
Зараз усі так пишуть. QT тягне 100 метрів на хелло_ворлд.
Пройшли ті часи, коли писали на нормальних мовах
QT тягне 100 метрів на хелло_ворлд.
Га ?
Код такого hello_world'а в студію.
Прошу звернути увагу що тут не лише більше 100 Мб і всередині віруальної машини .NET, але й на додочу лише для Windows. Незважаючи на всі накладні витрати воно не кросплатформенне що слугувало б хоч якимсь виправданням. Виграє лише програміст.
Задумка з HTTP–сервером якось занадто близька до божевільної ідеї писати під одну ОС, але потім розповсюджувати програму разом з ОС всередині файлу для віртуальної машини, але як бути у випадку коли потрібно не просто з БД взаємоідяти і в файлики писати а ще й робити якісь речі які HTTP–сервер чи браузер зробити не дозволить?
Ідею з http-сервером використано, наприклад, у дистрибутивах пітона, де можна запустити сервер документації й дивитися довідку офлайн через браузер (підозрюю, цим рідко користуються, бо є зручніші альтернативи, але така можливість є). HTTP-сервер не зобов'язаний бути чимось роздутим і сидіти під віртуалізацією — фактично, це може бути щось на рівні простенької консольної програмки, але взаємодіяти з користувачем не через stdin/stdout, a через браузер і протокол http. Самий браузер тягати з дистрибутивом програми непотрібно — як правило, в системі він вже є. Серверна частина може взаємодіяти з системою, як їй заманеться — це звичайна програма, тільки без власного графічного вікна. Уся графіка та взаємодія з користувачем — через браузер, тому обмеженням є графічні можливості браузера. Також обмеженням може бути сумісність з багатьма різними браузерами, а не якимось конкретним (якщо від цього відійти, то справді доведеться тягати цей конкретний браузер разом з дистрибутивом програми). Кросплатформність серверної частини забезпечується приблизно так само, як кросплатформність консольної програми: це може бути програма для кросплатформного інтрпретатора назразок JVM, або ж це може бути переносний початковий код, що компілюється для різних систем.
Для відправлення відповіді ви повинні увійти або зареєструватися