×Закрыть

Есть ли жизнь после Java?

Недавно я получил имейл от Java разработчика, где автор писал: «Похоже, ты всё меньше программируешь на Java, а в основном занимаешься разработкой для Web». Это действительно так.

Являюсь ли я всё еще Java разработчиком после 17 лет работы с этим супер-популярным языком программирования? Да. Вот только что выложил в свободный доступ новую версию своей книги о программировании на Java для детей. Но в сегодняшнем мире использовать только один язык программирования практически невозможно — если, конечно, вы не хотите ограничить себя разработкой для сервера и некоторых мобильных платформ. Я не говорю, что такая специализация — это плохо. Серверная разработка и смартфоны — это огромное поле для самообразования и экспериментов.

Даже с точки зрения карьеры специализация в узкой области может отлично кормить вас и вашу семью. Например, я знаю экспертов по улучшению производительности Java-приложений, у которых часовая ставка в разы больше, чем у обычного сеньора. Некоторые разработчики становятся экспертами в области безопасности приложений или многопоточной обработки данных. Это позволяет им каждое утро есть омлет с трюфелями (это не продукт фабрики Рошен, а грибочки такие).

Но 95% Java разработчиков делают более или менее рутинную работу, и изучение других языков программирования, тулзов и фреймворков может украсить эту рутину, делая их более конкурентоспособными при поиске работы.

В то время как Java царит на серверной стороне, JavaScript рулит на клиенте и позволяет создавать кроссплатформенный GUI и для десктопных приложений, и для мобильников. Современные разработчики пользуются несколькими языками и фреймворками для создания Web-приложений. Если вы уже не новичок в Java, почему бы не поднять голову и присоединиться к огромному и постоянно развивающемуся сообществу Web-разработчиков?

Довольно часто джависты смотрят свысока на тех, кто пишет на JavaScript, неверно предполагая, что настоящая разработка ведется только на Java. Скажу вам по секрету: это не так. JavaScript так же близок к интернету, как язык C — к железу. Вот посмотрите на этот длинный список компиляторов, которые генерируют JavaScript из других языков.

В нашей компании мы используем язык Google Dart как способ написания программ, которые будут преобразованы в JavaScript. Dart очень похож на Java. Если интересно, посмотрите мой доклад «Dart for Java Developers», который я недавно делал в Нью-Йорке.

Помимо Dart, мы используем TypeScript в связке с Angular фреймворком, новая версия которого выйдет в конце года.

В следующем году мы планируем переключиться на программирование фронтенда с новой версией JavaScript, которая станет реализацией стандарта ECMAScript 6. Вообще-то мы уже начали, и многие Web-браузеры начали поддерживать синтаксис ECMAScript.

Все популярные среди джавистов IDE прекрасно поддерживают и Dart, и Typescript, и JavaScript. Каждый браузер включает тулзы для удобной отладки. Среда разработки JavaScript имеет все тулзы, к которым привыкли джависты: репозитории кода, поддержка зависимостей, билд-тулы, фреймворки для тестирования, и т.д.

Будут ли Dart и TypeScript популярны через 3-5 лет? Я не знаю. Сегодня они помогают нам быть более продуктивными в разработке приложений, которые должны идти в продакшн в этом году. Кстати, первое приложение с фронтендом на Dart и Angular уже вышло в продакшн. Если в следующем году появятся более интересные и полезные языки, мы пересядем на них. Наша профессия предполагает постоянное обучение, не так ли?

Можно ли угадать, что будет следующим популярным языком или фреймворком? А надо ли? Если вы станете программистом-полиглотом, легко осваивающим новые инструменты, ваша карьера (да и заработки) будет идти вверх, а жизнь будет интереснее.

  • Популярное

65 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
фрейморком
--- опечатка

по Фрейду.

Javascript самый плохой из популярных языков, и популярный только благодаря своей монополии в веб-браузерах. Это самая большая проблема в отрасли на сегодняшний день. Javascript must die.

Хорошо хоть, что есть TypeScript.

по-моему уже есть больше сотни языков, которые транспилируются в javascript

самая большоая проблема отрасли — это малолетние сениоры, которые могу безапеляционно утвержать, что язык X — говно, язык Y — охуенный, толком не разбираясь ни в том, ни в другом, и даже не уточняя о каком кейсе они ведут речь.

Согласен, популярность технологии часто играет негативную роль в развитии IT, особенно языков программирования. Ввиду увеличения количества программистов, средний уровень навыков падает и выходит, что популярнее языки(технологии) становятся те, которые проще или имеют более низкий порог вхождения. Также увеличение количества направлений и технологий приводит к более узкой специализации, что в итоге негативно сказывается на общем уровне понимания. Грубо говоря, программист, который специализируется на front-end, уверенно владея javascript, не будет считать его плохим, потому что давно не писал на других языках или вообще на них не писал.

