USB, нормальная многооконность, трей, протоколы помимо HTTP(S)
Стойте. Причём здесь веб? Многооконность и трей, к счастью, не очень про веб. Веб — это про рисовать странички. Многооконность, трей и всё остальное — это про операционную систему. Должен ли это уметь веб? Возможно, но зачем? Кстати, как многооконность с треем должна работать на андроиде, допустим?
Ах да, веб же не позволяет использовать системную тему
Да даже горячо любимый Qt не позволяет без плясок с бубном использовать системную тему. Должен ли это делать веб?
Да ну ёлки, где оно кривее остальных-то?
Я года три назад перескочил из уютного Java мира с Java/Scala в node + frontend. Нормальное оно. Другое просто сильно.
Стандарты менее стандартные, но если не упарываться по всякой разработке игр на WebGL и другим крайне интересными, но не мейнстримовым вещам, то нормальное оно. И даже работает.
Берёшь Babel — и практически все проблемы с JS закрыты. Берёшь bootstrap, и не надо даже начинать думать о чем-то кроме того, в какой цвет кнопки покрасишь. Фреймворков для того, чтобы формочки и кнопки рисовать уйма. Начиная от крайне ванильного HTML/CSS/JS, заканчивая всякими Elm, ReasonML, ClojureScript, в связке с чем угодно, которые вполне себе работают.
Ну и React, раз уж столько хайпа про него. Автор про Flux упомянул. Он может быть и из времен Win3.1, но проблему-то он решает вполне неплохо. Если сравнивать, условно, Redux, который, конечно не совсем Flux, но из той же оперы, с правильным и расово-верным Qt (или что там автор предлагает?), то хм… кто из этих двоих ребят позволяет сделать replay приложения практически искоробки?
В общем, я конечно не могу сказать, что во фронтенде всё такое классное и блестящее — нужно ещё пилить и пилить. Но сегодня большинство проблем кривизны решается с помощью npm install left-pad… OH WHAI~~
JVM какой версии держать будем? Обновлять как будем? Сэндбоксом для JVM кто будет управлять? RPC как построить так, чтобы можно было получить ограничение по доменам? На стороне клиента нужен какой-то стандарт для хранения данных? Окей, будем считать с десктопом вопрос зарешаем. Тут ходовых платформ всё же всего полторы — x86 + unix/windows.
Теперь дело за малым, перенести эту референсную реализацию на ARM да под android, windows phone, ios… tizen, remix, sailfish, symbian, webOS и заставить на телевизорах работать.
Это я всё к чему? Если сделать замену вот такую: JVM -> V8, WebGL -> WebGL, API мышки/клавиатуры -> MouseEvents, RPC -> Ajax/XHR то получится, внезапно, то что сейчас есть, только оно более-менее работает почти на всех платформах старше IE9.
И ответ на это тоже один — аналогичный функционал для одной платформы на нативных компонентах требует больше времени разработки. Нативные приложения — это здорово. Но между нативное послезавтра и webkit сегодня, ответ, за редким исключением, очевиден.
MacBook 12" бывает с 1.4 GHz Core i7 и 16 Gb
В штатах стоит $2k.
Проблема с Ethernet решается переходником, а лучше док-станцией. Тогда его и заряжать одновременно можно.
Привет. Я правильно понимаю, что это всё же параллелизм на уровне процессов, и по-прежнему в кластере из четырех акторов можно добиться не более 4-х реально одновременно выполняющихся CPU-bound задач?
П.С. а почему таки не подпилили под интерфейс web workers?
Если не углубляться совсем в дебри, то на основе статистики поведения метода в runtime, виртуальная машина может его не только скомпилировать в машинный код, но и например, выкинуть какие-нибудь проверки аргументов, ветки условий, итд.
Более того, эти оптимизации занимают некоторое время, и требуют определенного способа использования приложения. Поэтому иногда для того, чтобы свежезапущенное приложение было молодцом с самого начала, в него профиль оптимизации можно загрузить. Вот так никогда не делал, но на хабре где-то не так давно была статья по этому поводу.
Не кидайте помидорами, но мне кажется, что сегодняшний JavaScript ближе к Java чем когда бы то ни было. Смотрите сами:
Кроссплатформенность. Java на кофеварке сегодня запустить не так уж и прямо (профили, вот это всё), но браузер там скорее всего есть. И с помощью нескучного тюнинга бабеля, думаю можно под этот браузер писать со всеми радостями ES7+.
Write Once Run Everywhere. Опять же за счёт бабеля (по желанию можно взять что-то другое) веб-приложение может быть собрано в какой-нибудь ES3 и запуститься на старых платформах.
Язык/Платформа. Сам по себе язык довольно простой с несколькими неочевидными нюансами, которые спустя пару недель проклятий становятся уже не настолько неочевидными. Платформа, конечно, так себе — реализации отличаются, стандартная библиотека очень маленькая, но тем не менее.
М? Чем не каноничная Java? Осталось портировать Spring, чтобы было для чего конфиги иксэмэльные писать, и готово :)
А в чем проблема? Eсли речь идет не о 8гб таблиц, то до определенного предела фронтенд вполне себе в состоянии из json получить xml.
Разумеется, если киллер-фича приложения это генерирование xlsx на любой кофеварке с браузером, то нужно крепко подумать, желательно дважды. Но если речь идёт о данных, которые уже есть в вебе и их не десятки мегабайт, то в чем проблема? Современные движки JS достаточно быстрые для этого.
Постойте, я и не говорю, что нода хороша для CPU-bound операций. Больших фишек у ноды ровно две:
асинхронный io с приятным интерфейсом для простых смертных (нет, последователи Карри, для этого не нужна специальная монада, и да, парни из мира Стандартных Изданий, для этого не нужно упражняться с тредпуллами), который внезапно показывает весьма приятную производительности без лишнего тюнинга.
javascript. Который, внезапно, не смотря на все фу-фу-фу, доступен практически любому разработчику на Java, C, C++, C#, Pascal, PHP итд. А если немного подтянуть матчать и разобраться в том как работает this и прототипное наследование (которое, вообще говоря надмножество Java-like OOP), то внезапно оказывается, что это вполне пристойный инструмент. А если копнуть еще чуть глубже, то внезапно оказывается, что JS можно декорировать типами (flow), проверять линтерами, собирать под платформы разной степени древности (babel) и использовать фичи из черновиков грядущих стандартов прямо вот сейчас (опять, привет babel). Чем, не смотря на некоторую костыльность и соберисамность, может похвастаться далеко не каждый ЯП.
Теперь про CPU-bound и тот-самый excel. Я конечно в офисных xml делах не очень рублю, но что-то мне подсказывает, что если мы собираемся массово генерировать excel- файлики, то я бы предпочёл это действо передавать системе и вызывать отдельным процессом. Потому что наверняка есть хорошая сторонняя/системная тулза, которую не стоит пытаться запихнуть ни в ноду, ни в похапэ, ни в питон.
Это не значит, что надо писать на ноде всё и вся. Но для типовых веб-серверных задач нода — прекрасный, доступный и достаточно мощный инструмент.
Мы в каких-то видимо сильно разных мирах живём, но как мне видится пласт задач вида "сходи в базу, принеси A, потом прими решение на его основе и принеси Б" — довольно широкий и охватывает если не весь веб, то довольно серьезную его часть.
Разумеется, есть еще уйма CPU-bound задач, которые на ноду ложатся мягко говоря не очень. Но это ведь не делает ноду плохим инструментом, для решения io-bound задач.
Ну и многопоточность тоже момент очень хитрый. Безусловно многопоточность в природе нужна. Но в ряде случаев от этого можно отказаться, и поиметь определенный профит от этого — выше уже был пример с nginx.
У латеха есть еще одна проблема, сформулировать её можно так: если у вас есть проблема и вы решили использовать латех, у вас уже две проблемы.
Латех сам по себе весьма неплох, и позволяет сделать с документом практически всё, что угодно, но сам по себе достаточно сложен, и с автоматизацией тоже не всё так гладко, хотя и решаемо.
У меня немного другой опыт (но на скале я уже два года активно не пишу, до этого писал активно о). Если использовать скалу, как Better Java, то ничего хорошего из этого не получается. А если активно писать в около-функциональном стиле, то выясняется две интересных подробности:
для этого надо знать слишком много о том, как работает JVM и во что превращается scala-код
стоит только сделать небольшой шаг дальше композиции функций, как тут же возникает огромное количество вопросов, на которые в "продвинутом" скала-сообществе принято отвечать примерами на хаскеле.
Что вы там на нём пишете? Куда ещё производительнее? https://habrahabr.ru/post/281879/
Да ну ёлки, где оно кривее остальных-то?
Я года три назад перескочил из уютного Java мира с Java/Scala в node + frontend. Нормальное оно. Другое просто сильно.
Стандарты менее стандартные, но если не упарываться по всякой разработке игр на WebGL и другим крайне интересными, но не мейнстримовым вещам, то нормальное оно. И даже работает.
Берёшь Babel — и практически все проблемы с JS закрыты. Берёшь bootstrap, и не надо даже начинать думать о чем-то кроме того, в какой цвет кнопки покрасишь. Фреймворков для того, чтобы формочки и кнопки рисовать уйма. Начиная от крайне ванильного HTML/CSS/JS, заканчивая всякими Elm, ReasonML, ClojureScript, в связке с чем угодно, которые вполне себе работают.
Ну и React, раз уж столько хайпа про него. Автор про Flux упомянул. Он может быть и из времен Win3.1, но проблему-то он решает вполне неплохо. Если сравнивать, условно, Redux, который, конечно не совсем Flux, но из той же оперы, с правильным и расово-верным Qt (или что там автор предлагает?), то хм… кто из этих двоих ребят позволяет сделать replay приложения практически искоробки?
В общем, я конечно не могу сказать, что во фронтенде всё такое классное и блестящее — нужно ещё пилить и пилить. Но сегодня большинство проблем кривизны решается с помощью npm install left-pad… OH WHAI~~
JVM какой версии держать будем? Обновлять как будем? Сэндбоксом для JVM кто будет управлять? RPC как построить так, чтобы можно было получить ограничение по доменам? На стороне клиента нужен какой-то стандарт для хранения данных? Окей, будем считать с десктопом вопрос зарешаем. Тут ходовых платформ всё же всего полторы — x86 + unix/windows.
Теперь дело за малым, перенести эту референсную реализацию на ARM да под android, windows phone, ios… tizen, remix, sailfish, symbian, webOS и заставить на телевизорах работать.
Это я всё к чему? Если сделать замену вот такую: JVM -> V8, WebGL -> WebGL, API мышки/клавиатуры -> MouseEvents, RPC -> Ajax/XHR то получится, внезапно, то что сейчас есть, только оно более-менее работает почти на всех платформах старше IE9.
И ответ на это тоже один — аналогичный функционал для одной платформы на нативных компонентах требует больше времени разработки. Нативные приложения — это здорово. Но между нативное послезавтра и webkit сегодня, ответ, за редким исключением, очевиден.
В штатах стоит $2k.
Проблема с Ethernet решается переходником, а лучше док-станцией. Тогда его и заряжать одновременно можно.
А чем не устраивает, допустим, Google Music? В него можно загрузить 10 000 своих треков.
Привет. Я правильно понимаю, что это всё же параллелизм на уровне процессов, и по-прежнему в кластере из четырех акторов можно добиться не более 4-х реально одновременно выполняющихся CPU-bound задач?
П.С. а почему таки не подпилили под интерфейс web workers?
Так message-based IPC в event-driven языке с managed memory и async/await искоробки, это так же просто и прямо как котят гладить.
В рантайме можно спекулятивные оптимизации на основе статистики использования, которые нельзя в compile time.
Вот тут есть довольно общий список: https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques
А вот тут пара слов про Profile: https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques
Если не углубляться совсем в дебри, то на основе статистики поведения метода в runtime, виртуальная машина может его не только скомпилировать в машинный код, но и например, выкинуть какие-нибудь проверки аргументов, ветки условий, итд.
Более того, эти оптимизации занимают некоторое время, и требуют определенного способа использования приложения. Поэтому иногда для того, чтобы свежезапущенное приложение было молодцом с самого начала, в него профиль оптимизации можно загрузить. Вот так никогда не делал, но на хабре где-то не так давно была статья по этому поводу.
Про джавовый HotSpot и другие интересные вещи, которые возможны только в рантайме, уже можно рассказывать?
Не кидайте помидорами, но мне кажется, что сегодняшний JavaScript ближе к Java чем когда бы то ни было. Смотрите сами:
М? Чем не каноничная Java? Осталось портировать Spring, чтобы было для чего конфиги иксэмэльные писать, и готово :)
А в чем проблема? Eсли речь идет не о 8гб таблиц, то до определенного предела фронтенд вполне себе в состоянии из json получить xml.
Разумеется, если киллер-фича приложения это генерирование xlsx на любой кофеварке с браузером, то нужно крепко подумать, желательно дважды. Но если речь идёт о данных, которые уже есть в вебе и их не десятки мегабайт, то в чем проблема? Современные движки JS достаточно быстрые для этого.
В файл её и отдать через sendFile
Постойте, я и не говорю, что нода хороша для CPU-bound операций. Больших фишек у ноды ровно две:
Теперь про CPU-bound и тот-самый excel. Я конечно в офисных xml делах не очень рублю, но что-то мне подсказывает, что если мы собираемся массово генерировать excel- файлики, то я бы предпочёл это действо передавать системе и вызывать отдельным процессом. Потому что наверняка есть хорошая сторонняя/системная тулза, которую не стоит пытаться запихнуть ни в ноду, ни в похапэ, ни в питон.
Это не значит, что надо писать на ноде всё и вся. Но для типовых веб-серверных задач нода — прекрасный, доступный и достаточно мощный инструмент.
Мы в каких-то видимо сильно разных мирах живём, но как мне видится пласт задач вида "сходи в базу, принеси A, потом прими решение на его основе и принеси Б" — довольно широкий и охватывает если не весь веб, то довольно серьезную его часть.
Разумеется, есть еще уйма CPU-bound задач, которые на ноду ложатся мягко говоря не очень. Но это ведь не делает ноду плохим инструментом, для решения io-bound задач.
Ну и многопоточность тоже момент очень хитрый. Безусловно многопоточность в природе нужна. Но в ряде случаев от этого можно отказаться, и поиметь определенный профит от этого — выше уже был пример с nginx.
У латеха есть еще одна проблема, сформулировать её можно так: если у вас есть проблема и вы решили использовать латех, у вас уже две проблемы.
Латех сам по себе весьма неплох, и позволяет сделать с документом практически всё, что угодно, но сам по себе достаточно сложен, и с автоматизацией тоже не всё так гладко, хотя и решаемо.
А на чём всё это написано, и не седеют ли программисты от такого количества асинхронной условной логики?
У меня немного другой опыт (но на скале я уже два года активно не пишу, до этого писал активно о). Если использовать скалу, как Better Java, то ничего хорошего из этого не получается. А если активно писать в около-функциональном стиле, то выясняется две интересных подробности: