Jednak tworzenie takiej aplikacji przypomina trochę programowanie dla DOS, czylu pusty ekran tekstowy lub graficzny bez żadnego menedżera interfejsu. W przypadku aplikacji desktopowej, system operacyjny zapewnia okienka, kontrolki w określonym stylu kolorystycznym.
W HTMLu też masz zestaw kontrolek. A jak chcesz mieć coś customowego to możesz zrobić własne komponenty z użyciem jakiegoś Reacta (albo nawet i bez niego). Plus jest masę bibliotek, które zapewniają ci już customowe widżety. Więc nie rozumiem tego argumentu.
Jeżeli ma się pomysł, żeby aplikacja miała wiele okien wyświetlanych obok siebie, to w aplikacji desktopowej nie ma żadnego problemu, natomiast w przeglądarkowej takiego czegoś nie ma, da się zrobić wyskakujące okienka w DIV, ale co aplikacja to trzeba to tworzyć od początku, oprogramować przeciąganie myszki, pasek tytułu. Można to też rozłożyć na kilka zakładek lub okien samej preglądarki, ale to też trzeba to samemu obsłużyć.
chodzi ci o tiling? To też ktoś coś takiego zrobił w React: https://github.com/nomcopter/react-mosaic
Standardowe czcionki i style są po prostu brzydkie
można ściągnąć z Google Fonts fajniejsze.
W przypadku layoutu to trzeba się pomęczyć z div. Często szybciej i łatwiej użyć table/tr/td, ale jest to uważane za nieprawidłowy sposób, pomimo, że pozwala uzyskać zamierzony efekt.
Trzeba po prostu poznać inne sposoby układania layoutu. był już layout na tabelkach, później była moda na float: left i inne haki, a teraz mamy flex i grid (swoją drogą grid to trochę jak tabelki, tylko dostosowane pod robienie layoutu). Jest lepiej, a nie gorzej.
współczesne IDE potrafią same wyświetlić metody dostępne dla danej zmiennej, które zależą od typu. W aplikacji przeglądarkowej jest tak naprawdę używany jeden język, jakim jest JavaScript. On jest niestety dynamicznie typowany, czyli ta sama zmienna raz może być liczbą, a raz napisem,
Ludzie, którym się to nie podoba, używają TypeScriptu.
również deklarowanie zmiennej nie jest obowiązkowe, a możliwe jest wielokrotne deklarowanie, to prowadzi do trudnych do wychwycenia błędów.
Mówisz o var, którego w nowym kodzie się zwykle nie używa, a używa się const i let, które rzucają błędem, jak ponownie zadeklarujesz. Poza tym można korzystać z linterów, jak chce się mieć większą kontrolę nad "trudnymi do wychwycenia błędami".
Kolejna sprawa jest taka, że JavaScript ma tylko jeden typ liczbowy i to zmiennoprzecinkowy.
Niby Number to podstawowy typ liczbowy i w większości tego się używa, jednak teraz wszedł jeszcze BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt
plus można korzystać z typowanych tablic i one też trzymają dane o określonym typie liczbowym.
Dodatkowo, z powodu dynamiczności typów, nie ma możliwości, żeby IDE do JavaScript po napisaniu zmiennej umiał podać, jaki to jest typ zmiennej i jakie ma metody lub pola, bo nie wiadomo, czy w danym momencie będzie to tekst, czy taki obiekt, czy inny obiekt.
Dlatego dużo ludzi pisze w TypeScripcie. Poza tym o jakim IDE mówisz? WebStorm, VSCode? Przecież one i tak dość sprytne są. Ew. kiedyś było coś takiego jak Tern, co ci dawał takie info.
Jakiś czas temu napisałem w C++ aplikację wyświetlającą spectrogram w czasie rzeczywistym. Później napisałem identyczną aplikację w HTML5/JavaScript i wydajnościowo nie udało mi się dorównać wersji w C++, Udało się uzyskać może góra 30% wydajności.
To normalne, że rozwiązanie w JavaScript będzie wolniejsze niż wersja natywna w C++. Tym niemniej w jaki sposób pisałeś wersję w JS? Ogólnie zasada jest taka, że jak chcesz mieć szybką grafikę w JS, to używa się do tego WebGL(w przyszłości WebGPU).
Kolejną sprawą jest obsługa plików binarnych. W desktopie nie ma z tym żadnego problemu, natomiast w JavaScript trzeba się namęczyc. Można plik jakoś zaczytać do bloba, wyciągnąć bajty, ale one będą albo jako napis (tekst), albo jako ciąg liczb, więc abo dane będą nieprawidłowe, albo wydajność będzie słaba.
Nie wiem, czy do końca rozumiem, o co ci chodzi, ale z moich doświadczeń w JS wkurza mnie, że nie mogę sobie zdefiniować "schema" dla pliku binarnego i zaciągnąć od razu semantycznie (tak jak w C++ da się zdefiniować struktury, a potem załadować dane z dysku od razu do pamięci i działać na strukturach), tylko zabawa z przetwarzaniem pojedynczych bajtów.
Nawet z plikami tekstowymi też jest trochę zachodu, choćby zwykłe zaczytanie pliku .txt do zmiennej tekstowej, albo odczyt tekstu linia po linii. W C# to nie problem, a w JS trzeba się gimnastykować, chociaż jest to teoretycznie możliwe.
nie rozumiem, w czym problem.
Żeby podzielić tekst na linie można zrobić np. tak:
text.split('\n')
Sam konwerter też już mam w JavaScript, ale on nie potrafi zaczytać i zapisać pliku, tylko do jednego pol wkleja się tekst z pliku TXT, a skonwertowany tekst trafia do drugiego pola.
Też nie do końca rozumiem problem. Albo masz po prostu nieaktualną wiedzę z JS.
Jeśli chodzi o pliki z dysku, to wczytujesz za pomocą inputa: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file
No i pamiętam, że jakoś się dało wygenerować plik po stronie frontendu do ściągnięcia (chyba za pomocą bloba?).
Plus jest coś takiego jak WebShare API, przydatne na komórkach.
Więc da się, ale faktycznie, nie jest jest to specjalnie wygodne. Więc jak coś potrzebuje mocno korzystać z dysku, to można to opakować w Electrona i zrobić webową aplikację desktopową (nie będzie to idealne, apki na Electronie są często krytykowane za słabą wydajność i zżeranie zasobów).
Mam też aplikację emulującą mikrokomputer oparty na Z80. W C++ czy C# to nie problem. Nieraz myślałem, żeby przerobić to na JavaScript, aby móc uruchomić w telefonie i zapomnieć o wersji w C++, ale obawiam się, że wydajnościowo nie dorównam (będzie dużo gorzej), a dodatkowo musiałbym całkowicie inaczej podejść do plików konfiguracyjnych.
Pamiętaj, że przeglądarka zapewnia dzisiaj coś takiego jak WebAssembly, do którego można kompilować kod w różnych językach (między innymi w C++). Ludzie korzystają z tego do portowania apek C++ do przeglądarki.
TL;DR mam wrażenie, że masz nieaktualną wiedzę z JS i siejesz FUDy.