А ещё бо́льшая проблема — «пожилые» типа сеньоры, которые с умным видом вещают что-то в стиле «у каждого своя правда» и отказываются признавать любой чужой опыт, который противоречит их «философии».

подрезюмируем, проблема отрасли — сеньйоры всех возрастов.

в JavaScript есть свои проблемы и плюсы, при определенных знаниях проблемы можно легко избежать. В JS наверное самое большая экосистема , а при выборе языка это тоже важно. Кроме того на каждую проблемы уже есть решение: типы — TypeScript/Flow, не нравиться прототипное насследование — Typescript/CoffeeScript, хочешь больше функциональщины — PureScript. К тому же если вы вспомните историю, то Java уже пытались прилепить в браузеры и что с этого вышло? Ну и как же не упомянуть ES6 , если вы посмотрити на спецификацию, то поймете что язык ждет очень прекрасное будущее и он никак не must die.

Со всем согласен, кроме «не must die». Под «must die» я полагаю не совсем уж must die, а просто убрать монополию языка, пусть кто хочет тот и пишет, а если не хочет, то пишет на другом не зависящем от javascript языке. А Java коряво пытались — процесс создания интерфейса там сложнее по сравнению с HTML и постоянно обновление, плагин и т.д.

не зависящем от javascript языке
Так или иначе монополия сохраняется и все вынуждены подстраиваться под js (в том числе и разработчики этих компиляторов в js, совместимость с библиотеками).

Так-так, подождите, а как же, например, виртуальная машина джавы, или там разработчики компилятора не заботятся о совместимости и не вынуждены подстраиваться под jvm? У джавы тоже монополия? или groovy, scala etc, которые компилируются в байткод — не отдельные языки?

Предлагаю смотреть на джаваскрипт как на язык виртуальной машины, на котором еще и удобно программировать нативно :-) на байткоде jvm не программируют, вроде?

Ну или признайте, что просто не любите javascript :-)

P.S. еще раз рекомендую вот этот доклад. Он забавый, интересный + повествует о многих возможностях javascript www.destroyallsoftware.com/...h-and-death-of-javascript

байткод под jvm, MSIL, CTS, CLR специально проектировался для данной цели, чтоб другие языки под них подстраивались и это все можно было выполнять на разных платформах. А javascript изначально делался для того, чтобы работать с DOM и что-то там сделать на страничке. Попробуйте написать транслятор из javascript в скажем C#(не уверен, но думаю это невозможно и если да, то просто так jquery и все остальные либы нельзя подключить, то есть промежуточный язык javascript весьма плохая затея). А сейчас на нем пишут 3d игры и всего чего не лень и браузеры все это должны поддерживать, причем все одинаково должно работать. Это же касается CSS и HTML(там просто эти проблемы не так заметны). Я не люблю писать на Javascript, если надо сделать, что-то более чем сценарий для отдельной странички. Очень тяжело, без тестов практически невозможно, ни на что нельзя надеятся. this может быть чем угодно, переменные можно передать любые, поменяешь или удалишь функцию — никто ничего не скажет, но потом только узнаешь, что где-то что-то поламалось. Естественно, в такой ситуации IDE ничего не раскажет и не подскажет. Доклад смешной, но как по мне это сатира на текущее положение вещей.

Зачем писать транслятор из javascript в C#? При чем тут jquery? :-) DOM API можно реализовать где угодно и запускать jquery. Браузеры ж не на JS написаны.

По поводу того, что придуман джс изначально не для всего этого — так и Интернет изначально для военных целей создавался. Вот Java Applets — то, что как раз придумывалось, чтобы писать что-то серьезное, но почему-то не очень сработало. А вот у javascriptа, по-моему, получается лучше. И то, что как раз пишут 3d игры, и браузеры поддерживают — доказывает это. Ведь браузер можно рассматривать как vm, которая есть у каждого на компе, в отличие от jvm. А js — как родной язык этой vm.

Ну, посмотрим, умрет он или нет :-) спасибо за дискуссию

ся. Вот Java Applets — то, что как раз придумывалось, чтобы писать что-то серьезное, но почему-то не очень сработало.
А для клиент банков и там где нужно проверка сертификата, почему-то сработало и очень хорошо.
this может быть чем угодно, переменные можно передать любые, поменяешь или удалишь функцию — никто ничего не скажет, но потом только узнаешь, что где-то что-то поламалось.
То есть в особенностях языка вы не пытались разобраться, а просто сразу разобиделись, что он работает не так как java?

Это прекрасное будущее окончится после выхода вот этого blog.mozilla.org/...e/2015/06/17/webassembly

