Году так в 2009-м, когда я, будучи студентом, изучал основы веба (и быдлокодил на пхп), синтаксис жабаскрипта был довольно прост и понятен, и на нём было несложно написать динамическое обновление страницы через аякс. А теперь, блять, каждые три месяца выходит хуева гора новых фреймворков, и нормальный фронтендщик обязан их знать все (иначе нахуй он нужен, на хедхантере толпа новых в очередь выстроилась).
Когда я вижу шутейки про весь этот фронтенд-ад, я косплею Эдди Мерфи и возвращаюсь к своим службам на нормальной человеческой джаве.
Когда я вижу шутейки про весь этот фронтенд-ад, я косплею Эдди Мерфи и возвращаюсь к своим службам на нормальной человеческой джаве.
Опять же, я об этом писал. Ангуляру - 10 лет, он сейчас топ по поиску сотрудников, реакту - 8 лет, он на втором месте. Есть дохрена фреймворков, но они занимают очень малую долю рынка. Тот же jquery который безнадежно устарел, сейчас востребован. Нужно поддерживать старые проекты.
Я не говорю что это хорошо или плохо, это факт. И слова вроде: "не угадал - проебал время" не имеют ничего общего с реальностью
Я не говорю что это хорошо или плохо, это факт. И слова вроде: "не угадал - проебал время" не имеют ничего общего с реальностью
ты видел чем это заканчивается?
Мне кажется что в этом комиксе было что другое
Ну там про котиков, еду, фильмы, социальные взгляды
Ьмцкмлйадйашйвтйдаца...
Ну там про котиков, еду, фильмы, социальные взгляды
Ьмцкмлйадйашйвтйдаца...
это скорее минус чем плюс. Когда в функцию кидаешь не то что она ожидает и при этом код "как-то" работает, это страшно
Жесткая типизация - лучшее что придумали в программировании
Жесткая типизация - лучшее что придумали в программировании
Низкий порог вхождения порождает кучу долбоебов. Однако, если бы та же мобильная разработка была так плоха Flutter бы не набирал такую популярность. Мне самому идея того что ЖСом пытаются заткнуть каждую дырку нравится не сильно, однако если ее затыкают знающие люди, то получается норм.
Как человек работающий за 1с я хочу прищемить пальцы дверью тому кто продумывал функционал программы.
Если бы можно было сделать тот же 1С, но круче и удобнее, его бы уже сделали и этот продукт успешно заменил бы собой данную поделку. Однако годы идут, все плюются, плачут, но пользуются, а ближайших конкурентов не видать, видимо не все так просто.
Я сам в вопросах 1С просто мимокрокодил, но будучи молодым и горячим врываясь в легаси код часто думал "вот я щас как тут все это говно перепишу и будет норм", по итогу оказывалось, что и говно бывает на своем месте, если его писал кто-то умнее тебя.
Я сам в вопросах 1С просто мимокрокодил, но будучи молодым и горячим врываясь в легаси код часто думал "вот я щас как тут все это говно перепишу и будет норм", по итогу оказывалось, что и говно бывает на своем месте, если его писал кто-то умнее тебя.
Но там нет элементарных вещей (или это я такой избранный) например кнопки отмены последнего действия.
Кому нахуй тут нужна твоя правда, уважаемый пидор.
На питоне и 1с же
Если тебе скучно постал без убийств проходить, то это с тобой что-то не так.
Скажи, а операционку на js написать можно?
А мне как раз интересно, можно ли написать на js операционку, чтобы продолжить речь персонажа из поста.
Что эмулятор 86-го проца на нём можно написать, я уже знаю.
Что эмулятор 86-го проца на нём можно написать, я уже знаю.
Чисто на JS - нет. Возьмём, к примеру, какой-нибудь ARM, у них все проще. Чтоб начать работать, надо просто положить программу в машинных кодах этого арма в правильное место флеш-памяти. Поэтому придется в начале реализовать написать js-движок, который получит управление при старте, написать js-врапперы для прямой работы с памятью, а уже потом начать исполнение js-кода операционки.
1. Выкидываем кучу существующих инструментов. "Браузер и верстка сделали половину работы" - так ОС/графический тулкит тоже сделали, предоставляя программисту всякие кнопочки и прочее.
2. JS тупо медленнее, чем даже Java/NET, не говоря уже о компилируемых языках
3. JS жрет кучу памяти сам по себе, потому что объекты создаются на каждый чих, которые потом заботливо удаляет GC. А уж подход всяких Redux, пропагандируемый как труЪ - это вообще мрак и ужас. Иммутабельный стейт, который меняется на каждый чих.
4. JS позволяет стрелять себе в ногу со скоростью пулемета и не заметить этого до рантайма. Разумеется, всякие C++ и даже C# не защищены от этого, но все же типизация сильно облегчает работу. А ведь там еще не самая крутая система типов. Если посмотреть в сторону Rust или, о боже, функциональных языков, там такие возможности типизации, что вообще огонь.
5. И все это тащит за собой браузер. Каждое приложение тащит ебаный браузер.
Если уж вы делаете приложение в виде веба - то пусть оно тупо будет в браузере. С возможностью создавать вкладки, что-то копировать, сохранять и прочими преимуществами веба.
2. JS тупо медленнее, чем даже Java/NET, не говоря уже о компилируемых языках
3. JS жрет кучу памяти сам по себе, потому что объекты создаются на каждый чих, которые потом заботливо удаляет GC. А уж подход всяких Redux, пропагандируемый как труЪ - это вообще мрак и ужас. Иммутабельный стейт, который меняется на каждый чих.
4. JS позволяет стрелять себе в ногу со скоростью пулемета и не заметить этого до рантайма. Разумеется, всякие C++ и даже C# не защищены от этого, но все же типизация сильно облегчает работу. А ведь там еще не самая крутая система типов. Если посмотреть в сторону Rust или, о боже, функциональных языков, там такие возможности типизации, что вообще огонь.
5. И все это тащит за собой браузер. Каждое приложение тащит ебаный браузер.
Если уж вы делаете приложение в виде веба - то пусть оно тупо будет в браузере. С возможностью создавать вкладки, что-то копировать, сохранять и прочими преимуществами веба.
Все то, что ты сейчас пишешь про JS раньше писали про Java - и что она медленнее C/C++ (в разы), и что память расходует как попало (и, кстати, до сих пор), и что она тащит за собой тяжелый JVM. Во времена, когда приложения занимали десятки мегабайт оперативной памяти, эта ваша Ява начинала разговор с сотни и страшно тупила.
И все те аргументы, которыми защищали JAVA - подойдут и для JS - он гораздо лаконичнее, работает на любом железе, лучше приспособлен для современных интерфейсных решений.
И все те аргументы, которыми защищали JAVA - подойдут и для JS - он гораздо лаконичнее, работает на любом железе, лучше приспособлен для современных интерфейсных решений.
До сих пор не считаю, что сотни метров на простенькое приложение или несколько гигов на штук пять вкладок в браузере - это норма. На любом железе работает Си. Вот прям практически абсолютно на любое самое извращенное дерьмо можно найти порт GCC. Но это из разряда "разрешите доебаться".
Зачем ты сравниваешь ботинки с перчатками? Джава для бэкенда, жабаскрипт для фронтенда.
Все таки согласись, в наше время ресурсы компа не такой уж дефицит. Часто нужно что-то не слишком сложное, считалка, подводила, учитывала, и делать такую программу путем скурпулезной экономии не совсем обязательно. Браузер сейчас есть на каждом компе, часто это единственная запущенная программа (причем на любой платформе), и логично пользоваться им для всяких банальных нужд, и если есть возможность несложно написать для этого прогу, то почему от этого нужно отказаться? Ради каких религиозных идей?
Я могу ответить на это с точки зрения пользователя и с точки зрения разработчика.
С точки зрения пользователя, я просто хочу, чтобы софт летал.
Если посмотреть на шутки про хром и ОЗУ, то отсутствие дефицита ресурсов тут как-то уже и не так очевидно. Ну даи хрен с ней, с ОЗУ. Компьютеры по сравнению с девяностыми и началом нулевых стали быстрее в десятки раз. А обычный прикладной софт, который не занимается тяжёлыми вычислениями, как тормозил так и тормозит. И я не уверен, что софт стал в десятки раз более навороченным. Какой-нибудь Outlook 360 - какой он, сука, неповортливый. Современный скайп vs скайп десять лет назад. Что изменилось? Внешний вид, добавили всяких стикеров и ботов, убрали кучу функций. В итоге, он работает чуть ли не медленнее, а памяти потребляет больше раз в десять. И так, сука, почти везде.
У меня возникает закономерный вопрос: а какого, спрашивается, хуя? Какого хрена компы становятся все мощнее, а прикладной софт становится только тяжелее, но никак не быстрее? А иногда, даже медленнее. И на что ушло два десятилетия прогресса? На красивые иконки, альфа-блендинг и поддержку разных DPI (хуевую)?
С точки зрения разработчика, мне просто не нравится, в какую жопу идет индустрия.
С тем же браузером не все так просто. Если вы хотите дать пользователю простенькое приложение, вряд ли это будет один index.html? Хотя это можно так сделать, это будет работать, самое главное, это будет работать ВЕЗДЕ, где есть браузер. Даже не так. Оно будет работать ВЕЗДЕ и без изменений, один и тот же файл. Круто. Но нет, обычно все это запаковывают в какой-то пакет, цепляют к нему движок хрома в сто раз больше самого приложения и отдают в таком виде. И вот оно уже не такое и кросс-платформенное, потому что этот пакет надо будет собрать под разные платформы, укомплектовать соответствующими хромами.
Едем дальше. Если вам не хватает простеньких операций в браузере, а хотите, к примеру, работать с файловой системой или еще чем-то в ОС, вам никто не даст это сделать из браузера. Поэтому вы берете nodejs, опять хром и все повторяется снова. (Кстати, напомню, какой-нибудь .NET Core/Mono и Java будут работать на любой поддерживаемой платформе БЕЗ перекомпиляции. Условный jar запустится везде, где есть java runtime). Для взаимодействия с сервером нам придется ебаться и писатьзапросы, запросы, запросы. Там, где даже на сраном Visual Basic родом из 90х, я тыкал два раза на кнопочку в редакторе Visual Studio и мог в обработчике события что-то писать, теперь нужно знатно поебаться. Ладно, у нас получилось клиент-серверное приложение, круто. Может быть, я смогу как-нибудь использовать его удаленно? Не с помощью богомерзкого RDP или X-Forwarding, которые мне тупо картинку передают, а запустить полностью локальный GUI у себя, который будет ходить в бэкенд на удаленную машину? Это же ровно то, для чего придуман веб? У вас же уже HTTP запросы под капотом? Я так думаю, эту функциональность можно добавить практически бесплатно? Что? Снова нет?
Что мы имеем? Мы имеем пирамиду костылей и велосипедов, которую заботливо выстраиваем 30 лет. Мы накрутили множество слоев, чтобы сделать из одной технологии что-то совершенно иное, для чего она вовсе не задумывлась. Мы тащим функциональность ОС в браузер. Мы рисуем контролы ручками, когда они уже есть. Иногда даже диалоги работы с файлами рисуют (привет, последний офис). Мы используем клиент-серверные приложения локально и без возможности воспользоваться преимуществами такого подхода. Мы изобретаем WASM, чтобы код в браузере не так сильно лагал, а потом портируем туда .NET. Теперь ты можешь запускать виртуальную машину, пока запускаешь виртуальную машину.
Это практически как эволюция. Что-то новое не может возникнуть из ниоткуда, оно возникает из "предков" маленькими шажками. И дальше пиздец будет только усиливаться. Что можно предложить в замен? Ну ладно, вот вам немного фантазий и мечтаний.
- Вы хотите писать приложения, которые будут работать везде и на любой платформе?
- Вы не используете натинвые контролы от ОС, а рисуете все сами (и не только веб. GTK, Qt, WPF итп).
- Хотите, чтобы было быстро?
- Хотите клиент-сервер?
Окей, нам нужен 15й стандарт, который решит все наши проблемы. Вместо того, чтобы тащить все в браузер, предлагаю браузер просто выкинуть нахуй. Пусть каждая ОС предоставляет стандартный API поверх какой-нибудь low-level virtual machine, того же WASM и стандартный же способ описания интерфейса. На базе HTML+CSS, но из него можно повыкидывать кучу легаси, добавить то, чего не хватает. (К примеру, всякие XAML-based языки разметки во всяких Android или WPF в некоторых аспектах круче HTML). У приложения есть окно (или окна), в которое оно может рисовать. Вам не нужен отдельный веб-сервер и HTTP. ОС уже предоставляет вам какой-то клиент-серверный API, при этом вам абсолютно плевать, какой там транспорт. В итоге, при работе локально у вас быстрый доступ без всяких затрат на генерирование и парсинг строкового протокола с передачей по TCP в localhost, а, к примеру, shared memory. Но в то же время вы можете спокойно вынести фронтенд на удаленную машину, и запросы прозрачно превратятся в HTTP или что-нибудь еще. Охуенно же.
С точки зрения пользователя, я просто хочу, чтобы софт летал.
Если посмотреть на шутки про хром и ОЗУ, то отсутствие дефицита ресурсов тут как-то уже и не так очевидно. Ну даи хрен с ней, с ОЗУ. Компьютеры по сравнению с девяностыми и началом нулевых стали быстрее в десятки раз. А обычный прикладной софт, который не занимается тяжёлыми вычислениями, как тормозил так и тормозит. И я не уверен, что софт стал в десятки раз более навороченным. Какой-нибудь Outlook 360 - какой он, сука, неповортливый. Современный скайп vs скайп десять лет назад. Что изменилось? Внешний вид, добавили всяких стикеров и ботов, убрали кучу функций. В итоге, он работает чуть ли не медленнее, а памяти потребляет больше раз в десять. И так, сука, почти везде.
У меня возникает закономерный вопрос: а какого, спрашивается, хуя? Какого хрена компы становятся все мощнее, а прикладной софт становится только тяжелее, но никак не быстрее? А иногда, даже медленнее. И на что ушло два десятилетия прогресса? На красивые иконки, альфа-блендинг и поддержку разных DPI (хуевую)?
С точки зрения разработчика, мне просто не нравится, в какую жопу идет индустрия.
С тем же браузером не все так просто. Если вы хотите дать пользователю простенькое приложение, вряд ли это будет один index.html? Хотя это можно так сделать, это будет работать, самое главное, это будет работать ВЕЗДЕ, где есть браузер. Даже не так. Оно будет работать ВЕЗДЕ и без изменений, один и тот же файл. Круто. Но нет, обычно все это запаковывают в какой-то пакет, цепляют к нему движок хрома в сто раз больше самого приложения и отдают в таком виде. И вот оно уже не такое и кросс-платформенное, потому что этот пакет надо будет собрать под разные платформы, укомплектовать соответствующими хромами.
Едем дальше. Если вам не хватает простеньких операций в браузере, а хотите, к примеру, работать с файловой системой или еще чем-то в ОС, вам никто не даст это сделать из браузера. Поэтому вы берете nodejs, опять хром и все повторяется снова. (Кстати, напомню, какой-нибудь .NET Core/Mono и Java будут работать на любой поддерживаемой платформе БЕЗ перекомпиляции. Условный jar запустится везде, где есть java runtime). Для взаимодействия с сервером нам придется ебаться и писатьзапросы, запросы, запросы. Там, где даже на сраном Visual Basic родом из 90х, я тыкал два раза на кнопочку в редакторе Visual Studio и мог в обработчике события что-то писать, теперь нужно знатно поебаться. Ладно, у нас получилось клиент-серверное приложение, круто. Может быть, я смогу как-нибудь использовать его удаленно? Не с помощью богомерзкого RDP или X-Forwarding, которые мне тупо картинку передают, а запустить полностью локальный GUI у себя, который будет ходить в бэкенд на удаленную машину? Это же ровно то, для чего придуман веб? У вас же уже HTTP запросы под капотом? Я так думаю, эту функциональность можно добавить практически бесплатно? Что? Снова нет?
Что мы имеем? Мы имеем пирамиду костылей и велосипедов, которую заботливо выстраиваем 30 лет. Мы накрутили множество слоев, чтобы сделать из одной технологии что-то совершенно иное, для чего она вовсе не задумывлась. Мы тащим функциональность ОС в браузер. Мы рисуем контролы ручками, когда они уже есть. Иногда даже диалоги работы с файлами рисуют (привет, последний офис). Мы используем клиент-серверные приложения локально и без возможности воспользоваться преимуществами такого подхода. Мы изобретаем WASM, чтобы код в браузере не так сильно лагал, а потом портируем туда .NET. Теперь ты можешь запускать виртуальную машину, пока запускаешь виртуальную машину.
Это практически как эволюция. Что-то новое не может возникнуть из ниоткуда, оно возникает из "предков" маленькими шажками. И дальше пиздец будет только усиливаться. Что можно предложить в замен? Ну ладно, вот вам немного фантазий и мечтаний.
- Вы хотите писать приложения, которые будут работать везде и на любой платформе?
- Вы не используете натинвые контролы от ОС, а рисуете все сами (и не только веб. GTK, Qt, WPF итп).
- Хотите, чтобы было быстро?
- Хотите клиент-сервер?
Окей, нам нужен 15й стандарт, который решит все наши проблемы. Вместо того, чтобы тащить все в браузер, предлагаю браузер просто выкинуть нахуй. Пусть каждая ОС предоставляет стандартный API поверх какой-нибудь low-level virtual machine, того же WASM и стандартный же способ описания интерфейса. На базе HTML+CSS, но из него можно повыкидывать кучу легаси, добавить то, чего не хватает. (К примеру, всякие XAML-based языки разметки во всяких Android или WPF в некоторых аспектах круче HTML). У приложения есть окно (или окна), в которое оно может рисовать. Вам не нужен отдельный веб-сервер и HTTP. ОС уже предоставляет вам какой-то клиент-серверный API, при этом вам абсолютно плевать, какой там транспорт. В итоге, при работе локально у вас быстрый доступ без всяких затрат на генерирование и парсинг строкового протокола с передачей по TCP в localhost, а, к примеру, shared memory. Но в то же время вы можете спокойно вынести фронтенд на удаленную машину, и запросы прозрачно превратятся в HTTP или что-нибудь еще. Охуенно же.
Выкинуть браузер, чтобы сделать браузер?
Вроде когда-то браузеры могли юзать диск, потом это убрали из-за вирусности. Потом еще были еще hta, хз наксколько они кроссплатформены, вряд ли сильно, но отлично работали, и их перестали развивать из-за вирусности.
Есть впечатление, что геморой, который стоит между js-быдлокодером нормальной программой, это некая защита, чтобы он писал поменьше вирусни.
А вообще, конечно, кода-нибудь придет Нео и перепрограммирует все с нуля, и это будет новый правильный мир.
Вроде когда-то браузеры могли юзать диск, потом это убрали из-за вирусности. Потом еще были еще hta, хз наксколько они кроссплатформены, вряд ли сильно, но отлично работали, и их перестали развивать из-за вирусности.
Есть впечатление, что геморой, который стоит между js-быдлокодером нормальной программой, это некая защита, чтобы он писал поменьше вирусни.
А вообще, конечно, кода-нибудь придет Нео и перепрограммирует все с нуля, и это будет новый правильный мир.
1. Не совсем. Выкинуть стек велосипедов и костылей, который создавался в 90х, чтобы рисовать новостные сайты, и сделать новый, ориентированные под современные потребности - кросс-платформенную разработку приложений. Отличия я упомянул, и это только то, что пришло мне сейчас в голову.
2. Разумеется, это защита. Код в браузере лишен всякого доступа в систему, иначе какой-нибудь рекламный банер на джое мог бы пиздить твои данные и устанавливать майнеры.
3. Я понимаю, что это не сбыточные мечты.
2. Разумеется, это защита. Код в браузере лишен всякого доступа в систему, иначе какой-нибудь рекламный банер на джое мог бы пиздить твои данные и устанавливать майнеры.
3. Я понимаю, что это не сбыточные мечты.
Я лично не вижу большой проблемы в установке майнера у меня на компе джоевской рекламой. Может быть. НО. Пусть оно у меня сначала спросит об этом. Приложения же в гуглплее спрашивают тебя за всю фигню, что им можно, а что нельзя. И это даже не приложения спрашивают, а система, в соответствии с требованиями приложения. Да, получится тогда, что заходишь на сайт, а он тебя начинает за всю хуйню спрашивать, семки есть? а если найду? Но опять же, сейчас похожего говна и так на сайтах полно: куки можно? ок. подпишитесь на новости? нет. разрешить оповещения? блокировать. город такой-то? ... и т.д. И пользователь логичным образом закрывает нахуй такой сайт, потому что хотел прочитать про что-то, и про что уже забыл, пока все это кликал. Я к тому, что это нормальная была бы система, и вполне себе саморегулирующаяся. Что-то можно по умолчанию, чтобы лишний раз не дергать юзера. Например там 10мб под собственные нужды в виде sqlite базки например.
> У меня возникает закономерный вопрос: а какого, спрашивается, хуя? Какого хрена компы становятся все мощнее, а прикладной софт становится только тяжелее, но никак не быстрее?
Каганов лет десять назад примерно то же самое писал (правда, применительно к дистрам линукса).
Каганов лет десять назад примерно то же самое писал (правда, применительно к дистрам линукса).
> С точки зрения пользователя, я просто хочу, чтобы софт летал.
И сразу мимо. Ни у кого это не приоритет. Приоритет - чтобы софт наличествовал и работал. А если он будет летать - хорошо. Но сперва - наличие и работоспособность.
Но посмотрим на скорость. Берем любуй не-веб-два-нольный сайт, и... он грузится существенно быстрее, но он грузится НА КАЖДУЮ СРАНУЮ ОПЕРАЦИЮ. В лучшем случае перегружает фрейм, в худшем - полностью обновляет всю страницу.
Ну ладно, скажешь ты, ведь аякс появился очень давно, может быть стоило остановиться на каком-нибудь jquery и норм?
Но это ломает логику кнопки "назад" - нажал ее и вся страница улетела в жопу. Нужна навигация, которая бы как бы работала в рамках одного веб-приложения, но не перезагружала ничего. Да и подлый юзер может взять и нажать F5 в неподходящем месте. И вот у тебя уже есть роутер и над тобой нависает тень редукса.
А чтобы твое творение отображалось на разных мобильных и десктопных устройствах придется добавить @media и grid. Чтобы выиграть в производительности, но не проебать древние браузеры, придется добавить полифил. И так одно, другое, третье.
Что? Ты хочешь все-таки быстро работающее приложение? Не вопрос, но тогда тебе придется изучить немного больше, чем краткий вводный курс в современные фреймворки, чтобы знать, что и как нужно. Берешь себе в помощь Lighthouse и вперед, покорять вершины и глубины.
P.S.: А нативные интерфейсы как правило уебищны, попробуй в селект запихнуть, скажем, выбор языка с иконкой флага - удивишься.
И сразу мимо. Ни у кого это не приоритет. Приоритет - чтобы софт наличествовал и работал. А если он будет летать - хорошо. Но сперва - наличие и работоспособность.
Но посмотрим на скорость. Берем любуй не-веб-два-нольный сайт, и... он грузится существенно быстрее, но он грузится НА КАЖДУЮ СРАНУЮ ОПЕРАЦИЮ. В лучшем случае перегружает фрейм, в худшем - полностью обновляет всю страницу.
Ну ладно, скажешь ты, ведь аякс появился очень давно, может быть стоило остановиться на каком-нибудь jquery и норм?
Но это ломает логику кнопки "назад" - нажал ее и вся страница улетела в жопу. Нужна навигация, которая бы как бы работала в рамках одного веб-приложения, но не перезагружала ничего. Да и подлый юзер может взять и нажать F5 в неподходящем месте. И вот у тебя уже есть роутер и над тобой нависает тень редукса.
А чтобы твое творение отображалось на разных мобильных и десктопных устройствах придется добавить @media и grid. Чтобы выиграть в производительности, но не проебать древние браузеры, придется добавить полифил. И так одно, другое, третье.
Что? Ты хочешь все-таки быстро работающее приложение? Не вопрос, но тогда тебе придется изучить немного больше, чем краткий вводный курс в современные фреймворки, чтобы знать, что и как нужно. Берешь себе в помощь Lighthouse и вперед, покорять вершины и глубины.
P.S.: А нативные интерфейсы как правило уебищны, попробуй в селект запихнуть, скажем, выбор языка с иконкой флага - удивишься.
> Приоритет - чтобы софт наличествовал и работал.
Я подразумвал, что софт есть. Глупо спорить об неэффективности того, чего нет. Но вот такое "на, братишка, я тебе покушать принес" меня совершенно не радует, и жрать хоть какое-то дерьмо на лопате - удовольствие ниже среднего, я вам скажу.
Чувак, ты приводишь в пример SPA. Где я выступаю против SPA (разумеется, там, где оно нужно, а не так, как сделал хабр в мобильной версии)? Я выступаю против того, что все и вся делать на вебе, потом запаковывать свое поделие вместе с очередным хромом и отдавать юзверям.
А в классических UI-тулкитах (поехали: GDI+ и MFC (для извращенцев) WinForms, WPF и WPF-подобные поделия, GTK, Qt, WxWidgets, стопицот джавных тулкитов, которые я не знаю), сюрприз-сюрприз, нет никаких загрузок на каждую операцию. И кнопок "назад" там тоже нету. Или есть, но они часть приложения и работают по логике приложения.
Что касается всяких redux... Пока что самое удобное, что я видел для связи данных и отображения, это паттерн MVVM, в особенности его реализация на Reactive Extensions в тулките Avalonia UI, но он настолько сырой, насколько возможно.
> Что? Ты хочешь все-таки быстро работающее приложение?
Я вообще очень далеко от мира веб и прочей UI-разработки, с фреймворками и прочими лайтхаусами. Я сказал, чего я хочу, как юзверь.
> А нативные интерфейсы как правило уебищны
А полу-нативные, такие, как WPF, Qt и прочие, которые рисуют контролы сами с помощью всяких OpenGL/DirectX, но без браузеров и прочих JS, позволяют творить с интерфейсом такое, что HTML даже не снилось. Как на счет приложения, ВЕСЬ интерфейс которого, с кнопочками, менюшками, текстовыми полями и всем прочим можно БЫСТРО масштабировать туда-сюда, двигать?
Я подразумвал, что софт есть. Глупо спорить об неэффективности того, чего нет. Но вот такое "на, братишка, я тебе покушать принес" меня совершенно не радует, и жрать хоть какое-то дерьмо на лопате - удовольствие ниже среднего, я вам скажу.
Чувак, ты приводишь в пример SPA. Где я выступаю против SPA (разумеется, там, где оно нужно, а не так, как сделал хабр в мобильной версии)? Я выступаю против того, что все и вся делать на вебе, потом запаковывать свое поделие вместе с очередным хромом и отдавать юзверям.
А в классических UI-тулкитах (поехали: GDI+ и MFC (для извращенцев) WinForms, WPF и WPF-подобные поделия, GTK, Qt, WxWidgets, стопицот джавных тулкитов, которые я не знаю), сюрприз-сюрприз, нет никаких загрузок на каждую операцию. И кнопок "назад" там тоже нету. Или есть, но они часть приложения и работают по логике приложения.
Что касается всяких redux... Пока что самое удобное, что я видел для связи данных и отображения, это паттерн MVVM, в особенности его реализация на Reactive Extensions в тулките Avalonia UI, но он настолько сырой, насколько возможно.
> Что? Ты хочешь все-таки быстро работающее приложение?
Я вообще очень далеко от мира веб и прочей UI-разработки, с фреймворками и прочими лайтхаусами. Я сказал, чего я хочу, как юзверь.
> А нативные интерфейсы как правило уебищны
А полу-нативные, такие, как WPF, Qt и прочие, которые рисуют контролы сами с помощью всяких OpenGL/DirectX, но без браузеров и прочих JS, позволяют творить с интерфейсом такое, что HTML даже не снилось. Как на счет приложения, ВЕСЬ интерфейс которого, с кнопочками, менюшками, текстовыми полями и всем прочим можно БЫСТРО масштабировать туда-сюда, двигать?
> Я подразумвал, что софт есть.
А не надо принимать это как должное. Софт определяется бюджетом. То, что позволяют делать сегодня фреймворки одному разработчику за год - десять лет назад делала команда, а двадцать лет назад было вообще невозможно сделать в какие-то вменяемые сроки.
> Я выступаю против того, что все и вся делать на вебе
Ну так если есть куча денег и времени или в качестве хобби - пиши хоть на ассеблере.
Или если производительность абсолютно критична, хотя в таких случаях обычно тяжелые вещи выносят в библиотеки - вон, в науке вовсю пользуются питоном, а более тормозного и прожорливого говна мир еще не видывал (ну, может кроме Ruby), но какая разница насколько он быстр, если он всего лишь обертка для обращения к мат. библиотекам?
> Как на счет приложения, ВЕСЬ интерфейс которого, с кнопочками, менюшками, текстовыми полями и всем прочим можно БЫСТРО масштабировать
Да вообще как нехуй. К слову, браузеры тоже умеют в 2D-акселерацию.
А не надо принимать это как должное. Софт определяется бюджетом. То, что позволяют делать сегодня фреймворки одному разработчику за год - десять лет назад делала команда, а двадцать лет назад было вообще невозможно сделать в какие-то вменяемые сроки.
> Я выступаю против того, что все и вся делать на вебе
Ну так если есть куча денег и времени или в качестве хобби - пиши хоть на ассеблере.
Или если производительность абсолютно критична, хотя в таких случаях обычно тяжелые вещи выносят в библиотеки - вон, в науке вовсю пользуются питоном, а более тормозного и прожорливого говна мир еще не видывал (ну, может кроме Ruby), но какая разница насколько он быстр, если он всего лишь обертка для обращения к мат. библиотекам?
> Как на счет приложения, ВЕСЬ интерфейс которого, с кнопочками, менюшками, текстовыми полями и всем прочим можно БЫСТРО масштабировать
Да вообще как нехуй. К слову, браузеры тоже умеют в 2D-акселерацию.
> Ни у кого это не приоритет. Приоритет - чтобы софт наличествовал и работал. А если он будет летать - хорошо.
Ха-ха, ёпт. Мало ты с людьми общался.
Изразговора срача с начальником на прошлой работе (между прочим, инженером):
- Это чё за пиздец, почему интерфейс серым становится? Мне через 10 минут уезжать на выставку, а с программой, которую я же ещё в прошлом году у другого программиста принимал, такой пиздец - это всё вы, программисты виноваты!
- Блять, ты приоритеты расставлять умеешь? Одно дело, когда датчики нихуя не меряют и с них информация не приходит, и совсем другое, когда во время измерений всего лишь интерфейс блокируется, чтобы пользователь не мог в галочки тыкать.
- Нету никаких приоритетов! Приоритет у всего один: всё должно работать!
Ха-ха, ёпт. Мало ты с людьми общался.
Из
- Это чё за пиздец, почему интерфейс серым становится? Мне через 10 минут уезжать на выставку, а с программой, которую я же ещё в прошлом году у другого программиста принимал, такой пиздец - это всё вы, программисты виноваты!
- Блять, ты приоритеты расставлять умеешь? Одно дело, когда датчики нихуя не меряют и с них информация не приходит, и совсем другое, когда во время измерений всего лишь интерфейс блокируется, чтобы пользователь не мог в галочки тыкать.
- Нету никаких приоритетов! Приоритет у всего один: всё должно работать!
Objective-C - это ебучий пиздец, все кто его защищают сраные дегенераты
C++ - это ебучий пиздец, все кто его защищают сраные дегенераты
Perl - это ебучий пиздец, все кто его защищают сраные дегенераты
Delphi - это ебучий пиздец, все кто его защищают сраные дегенераты
PHP - это ебучий пиздец, все кто его защищают сраные дегенераты
... Вы находитесь здесь ...
JavaScript
... Вы находитесь здесь ...
C++ - это ебучий пиздец, все кто его защищают сраные дегенераты
Perl - это ебучий пиздец, все кто его защищают сраные дегенераты
Delphi - это ебучий пиздец, все кто его защищают сраные дегенераты
PHP - это ебучий пиздец, все кто его защищают сраные дегенераты
... Вы находитесь здесь ...
JavaScript
... Вы находитесь здесь ...
Ну похапэ и правда пиздец, говорю как быдлокодер, который на нём спагетти-код писал.
Херачить код в специальный тэг хтмл? Для чего это вообще может пригодиться, кроме вебодиннольной хоумпаги?
Херачить код в специальный тэг хтмл? Для чего это вообще может пригодиться, кроме вебодиннольной хоумпаги?
Я на PHP тоже писал. Я писал сначала на Smarty, а потом Twig нашёл. Так что я ни дня не херачил вёрстку в код. Потом уже жирные проекты как подработка были FuelPHP -> Lumen -> Laravel. Первый без ничего, на втором и третьем ReactPHP (да, мне помогали, но не суть). Причём был линтер который не давал отправить в репозиторий файлы у которых не было `declare(strict_types=1);`. Ещё раз повторюсь, я понимаю что я с профи работал, но всего того кошмара который везде пишут я и близко не видел. И вообще иногда кажется, что я на каком-то другом PHP писал, видать не зацепил версии три и четыре вот и не рефлексирую. Давно не прикасался к PHP, но и давно понял, что проблема только в людях которые дальше вебодиннольной хоумпаги писать не могут. Не зашло - не пиши. Надо писать - ищи ментора, другую команду которая что-то умеет, они помогут. А пока сам будешь писать говнокод, и никто его толком не проверяет, то ты так на месте и останешься. Хоть с PHP, хоть с Java, хоть со Scala. Ты просто обязан окружить себя профи которые намного лучше тебя.
годы идут, а срачи остаются :)
http://lurkmore.to/%D0%AF%D0%B7%D1%8B%D0%BA%D0%B8_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F
Python — идеальный язык для обучения программированию школоты, так как даже обезьяна осилит. Да что уж там обезьяна, даже 1Сник или похапэшник не облажается. Тем не менее, на нём пишут и серьёзные вещи. Огромный плюс языка — синтаксис, всячески ограничивающий говнокодера в вымещении своих влажных фантазий в файл со скриптом в необработанном виде. В результате даже ОЧЕНЬ ПЛОХО написанный код таки поддаётся синтаксическому разбору среднестатистическим программистом. Ещё одно непревзойдённое достоинство языка и компиляторов для него — феерическая скорость работы программ, что позволяет даже самому бездарному учащемуся для простейших вычислений заранее получать результат, вычисленный столбиком до окончания работы программы.
Javascript — ужас и кошмар любого вменяемого разработчика, на фоне которого PHP выглядит, мать его, Haskell-ем. Несмотря на отсутствие нормальной структурированности и откровенные проебы в базовой архитектуре, горячо любим нублом за предельно низкий даже среди ближайших конкурентов порог вхождения, а также работодателями, готовыми взять на фирму долбоёба с двухмесячным стажем, который быстро-решительно наваяет им относительно рабочую, но при этом абсолютно неподдерживаемую систему без всякой перспективы к дальнейшему развитию. О том, насколько javascript на самом деле плох, красноречиво говорит количество псевдоязыков, код которых может в него транслироваться.
http://lurkmore.to/%D0%AF%D0%B7%D1%8B%D0%BA%D0%B8_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F
Python — идеальный язык для обучения программированию школоты, так как даже обезьяна осилит. Да что уж там обезьяна, даже 1Сник или похапэшник не облажается. Тем не менее, на нём пишут и серьёзные вещи. Огромный плюс языка — синтаксис, всячески ограничивающий говнокодера в вымещении своих влажных фантазий в файл со скриптом в необработанном виде. В результате даже ОЧЕНЬ ПЛОХО написанный код таки поддаётся синтаксическому разбору среднестатистическим программистом. Ещё одно непревзойдённое достоинство языка и компиляторов для него — феерическая скорость работы программ, что позволяет даже самому бездарному учащемуся для простейших вычислений заранее получать результат, вычисленный столбиком до окончания работы программы.
Javascript — ужас и кошмар любого вменяемого разработчика, на фоне которого PHP выглядит, мать его, Haskell-ем. Несмотря на отсутствие нормальной структурированности и откровенные проебы в базовой архитектуре, горячо любим нублом за предельно низкий даже среди ближайших конкурентов порог вхождения, а также работодателями, готовыми взять на фирму долбоёба с двухмесячным стажем, который быстро-решительно наваяет им относительно рабочую, но при этом абсолютно неподдерживаемую систему без всякой перспективы к дальнейшему развитию. О том, насколько javascript на самом деле плох, красноречиво говорит количество псевдоязыков, код которых может в него транслироваться.
Чтобы написать коммент, необходимо залогиниться
Отличный комментарий!