Заранее прошу прощения за некоторые обороты в переводе. Буду рад услышать здравую критику и поправки, лучше в пм. Спасибо. – пер.
Стартапы имеют много общего с JavaScript'ом. Когда вы только начинаете, вам нужно быть динамичными. Вы должны быть гибкими. Вы должны иметь возможность мгновенно выпустить прототип, который просто работает, и вам нужно уметь быстро и дешево менять его без перекомпиляции вашего кода. JavaScript появился когда война между браузерами только начиналась, и он раздавил Java и Flash по тем же причинам, по которым стартапы рушат рынки и вытесняют признанных игроков: быстрота и гибкость.
Сегодня JavaScript уже не стартап, и не только стартапы его используют. Компании всех размеров и уровней зрелости делают приложения для браузера, и JavaScript — это язык, который они используют для этого. Претензии, которые были однажды предъявлены таким языкам, как C/C++ и Java, сейчас предъявляются JavaScript'у, и эти претензии относятся к ограничениям языка: производительности и поддерживаемости.
Последнее поколение JavaScript движков достигло невероятных высот производительности, но этого все еще недостаточно. Посмотрите на такие сайты, как YouTube и Hulu, или игровые платформы Facebook'а или EA. Когда нужно сделать мультимедийное приложение, компании все еще обращаются к производительности Flash. Провидение Стива Джобса могло предсказать судьбу, которая в итоге постигнет Flash, но нам еще приходится работать с ним, пока JavaScript не дотягивает по производительности.
Как только объем вашего кода достигает сотни тысяч строк, и он весь написан на таком динамичном языке, как JavaScript, скорость разработки начинает страдать. Если вы делаете изменения где-то в одной части кода, нет никакой возможности узнать, что это не приведет к багам где-то еще, не запуская приложение. Тестирование может только усугубить ситуацию – привести к большому количеству непредвиденных расходов, сделанных заранее. Результат — больше багов в приложении либо же более длинные циклы разработки.
Кто-то должен что-то сделать с этими ограничениями, чтобы компании могли вводить новшества и делать удивительные приложения для веба. Кто же собирается сделать это и как?
Prezi, LogMeIn и Ustream организовали MLOC.js, конференцию, сфокусированную на том, как улучшить JavaScript. Инженеры из Google, Facebook, Mozilla, Groupon, и других компаний, работающих над серьезными техническими задачами собрались на три дня в Будапеште для обсуждения как они справляются с ограничениями JavaScript. Их работа даст уверенность, что JavaScript не единственная жизнеспособная платформа в будущем, но первая, которая изменит наше представление о том, как писать приложения в вебе.
Вот мое мнение: JavaScript пойман в железный треугольник им же и созданный. Мы все привыкли к гибкости и свободе, которую он дает, и мы не хотим от нее отказываться. В то же время, мы хотим, чтобы он был молниеносным, и оказывается, что при достижении миллиона строк кода, поддержка столь гибкого языка становится проблемой. Все три области — гибкость, производительность и поддерживаемость — переплетаются. Когда вы достигаете успехов в одной области, одна из двух других, или обе сразу, страдают.
Это мне говорит о том, что нет одной серебряной пули, которая решит эти проблемы, но может быть множество, которое решит. JavaScript — это динамический язык, который превосходен в склеивании веба, и это неизменно.
Бизнес-логика должна работать, и должна работать корректно. Статический анализ в таких системах, как Dart или TypeScript, важен, для гарантии, что наиболее чувствительные компоненты нашего приложения работают – и продолжат работать, когда наши приложения вырастут и эволюционируют. Нам нужно больше таких инструментов для статического анализа. Тем не менее, если посмотреть на рынок браузеров, непохоже, что мы увидим широкое распространение нативной поддержки этих технологий в ближайшее время.
Оказывается, что нативная поддержка для новых языков не всегда обязательна. Alon Zakai из компании Mozilla говорил об ASM.js, подмножестве JavaScript'а, который выполняется очень быстро на современных браузерах без модификации. Когда имеет значение скорость, нам стоит писать на ASM.js. Или, еще лучше, мы можем писать наш код на C и иметь компилятор, генерирующий ASM.js для нас. Если не говорить о производительности, мы можем применить эту технику к другим языкам и в других вариантах использования. Разработчики почти сделали это, и все их усилия перечислены на atl.js.
Один из лучших способов сделать ваш код более поддерживаемым – это писать меньше кода. Библиотеки вроде bacon.js или язык Elm кратко выражают сложные зависимости данных в вашем приложении и выгружают работу по сохранению актуальности данных в библиотеку. Результат – меньше кода для поддержки и более высокое качество приложений.
JavaScript никуда не уходит, но подвергается трансформации. Разработчики создают вариации языка и впечатляющие библиотеки для лучшей обработки специфических вариантов использования, включая производительность. Вдобавок, есть прогресс и в создании инструментария и статическом анализе. Все эти тренды влияют на то, как мы пишем приложения для веба. Конференция MLOC.js многое прояснила.
Для больших игроков, тех, кто использует JavaScript каждый день, только один вопрос остается открытым: что вы сделаете для того, чтобы JavaScript стал наиболее гибким, производительным и масштабируемым языком, который мы когда-либо знали?
Стартапы имеют много общего с JavaScript'ом. Когда вы только начинаете, вам нужно быть динамичными. Вы должны быть гибкими. Вы должны иметь возможность мгновенно выпустить прототип, который просто работает, и вам нужно уметь быстро и дешево менять его без перекомпиляции вашего кода. JavaScript появился когда война между браузерами только начиналась, и он раздавил Java и Flash по тем же причинам, по которым стартапы рушат рынки и вытесняют признанных игроков: быстрота и гибкость.
Сегодня JavaScript уже не стартап, и не только стартапы его используют. Компании всех размеров и уровней зрелости делают приложения для браузера, и JavaScript — это язык, который они используют для этого. Претензии, которые были однажды предъявлены таким языкам, как C/C++ и Java, сейчас предъявляются JavaScript'у, и эти претензии относятся к ограничениям языка: производительности и поддерживаемости.
Последнее поколение JavaScript движков достигло невероятных высот производительности, но этого все еще недостаточно. Посмотрите на такие сайты, как YouTube и Hulu, или игровые платформы Facebook'а или EA. Когда нужно сделать мультимедийное приложение, компании все еще обращаются к производительности Flash. Провидение Стива Джобса могло предсказать судьбу, которая в итоге постигнет Flash, но нам еще приходится работать с ним, пока JavaScript не дотягивает по производительности.
Как только объем вашего кода достигает сотни тысяч строк, и он весь написан на таком динамичном языке, как JavaScript, скорость разработки начинает страдать. Если вы делаете изменения где-то в одной части кода, нет никакой возможности узнать, что это не приведет к багам где-то еще, не запуская приложение. Тестирование может только усугубить ситуацию – привести к большому количеству непредвиденных расходов, сделанных заранее. Результат — больше багов в приложении либо же более длинные циклы разработки.
Кто-то должен что-то сделать с этими ограничениями, чтобы компании могли вводить новшества и делать удивительные приложения для веба. Кто же собирается сделать это и как?
Prezi, LogMeIn и Ustream организовали MLOC.js, конференцию, сфокусированную на том, как улучшить JavaScript. Инженеры из Google, Facebook, Mozilla, Groupon, и других компаний, работающих над серьезными техническими задачами собрались на три дня в Будапеште для обсуждения как они справляются с ограничениями JavaScript. Их работа даст уверенность, что JavaScript не единственная жизнеспособная платформа в будущем, но первая, которая изменит наше представление о том, как писать приложения в вебе.
Вот мое мнение: JavaScript пойман в железный треугольник им же и созданный. Мы все привыкли к гибкости и свободе, которую он дает, и мы не хотим от нее отказываться. В то же время, мы хотим, чтобы он был молниеносным, и оказывается, что при достижении миллиона строк кода, поддержка столь гибкого языка становится проблемой. Все три области — гибкость, производительность и поддерживаемость — переплетаются. Когда вы достигаете успехов в одной области, одна из двух других, или обе сразу, страдают.
Это мне говорит о том, что нет одной серебряной пули, которая решит эти проблемы, но может быть множество, которое решит. JavaScript — это динамический язык, который превосходен в склеивании веба, и это неизменно.
Бизнес-логика должна работать, и должна работать корректно. Статический анализ в таких системах, как Dart или TypeScript, важен, для гарантии, что наиболее чувствительные компоненты нашего приложения работают – и продолжат работать, когда наши приложения вырастут и эволюционируют. Нам нужно больше таких инструментов для статического анализа. Тем не менее, если посмотреть на рынок браузеров, непохоже, что мы увидим широкое распространение нативной поддержки этих технологий в ближайшее время.
Оказывается, что нативная поддержка для новых языков не всегда обязательна. Alon Zakai из компании Mozilla говорил об ASM.js, подмножестве JavaScript'а, который выполняется очень быстро на современных браузерах без модификации. Когда имеет значение скорость, нам стоит писать на ASM.js. Или, еще лучше, мы можем писать наш код на C и иметь компилятор, генерирующий ASM.js для нас. Если не говорить о производительности, мы можем применить эту технику к другим языкам и в других вариантах использования. Разработчики почти сделали это, и все их усилия перечислены на atl.js.
Один из лучших способов сделать ваш код более поддерживаемым – это писать меньше кода. Библиотеки вроде bacon.js или язык Elm кратко выражают сложные зависимости данных в вашем приложении и выгружают работу по сохранению актуальности данных в библиотеку. Результат – меньше кода для поддержки и более высокое качество приложений.
JavaScript никуда не уходит, но подвергается трансформации. Разработчики создают вариации языка и впечатляющие библиотеки для лучшей обработки специфических вариантов использования, включая производительность. Вдобавок, есть прогресс и в создании инструментария и статическом анализе. Все эти тренды влияют на то, как мы пишем приложения для веба. Конференция MLOC.js многое прояснила.
Для больших игроков, тех, кто использует JavaScript каждый день, только один вопрос остается открытым: что вы сделаете для того, чтобы JavaScript стал наиболее гибким, производительным и масштабируемым языком, который мы когда-либо знали?