хуже ,чем PHP?)

Довольно часто джависты смотрят свысока на тех, кто пишет на JavaScript, неверно предполагая, что настоящая разработка ведется только на Java.
Тут дело не в джависты или нет. Просто есть люди которые считают что фронтэнд — это не круто. Причин такому отношени можно на целую статью набрать.
Наша профессия предполагает постоянное обучение
Как бы да. В ИТ, если ты не развиваешься (и в глубь, и в ширь), то ты деградируешь.
Но совсем не обязательно развиваться в сторону фулл-стек разработки, хотя такой вектор наиболее интересен многим (но далеко не всем, особенно в верхнем зарплатном сегменте) работодателям. Развиваться можно в сторону БД (реляционных и НоСКЛ), можно в сторону организации бизнесс-логики, можно в сторону распределенности и тд. Точно так же не обязательно становиться полиглотом. Ознакомится с другими языками таки нужно, но совсем не обязательно их изучать.

Причем тут

Просто есть люди которые считают что фронтэнд — это не круто.
Просто кому-то нравитьсяч гуем возиться, а кого-то от этого выворачивает.

Как можно сравнивать JavaScript и Java? Java компилируется, JavaScript интерпретируется. Java статически типизирован, JavaScript динамически.

Полагаю, было сравнение не языков программирования, как таковых, а более как сферу применения:
бэкэнд — Java
фронтенд — JS

JS действительно в последнее время начало все более уверенно использоваться на стороне клиента, вытесняя не только Java, но и Flash, PHP,..

Думаю это очень интересное и перспективное направление как для развития, так и для заработка.
Особенно рекомендую обратить внимание молодым разработчикам, которые еще определяются с технологией.

пс: сам также в последнее время все более начал интересоваться и даже немного пользоваться JS :)

Согласен, что у JS своя ниша, но не согласен, что он удобнее чем Java для меня как программиста.
Попробуйте взять два файла — один на Java, другой на JS, одинаковое количество строк. И найти ошибку в каждом из них (с секундомером), а потом сравнить время.

За то время, пока откроется эклипс, можно успеть прогнать все regression tests, написанные на js, найти ошибку, пофиксить ее и сходить попить кофе

Если у вас медленный компьютер и долго запускаются приложения, могу вам посоветовать быстрый и многофункциональный редактор Notepad++.
Подсветка синтаксиса, более 50 языков, автозавершение и много других интересных фитч.

notepad-plus-plus.org

Тулы которыми пользуются люди имеют влияние на их стиль разработки/кодирования.
В случае с джаваскриптом, основной тул — это простой (или продвинутый) текстовый редактор, соответственно люди (адекватные люди) пишут код который удобно читать/изменять в таком редакторе.
В случае с джавой, основной тул — это крутая ИДЕ (ну или какой-то эклипс :) ), соответственно с кодом будет удобно работать в ИДЕ, а не в ВИМе или типа того. Есть люди кторые пишут на джаве в текстовых редакторах, но этот код очень сильно отличается по стилю (и даже фреймворкам) от мейнстрима.

Мне кажется начинается очереной холивар «что круче: Java или JS», хотя я считаю — это совсем РАЗНЫЕ технологии и их предназначение — решение РАЗНЫХ задач.

Естественно, что и я (как молодой разработчик) вовсю использую весь «сахар» ИДЕ, но и иногда и блокнотом не брезгую — код же одинаков что в ИДЕ что в текстовом редакторе (разве что подсветка разных цветов может быть :-) ).
Ту же JS пишут также, в том же WebStorm’е, например..

Поэтому, не вижу проблем в вопросе «где/чем писать». В плане «правильности» форматирования ИДЕ справляется не хуже. Ну, а «кривые руки» никто не отменял. И тут уже не важно «в блокноте» или «в ИДЕ» был написан «код» )))

Тут больше скорее всего дело привычки (где писать) и соблюдения Соглашений конкретного языка (как писать), но это уже совсем другая тема..

Не только подсветка. IntelliSense например. Очень помогает. Или перейти на объявление функции из контекстного меню. Быстрее и приятнее, чем пользоваться текстовым поиском.

Оно кажется только не важным, потому что и так и иначе задача решается. Но это всё равно, пока делаешь код не за деньги. А когда за деньги — производительность играет роль.

Фигась-фигась и в прод?
Хотя сорри — прочитал про тесты и т.п. ;)

PHP на стороне клиента, rlly ?

Ну типа в классическом mvc стиле с сервер-сайд рендерингом на php, а js для рюшечек, менюшек и т.п.

Можно конкретный пример как js вытесняет php? Если имеется в виду node — можно список нормальных фремверков типа symfony2 на node?

Ну кто-то же назвал Javascript именно текущим названием... вот и сравнивают.

Где то эту статью читал ранее...
Может на блоге Якова...

А еще можно писать серверные приложения на JavaScript. Callback hell`а уже нет :-) В результате можно совсем перестать писать на Java ;-)

Та ну, у поєднанні з JS така порада більше із категорії шкідливих.

Ага, напиши крупное ентерпрайз приложение на js с командой в 15 человек и потом попробуй его поддерживать в течении пары лет.

Напишу :-) да кто мне позволит? :-)

сейчас такое пишем в моей компании, и поддерживаем вот уже несколько лет, и ниче не отвалилось

Молодцы! Было бы круто услышать о том что и как вы пишете и саппортите.

Node Meetup будет в Киеве, 24 октября. Там как раз про такое расскажут.

Еще только там его не хватало. Хватит того что на клиентскую сторону въелся как стандарт.

Хорошая статья, быть full-stack это логично и правильно. А изучить js после сотен тысяч джава фреймворков это легкая задача.

в js їх же теж сотні тисяч

Только они малюсенькие и их исходники за редким исключением можно полностью перечитать и все сразу понять. А попробуй прочитать spring или hibernate!

ты ext js видел? он ни фига не малюсенький

за редким исключением

Скорее они за редким исключением малюсенькие

Есть одна проблемка — хорошим full-stack при этом быть крайне сложно. Если вы легко сгенерируете фронтэнд со всеми совместимостями с разнообразными браузерами, скорее всего у вас «поплывут» нетривиальные запросы к БД, или, от незнания, вы будете 10 строчками делать операцию, выполнимую одной функцией сервер-сайд-языка.

Или, даже зная эти функции, вы не будете на сравнимом уровне по вашему сервер-сайд фреймворку в плане качества разработки. Я плавал и знаю, более того, видел наглядные примеры, только для случая MySQL/PHP/Javascript + популярные фреймворки. Уметь fullstack, конечно, неплохо, но «быть специалистом во всем» — это быть дилетантом.

Странно — мне вот почему-то попадались в команде вполне годные фул-стек разработчики на LAMP+js. Для этого должны быть два условия: человек в принципе старается разбираться в языках/технологиях которые использует и ему нравится делать как фронт так и бек часть.
При этом можно не уходить в дебри скл-оптимизации например и не уметь писать на сях модули для пхп.

Виктор, я сам немножко такой. Но как только от меня, как «фулл-стека» хотят раскапывания кроссбраузерного ада (да, чтобы в ИЕ, ФФ, Хроме и Сафари совпадало все до пиксела, при этом блоки генерируются динамически, и несмотря на кроссбраузерный jQuery и прочие плюшки рендеринг блоков отличается на +/- 3 пикселя, за что просто жестко трахают мозг) — мне как-то перестает хотеться быть «фронтендщиком». Особенно когда сверху ещё накидывают чисто верстальщицкие задачи (ага, опять с кроссбраузерным адом), и приговаривают «ты теперь у нас и по фронт-энду, значит должен уметь всё, это твоя работа» — мне в такой ситуации хочется откреститься и уйти в тот самый бэк-энд, который я и знаю чуть лучше, и который «друг от друга» отличается в худшем случае только версиями языков, серверов и клиентов баз данных (ну и окружением, единым в пределах сервера, слава богу, для любых клиентов «снаружи»).

Когда коллеги-руководство жестко имеют мозг коллегам за каждый кривоватый рендеринг на экзотическом мобильном клиенте (а фронт-энд делается на вполне грамотных кроссбраузерных библиотеках, т.е. изначально костылей нет) — просто нет желания уходить в дебри фронт-энда. Я это оставлю людям с более крепкой психикой.

Фронтенд — когда копро уже не вставляет.

Кстати, а есть какие-то статьи на тему полезности фулстека? А то мне лично не очевидно, почему это логично и правильно.

На мой взгляд, полезности две (а статей не знаю):
1) можно на вакансии фулстеков подаваться
2) фрилансить в одиночку можно более успешно. Еще успешней, если быть в дополнение дизайнером — но это как-то совсем маловероятно :-)

А кроме этого ничего особо полезного.

Ну я имел ввиду полезность фулстек-разработчиков для самого производства.

На мой взгляд, всё просто: вместо 2ух человек нанимают 1ого. А так как он знает и то, и другое одинаково хорошо — он теоретически эффективней, чем двое, которым еще и общаться между собой нужно. Например, если нужна какая-то фича — ее дают человеку и он всё делает. А если фронтенд и бекенд отдельно, то нужно занимать 2ух человек на одну фичу и тратить время на коммуникации между ними пока они не достигнут консенсуса.

Подписаться на комментарии