Чому Java не використовується для розробки сучасних веб-додатків? [зачинено]

Як професійний програміст на Java, я намагався зрозуміти - чому ненависть до Java для сучасних веб-додатків?

Я помітив тенденцію, що серед сучасних веб-стартапів сучасний порівняно невеликий відсоток з них використовує Java (порівняно із загальною популярністю Java). Коли я запитав кілька про це, я зазвичай отримував відповідь на кшталт "Я ненавиджу Java з пристрастю". Але, схоже, ніхто не може дати остаточну відповідь.

Я також чув, що ця сама спільнота запуску веб-сайтів негативно ставиться до розробників Java - більш-менш натякаючи на те, що вони повільні, не творчі, старі.

Як результат, я витратив час на роботу, щоб забрати Ruby / Rails, в основному, щоб дізнатися, чого мені не вистачає. Але я не можу не думати собі: "Я міг би зробити це набагато швидше, якби використовував Java", в першу чергу через мій рівень відносного досвіду.

Але також тому, що я не бачив у Java нічого критичного, що "не вистачає", що заважало б мені створити ту саму програму.

Що приводить мене до моїх питань :

Чому Java не використовується в сучасних веб-додатках?

• Це слабкість мови?

• Це несправедливий стереотип Java, оскільки він існує так довго (він був несправедливо пов'язаний із його старими технологіями і не отримує визнання за свої "сучасні" можливості)?

• Чи занадто сильний стереотип розробників Java? (Java просто більше не "крута")

• Чи справді програми, написані іншими мовами, швидше збирати, простіше в обслуговуванні та чи ефективніші вони?

• Чи Java використовується лише великими компаніями, які занадто повільно адаптуються до нової мови?

Сучасним стартапам потрібно якомога швидше вийти на ринок. Їм не потрібно витрачати близько півроку, щоб випустити веб-додаток Java.

Наприклад, Twitter був побудований за допомогою Rails / Ruby, але як тільки він не змінився, вони перейшли до спільного проекту.

Не кажучи вже про те, що процес розробки не є продуктивним: код -> компілювати -> розгортати, поки він знаходиться в таких структурах, як (Rails / Django / Grails): запустити тестовий сервер -> код -> змінити речі і подивитися, що відбувається.

Хороша новина полягає в тому, що JRebel дозволяє моментально бачити зміни коду.

На мій досвід, Java для веб-додатків є надмірним для невеликих додатків. Наприклад, простий блог з однією таблицею бази даних, що містить записи в блозі, можна зробити щось набагато простіше.

Зазвичай я бачив, що Java робить набагато краще в набагато більших веб-додатках (думають, банки та страхові компанії), які спілкуються з низкою інших систем (таких як бек-енд-мейнфрейм та бази даних та фонові системи пакетної обробки пакетних веб-служб ... все в одній програмі).

З того, що я бачив, архітектура веб-програми JavaEE зазвичай більше, ніж потрібно для невеликих / простих веб-додатків.

Я програмував веб-додатки java протягом 10 років, перш ніж я перейшов на python, 4+ років тому. Я відчуваю, що я набагато продуктивніше використовую python і можу набагато більше зробити за коротший проміжок часу, і якщо чесно, я набагато щасливіший, коли розвиваюся в python. Ось декілька причин, чому я вважаю, що пітон краще, ніж Java, виходячи з мого особистого досвіду, ваш пробіг може бути дуже.

Веб-рамки:

Коли я вперше почав програмувати веб-додатки на Java, Struts просто вийшов, і це було не чудово, але це було найкраще з наявних речей. Я створив купу додатків з підкосами та ще декілька в інших структурах. Щоразу, коли виходила нова рамка (Гобелен, Хвіртка, GWT, смуга, грааль, AppFuse, Play, RichFaces, Весна тощо), я б спробував це і побачив, чи було це краще, а в більшості разів це було лише трохи краще , а іноді і зовсім не краще. Я мушу сказати, що ігровий каркас - це крок у правильному напрямку.

Батареї не входять:

Однією з найбільш дратівливих частин Java було те, що більшість бібліотек, якими ви користуєтесь, не були включені до самої Java, вам довелося включити тону сторонніх файлів з таких місць, як apache commons. Якщо ви використовуєте щось подібне до сплячки з будь-якою іншою великою бібліотекою, ви опиняєтесь у пеклі залежностей від Jar, де в сплячому режимі потрібна одна версія баночки, а ще щось - інша версія. Якщо ви завантажуєте файли jar у неправильному порядку, вам не пощастить. Вам потрібно залежати від таких інструментів, як Maven та Ivy, щоб керувати своїми залежностями, і це просто привносить більше залежностей у ваш проект, що призводить до того, що проекти будуть величезними. У мене було кілька файлів війни 100 Мб + файли війни для найпростіших веб-додатків.

Занадто багато варіантів:

Чомусь, мабуть, існує занадто багато різних способів зробити те саме на Java. За версією wikipedia ( http://en.wikipedia.org/wiki/Comppare_of_web_application_frameworks#Java ) існує понад 38 різних веб-рамок для Java та 23 різних ORM ( http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software# Java ), просто назвати пару прикладів. Якщо ви подивитесь на інші мови, їх кількість є більш розумною. Деякі люди вважають, що мати багато варіантів - це добре, але це не призводить до багато витрачених зусиль у спільноті розробників, усі винаходять одне і те саме колесо, і якщо ви новачок для мови, якою володієте занадто багато варіантів для вибору.

Сервери додатків:

Веб-додатки Java справді важкі та потребують великих ресурсів для роботи. Вони особливо голодні пам’яті. Як і будь-яке програмне забезпечення, вони можуть бути налаштовані на зменшення слідів ресурсів, але порівняно з іншими мовами їх жахливе налаштування є жахливим. У своєму минулому я використовував weblogic, веб-сферу, Jboss, tomcat та jetty. Перші три я використовував лише тоді, коли мене змусили використовувати EJB, але навіть якщо ви не використовуєте EJB, вони були великими серверами додатків, а іноді важко налаштувати та запустити правильно. Tomcat і Jetty набагато кращі та простіші в налаштуванні, але все ще є ресурсами.

Хостинг додатків:

Якщо ви не працюєте з власним сервером, важко знайти спільний хостинг для ваших додатків Java за розумною ціною. Основна причина полягає в тому, що додатки java потребують набагато більше пам’яті порівняно з іншими мовами, тому не має сенсу для провайдера спільного хостингу витрачати свою цінну оперативну пам’ять на веб-сайті java, коли вони можуть запускати 5 php-сайтів в тому ж місці. Це означає, що менше постачальників послуг, які пропонують java хостинг, що, в свою чергу, означає більші витрати на запуск вашого веб-сайту.

Час розробки:

Коли я розвивався в java, я виявив себе набагато повільніше, ніж те, що я можу робити в python. Мені потрібно було б внести зміни, компілювати, перерозподілити, а потім протестувати, і це уповільнює ітераційний процес. Я знаю, що є способи зробити це швидше, але навіть в кращому випадку я відчував себе набагато повільніше, ніж те, що я можу зробити в python.

Існує також набагато менше кодового коду, щоб зробити те ж саме в python, тому я витрачаю менше часу на розробку коду.

Ява просто відчуває багато інженерів, багато API та інтерфейсів - це лише спосіб ускладнення того, що ви хочете зробити. І всі, і їхній брат вважають, що вони архітектори Java, і це призводить до великих складних систем, які важко використовувати та розвивати.

IDE:

Коли я розвивався в Java, я відчув, що я приєднався до IDE, я втратив його. IntelliJ - найкращий IDE на ринку, і він важко перейшов на python, оскільки для python не було нічого подібного. Тож замість IDE я просто використав textmate, який є просто звичайним текстовим редактором. Спочатку було важко, але оскільки це був лише текстовий редактор, це було дійсно швидким та чуйним додатком. Я міг би відкрити весь свій проект за кілька секунд, тоді як коли я хочу відкрити проект в IDE, це може зайняти хвилину і більше, з машиною з тоною оперативної пам’яті. Виробники IntelliJ вийшли з редактором python під назвою pycharm, я купив його, коли він вперше вийшов, і це чудово. Але я зрозумів, що IDE для python мені не потрібен, я добре в редакторі тексту. Коли я повертаюся до роботи над веб-додатками Java, які мені доводиться робити час від часу, я намагаюся використовувати текстовий редактор, але я ще не зовсім це освоїв. Мені особисто потрібен IDE для Java більше, тому що якщо я зіпсую щось, потрібно більше часу, щоб перекомпілювати та перерозподілити, що сповільнює мене.

ORM:

Коли я вперше почав використовувати Hibernate як ORM, я подумав, що це здорово, у нього були проблеми, і це було не ідеально, але було краще, ніж я робив раніше. Я був задоволений цим, поки я не зробив заявку з ORM Джанго на проект python, і це відкрило мої очі, тобто ОРМ повинен працювати. Після цього проекту я повернувся до сплячого режиму, і я просто відчув розчарування та прагнув повернутися до ORM Джанго. Ще один великий пітон ORM - це sqlalchemy, яка схожа на ORM Django, але трохи інша. У мене обмежений досвід роботи з ORM ROR, але, як я пам’ятаю, це було також непогано.

Шаблони:

Системи веб-шаблонів на Java не такі гарні, і я думаю, що я спробував їх усі (плитки, фрейма, швидкість тощо). Більшість із них пропонують лише основні функціональні можливості і дуже важко працювати. Що стосується Python, мої два улюблені - це шаблони Django та Jinja2, у них є все, що мені могло знадобитися в шаблоні, і вони дуже прості у використанні.

Start Ups хочуть блискучого. Що б там не було блискучим: RoR, Groovy, Grails, OOP w / PHP, Foobar, Wibble, Narf тощо.

Підприємство бажає стабільної, надійної та масштабованої: Java та .NET підходять до цього рахунку (якщо виконано правильно).

Поточний концерт: Фінансові послуги. Платформа: ColdFusion (по суті, бібліотека тегів Java) та Java.

Попередні концерти:

1. Послуги з тестування освіти - ColdFusion
2. Страхування високих ризиків - ColdFusion та Java
3. 401k - ColdFusion та Java
4. Подорожі - Java з внутрішніми програмами ColdFusion
5. Цінні папери - ColdFusion (версія до Java)

Це все сайти з високим рівнем безпеки, які мають високу безпеку. Ніхто з жодної з цих компаній ніколи не розглядав PHP, деякі дивилися на RoR і бачили занадто багато проблем. У компанії 401k була дочірня компанія, яка запускала .NET-додаток з компетентними розробниками, додаток щодня виходив з ладу. Нарешті вони перетворили його на Java та здобули стабільність.

Єдині люди, які дивляться на Яву, - це ті, хто не має або мало фактичного досвіду роботи з цим, або він був пов'язаний з поганою реалізацією, і тепер вони сором'язливі. Вони бачать блискучу і фігуру, якщо всі круті діти користуються цим, чому б не я?

Доповнення до відповіді FrustratedWithFormsDesigner : Оскільки я думаю, що ваше питання більше спрямоване на менші сайти, є важливий аспект, який потрібно розглянути багатьом людям: Хостинг є повсюдним для PHP, але складніше для сайтів Java або ASP. Однак це не є дефектом цих мов.

Java абсолютно буде використовуватися для нового покоління веб - додатків. Особливо після того, як ви потрапите на трохи більший / складніший / масштабований кінець спектру веб-додатків.

Якщо вас цікавлять сучасні, продуктивні інструменти та рамки, подивіться на:

• Ігрові рамки
• Google Web Toolkit
• Ваадін
• Гобелен 5

Але я думаю, що більшість справді сучасних веб-розробок на платформі JVM, швидше за все, буде здійснюватися однією з нових мов JVM, а не використовувати Java безпосередньо, при цьому Java просто надає основу з точки зору базових бібліотек та інфраструктури. У Groovy ( Grails ), Scala ( Lift and Play ), JRuby ( JRuby on Rails ) та Clojure ( Noir , Ring / Enlive + безліч спеціальних рамок) можна назвати лише декілька веб-розробок .

Зважаючи на нововведення нового мовного простору JVM, я особисто підозрюю, що Java в кінцевому підсумку стане "асемблером серверного програмування".

Чи вважаються Google, Amazon чи LinkedIn сучасними?

Java використовується для сучасних веб-додатків. Якщо ви переглядаєте підприємство, це мова, яка найбільш широко використовується для веб-додатків (внутрішніх).

Однак, Java пережила певний період, коли її стандарти для веб-розробки намагалися бути всім (можливо, досі). "Не повторюй себе" - це відповідь на пекло xml та довгі цикли складання веб-розробки Java. В результаті Java (EJB, Struts, JSF тощо) стала розглянутою як річ, яку намагалися подолати нові парадигми.

Java, мова є багатослівною. Це професіонал і кон (відмінно підходить для обслуговування, відстій для розробників). Існує ряд сучасних мовних функцій, які ще не перетворили його на Java, що дозволяє значно скоротити час кодування (властивості, події, закриття, генератори, розуміння списку тощо). Отже, це може бути неприємно, коли виходите з більш сучасної мови. Однак, їх важко додати до зрілої мови, не стаючи гніздом для щурів, яким стає C #.

Багато мов, які використовуються в сучасній веб-розробці, динамічно набираються. Це дає можливість інструменту, який може динамічно перезавантажувати код у міру написання (це важче здійснити статичною мовою - jrebel). Оскільки веб-розробка піддається швидким ітераціям, динамічне перезавантаження - це величезна виграш. Це суттєво скорочує цикл розробки проектів «зелених полів» і полегшує отримання права користувальницького інтерфейсу та UX (спроба та помилка за своєю природою).

Статичні мови теж мають своє місце. Для складної логіки, яка повинна працювати протягом багатьох років, повинна масштабуватись без проблем, повинна бути дуже швидкою, і повинна бути повністю без помилок, переважні статичні мови (наприклад, Java або навіть С).

Окрім того, у міру зростання кількості / обороту розробників та визрівання продуктів вірогідність навмисних людей, які впроваджують помилки. Суворість і дисциплінованість, що добре розроблений проект Java (інтерфейси, зразки та свята вода для тих вампірів php :)) допомагає знизити довгостроковий ризик. Незважаючи на це, це також можна досягти за допомогою тестування одиниць, захисна сітка, отримана від статичної перевірки (і статичних аналізаторів, таких як Findbugs і Clang), забезпечує вбудований рівень покриття коду, який важко повторити рукописними тестами. Не зрозумійте мене неправильно, повинні бути одиничні тести та функціональні тести, але реальні організації ніколи не досягають 100% охоплення. Що вони перевіряють, роблять статичні аналізатори.

Так, у великих проектах (як це визначено більше за розміром команди, ніж за розміром коду), де існує складна взаємодія між незалежно розробленими фрагментами коду, такі мови, як Java, все ще віддають перевагу. Приклади включають великі / складні веб-додатки, такі як фінансові брокери (ameritrade), фінансові біржі (nasdaq, nyse, можливо, Лондон після відмови .net), інтернет-банкінг (майже всі вони), електронна пошта (google), аукціон (ebay) тощо.

З точки зору продуктивності та масштабу, нічого не перевершує платформу Java, оскільки це поєднання масштабованості та продуктивності для веб-додатків (залежно від того, як ви рахуєте розділ програми facebook). Наприклад, Twitter повинен був переписати великі частини інфраструктури Ruby в Scala на Java VM, щоб повернути несправного кита назад у море. Я чув про інші великі приклади, але вони мені зараз ухиляються.

Також варто врахувати безпеку. Хоча плагіни браузера Java зазнали справедливої ​​частки вразливості безпеки, сама платформа java - одна з найбільш захищених платформ. Веб-додатки Java мають репутацію дуже захищеної. Це практики кодування, бібліотеки та архітектура давно відлякують помилок, які роблять можливими атаки на зразок введення sql або переповнення буфера. Хоча інші веб-платформи (рейки) мають гарну репутацію безпеки, жодна не перевершує Java.

Підсумок, більшість веб-додатків технічно прості. Для простоти, Java часто надмірна (як і в старі часи, коли ми писали їх на C :)). Якщо, хоча, веб-версія є складною (бекенд або іншим способом) або, як очікується, має більше 100 розробників, Java важко перемогти.

-

В особистій ноті я дуже часто використовую Грааль, тому що він дає мені найкраще з обох світів (те саме можна сказати і про JRuby, про який я чую, стає все більш популярним у світі Ruby).

BTW - Я вважаю, що підйом PHP є справді неприємним. PHP як мова є приблизним еквівалентом perl у читанні та VB у якості результатів. Це заохочує жахливі практики, поруч із неможливим у підтримці, бібліотеки сторонніх організацій рідко працюють так, як очікувалося, і у неї є синтаксис, який би загнав Ларрі Уолла ... ну ... стіну. Єдине пояснення, яке я можу отримати, - це те, що воно піддається поступовому навчанню (як VB). Іншими словами, ви можете домогтися чогось корисного, знаючи дуже мало про програмування / адміністрування, і можете розширити свої знання за невеликий шматок за раз. Для цього можна багато чого сказати з точки зору усиновлення. Однак для всіх, хто мав підтримку або заміну одного з мільярдів додатків VB, написаних "програмістами" у світі корпоративних / mfg, ви, мабуть, хитаєте головою і плануєте свою пенсію. :)

Ну, я нещодавно познайомився з хлопцем Java, який був дуже схвильований новим проектом Spring Data, через те, як мало коду потрібно, щоб отримати базовий доступ CRUD до вашого БД.

Я можу створити додаток CRUD за допомогою Rails (не лише db доступу, але й переглядів та контролерів) за допомогою декількох команд.

(Зверху в голові: новий проект, 1 команда скелета на сутність, 1 команда для переміщення бази даних, 1 команда для запуску сервера.)

Це не має нічого спільного з мовою, це все про інструменти. І схоже, що в динамічних мовах, як правило, є інструменти та рамки, які видаляють багато кодового коду. (Щоб поповнити нашу відсутність потужних ІДЕ, які генерують для нас котельну плиту.)

Також я відчуваю, що динамічні мови, як правило, значно спрощують написання таких інструментів та рамок. Я можу копати код для, скажімо, Padrino або Rails (рубінові веб-рамки) набагато простіше, ніж я можу вправити код для скажімо Spring Roo. Це може бути пов'язано з тим, що я знаю Рубі набагато краще, ніж я знаю Java.

В останні роки Java позиціонується як "підприємство". Що з іншого боку спектру того, що потрібно стартапу. У розробці веб-додатків вам потрібно 4 речі - безболісний доступ до бази даних, велика маніпуляція з рядками, синтаксичний цукор та швидкий ітераційний процес, щоб внести численні невеликі зміни, які потребує ваша програма.

Продуктивність, масштабованість та стабільність трохи нижче в списку пріоритетів.

Також Java - це дуже нефункціональна мова для кодування. Вона отримала революційну здатність використовувати рядок у операторі комутатора лише вчора. А JavaScript - дуже хакерська мова, тому після розробки фронту ви відчуваєте дуже обмеженість, коли повертаєтесь до Java.

Тому я припускаю, що це причини, за якими веб-запуски уникають Java.

Зараз я працюю в компанії, в якій є досить багато розробників "Я ненавиджу Java". Раніше мене також приголомшували. Я, звичайно, ненавиджу всі скарбниці технологій, які доступні в Java. Це робить прийняття рішень занадто важким. Це як коли у вас занадто багато вибору, у вас немає вибору. Вам доведеться провести час із 100 рамками, щоб реально придумати рамки, які працюють для вас. Стандартна архітектура Servelt є більш складною для більшості застосувань. Це не так з Рубі, Джанго та ін. Вони є скоріше єдиною рамкою, а не мовою.

Найбільші скарги, які я чую від розробників

1. Синтаксис занадто довгий. Просто для того, щоб надрукувати щось, ми повинні написати System.out.print. Ви дійсно не можете використовувати простий редактор типу VI, а за кілька годин виписати робочий фрагмент коду.
2. Слабкі тестові рамки. Хоча рамки тестування дуже схожі в Java та Ruby, Ruby робить крок вперед, роблячи річ легко доступною для тестування. Це особливо актуально, якщо ви широко використовуєте БД у своїй програмі. Навіть багато веб-рамок не думають про тестування.
3. Шаблони - це біль. Перетворює порівняно просту мову в суп з локшиною.
4. Не круто. Більшість додатків Java написані у величезних компаніях, що асоціюється з бюрократією, що не дуже добре йде з розробниками. Люди не думають Google, коли думають Java. Google == Python. Він також повинен багато робити, не виходячи жодної книги, що свідчить про те, що робити X за Y дні.
5. Не люблю компілювати. Для більшості розробників компіляція - це явище десятиліття. Це було сенс у 80-х роках з C, але монтерні комп’ютери можуть зробити набагато більше. Вони не пишуть код компільованими мовами. Java - одна з небагатьох мов, яка компілюється та використовується для написання веб-додатків.
6. Забагато понять Oops. Навіть незважаючи на те, що розробники спокійно прийняли домен Oops. Вони не люблять це в повному обсязі. Їм не подобається, коли ти пишеш заявку з 10 класів, з кожним класом робиш лише одне. Змушує відкривати 100 файлів і уявляти собі взаємодію протягом 100 класів, іноді з рамками. Здійснює всю програмову діяльність. Це може бути правдою для більшості мов, але я бачив, що розробники Java приділяють багато уваги тому, що робить клас. Його розробники Java, які часто придумують код із 100 класів. Це добре з багатьох точок зору, але розробники, які не входять у java, ненавидять це.

Так що загалом Java накладає круту криву на початку проекту, що означає занадто багато грошей. Додайте до цього величезну спільноту, приєднану до java, кожен мислить по-різному і нікого, хто насправді керує цілою громадою. Вони також не бачать переговорів та конференцій, що проводяться громадою, демонструючи всі нові цікаві речі. Ніяких нових класних книг. Java, схоже, знизиться, тому що вона використовувалася для вирішення занадто багатьох різних проблем за кілька років тому.

Рамки для розробки веб-розробок Java мають трохи кривої навчання, вони часто є надмірними для того, що вам потрібно, і велика частина непрямості, необхідної для роботи, просто ... болісно ... працювати.

Раніше я працював у компанії, яка займалася розробкою Spring / Java, і я вважала, що рамки в кращому випадку є громіздкими. Я не маю багато приємного сказати про рамки Spring, за винятком того, що у мене був друг, який раніше займався розробкою Струтса, і він вважав, що Струц ще гірший. Веб-фреймворк - це не що інше, як робити настільні додатки або мобільні (наприклад: android) програми, і має безліч дуже абстрактних ідей, які потребують певного часу, щоб дійсно зрозуміти (хоча, безумовно, це дає багато сил та можливостей, якщо ви ви професіонал і робите щось дійсно складне, як-от додаток для корпоративного класу). Я люблю програмування Java для мобільних або настільних пристроїв, але java для веб-додатків? Не так багато.

Я не робив жодного програмування особисто в Ruby / Rails, але мій друг, який раніше робив Struts, зараз займається веб-програмуванням Ruby і свідчить, що речі, які важко зробити в веб-програмуванні Java, вимагають набагато менше коду та складності для досягнення в Рубін. Звичайно, існує крива навчання різних правил синтаксису та мови, але для програм для прототипування це має переваги щодо того, скільки коду потрібно для досягнення бажаного результату. Як зазначали інші, масштабування також є проблемою, і одна з причин, що більш зрілі програми не сприймаються так часто на більшості мов стегна.

Це зводиться до витрат і тенденцій. Запуск Web 2.0 створений молодшим візіонером, який має більше талантів, ніж гроші (я, звичайно, узагальнюю, але це те, що ви побачите "в середньому"). Він збирається використовувати мову, яку він знайомий, тому що займається програмуванням (разом, можливо, з кількома друзями). Він, швидше за все, програміст-самоук.

Java орієнтована на корпоративне середовище (під Java, я маю на увазі мову, рамки та стандарти). Є купа дорогих інструментів, які IBM, Oracles та BEA світу хочуть продати підприємствам.

Етапи, які набувають знання Java, є складними та / або дорогими. Я знаю, що ландшафт там змінюється, але чи занадто мало пізно?

Після того, як стартап набирає тягу, настає зростання. Набір талановитих розробників важко. Більшість програм "стати програмістом за шість тижнів" навчають Java (або .NET), а ринок насичений "шести тижневими програмістами" (як не дивно, я бачив розробників із резюме, які говорять про 7-річний досвід, який все ще показує знання шести тижневий програміст). Використання непрофільного середовища, що не є "підприємницьким", може бути природним фільтром для програмістів шість тижнів. Щоб вивчити Ruby або Scala поза вимогою на роботу, потрібна відданість та особисті інвестиції. Це для мене найбільший показник потенціалу кандидата.

Знання надходять із досвідом, але завзятий / пристрасний програміст здобуватиме знання швидше (в середньому), ніж хтось без цієї відданості / пристрасті. Так само, як дитина, яка любить грати на гітарі, стане кращою швидше, ніж дитина, яка бере уроки, тому що його зробив її тато.

Java занадто складний. Я роблю багато PHP роботи, і це просто простіше і швидше в більшості ситуацій. Можливість просто SSH на сервері відкрити файл php дозволяє змінити збереження і зробити це чудово. Кілька додатків Java, над якими я працював, завжди потребували перезавантаження для найпростішої зміни. (не кажучи, що це завжди так, що я дельтую). Додатково хостинг PHP - це дешево і легко.

Я також думаю, що у вас є принаймні PHP - це багато розробників, які, як я, розпочали 14/15 років тому зі статичним HTML. По мірі того, як справи прогресували, ми почали додавати PHP на наші сайти, оскільки це було легко, просто та доступно. З роками мова зростала і розширювала свої здібності далеко поза її скромними початками, і зараз дуже старається бути тим, що, на мою думку, є багато речей, що насправді це не так.

З іншого боку, я знаю, що Java - це гігантська надмірно складна горила на 800 фунтів, майже як вийти з 18 вантажівки-напівнавантажувача, щоб заїхати до продуктового магазину та отримати хліб хліба.

Я спробував вивчити Яву, мої перші враження, де це було дуже довго звивалося і викликало зап'ястний тунель. Крім того, починаючи, це залишило у мене багато питань, які, мабуть, здаються ветеранам Java просто OpenJDK, або Sun? Томат, або Склянка, або? Плюс здається, що кожне вступ до книги Java запускає написання коду для командного рядка. Я думаю, що більшість людей в цей час вважають, що це затяжний фест.

Зараз ми з моєю командою розробляємо веб-додаток «greenfield» на Java 6 + Stripes. Протягом останнього року я також працював над іншим веб-додатком «greenfield», використовуючи Java 6 + Stapler (дещо невідомий веб-фреймворк, розроблений Косуке Кавагучі із слави Хадсон / Дженкінс).

Java абсолютно використовується для сучасної веб-розробки. Звичайно, у нього немає "сексуальної" привабливості Рубі чи інших динамічних мов, але я далеко не впевнений, що динамічні мови - це добре, коли проект починає масштабуватися.

Сучасні сервери додатків Java дуже конкурентоспроможні з ASP.NET з точки зору продуктивності, і обидва набирають порядків швидше, ніж будь-яка динамічна мова, яку я знаю.

Не зрозумійте мене неправильно ... Я не кажу, що Java - це завжди найкращий вибір (не віддалено!) - але і не завжди це неправильний або "застарілий" вибір.

1. Java є більш складною для вивчення, ніж PHP / Python / Ruby
2. Екосистема Java дуже складна, дуже велика і досить заплутана для початківців
3. Існує багато історично поганих фреймворків з негативною репутацією, пов’язаними з Java, ви повинні знати, на які рамки уникати витрачати час на
4. Інструменти побудови Java - це шлях до складних завдань (Maven & Ant)
5. У Java немає модульних систем, які прості у використанні (OSGI занадто складний)
6. Java IDE, наприклад Eclipse, хоча дуже потужну та дивовижні функції важко налаштувати для ефективної веб-розробки без великого досвіду.
7. Якщо ви використовуєте що-небудь, крім Tomcat або Jetty в якості сервера, ви будете розчаровані довгими часом запуску WebSphere / WebLogic / JBOSS
8. Java EE вирішує проблеми, які у багатьох людей відсутні, наприклад, розподілені транзакції

Новий розробник, який займається професійним розвитком, знайде Java на ордер величини важче, ніж рейли, пітон або php, щоб розпочати роботу, тому вони йдуть з тим, що легко вивчити.

Сказавши все вищесказане, я прийняв рішення використовувати Java для мого запуску, оскільки правильно налаштоване середовище розробки Java дуже продуктивне для роботи. Я маю на увазі правильно налаштований.

1. Менше 10 секунд часу запуску
2. Правильно налаштована робоча область затемнення із усіма рамками, налаштованими та налаштованими
3. Хороший вибір бібліотек (Spring, Spring MVC, Spring Social, Spring Security, JPA, Hibernate, Velocity, .... тощо)
4. Швидкі машини для розробників із SSD
5. Підписка на Orielly Safari

Близько 5 років тому мені та колезі було задано програмування для якогось внутрішнього проекту. Досить проста задача, яка вимагала розбору команд.

Я придумав всю справу приблизно в 80 рядках коду Java, і мій колега взяв тиждень, приблизно 20 класів java та багато інших рядків коду Java, щоб зробити те саме. Потрібно сказати, що його код був обраний.

Це мене здивувало. Всюди цінували складність. (Я працював в одній з найбільших компаній із програмних продуктів.) Java був інструментом вибору, а шаблони дизайну - це спосіб кодування.

Тепер, непритомність чи просто зарозумілість відкидає простоту. Ну, я завжди вважав, що здоровий глузд повинен панувати. Будь то підприємство чи звичайний веб-додаток, основні випадки використання однакові. Він повинен бути правильним і перевіреним.

Я більше не використовую Java з кількох причин. Але один з факторів - складність, полягає в переважаючому мисленні в тоні java devs, коли мова йде про розробку програмного забезпечення.

Що стосується масштабування динамічних мов, JVM - результат десятиліть досліджень. З Рубі відбувається багато того ж.

Scala - це одна з мов, яку я вважаю надзвичайно розумною та практичною. Грайте! Скала настільки ж чудова для розробки додатків для веб / підприємств, як і будь-яка інша.

Що стосується Ruby and Rails, що є новою блискучою справою для стартапів, найняти надійного розробника Rails надзвичайно важко. Це насправді перешкода будь-якому стартапу, тоді як безліч java devs має надати більше ділового сенсу.

У недавньому інтерв'ю Джозефа Снарра, технічний посібник для google plus, пояснив, як програма використовує Java сервлетів для заднього та JavaScript на передньому.

Отже, щоб відповісти на ваше запитання, Java все ще використовується для дуже сучасної веб-розробки. Тільки не для стартапів, які останнім часом отримують таку кількість преси.

Я думаю, що причина, коли багато стартапів використовують інші технології, полягає в тому, що вони сексуальніші та мають більш широкий розголос, що відкриває їх за собою.

Оскільки ви згадали про веб-розробку та Java, багато людей, як правило, забувають, що спочатку використання Java-аплетів у веб-браузері не було добре, не тільки це, але "пісочниця" для аплетів була не повністю розроблена і виникли проблеми із безпекою. з можливістю запуску Java Applets у веб-переглядачі та доступу до даних локальної машини (також проблема безпеки клієнта). Впевнений, що Java була надійною в резервних та автономних програмах, але я думаю, що асоціація мови Java з аплетами Java (запускається в браузері) разом начебто викрутила деякі уявлення про Яву як компонент веб-розробки. Я не думаю, що вони коли-небудь одужали від цього.

Питання повинно бути "Чому Java не використовується стартапами або для малих проектів?". Java, безумовно, використовується для "сучасних веб-додатків". В Google, Java використовується в сервісному центрі для багатьох сервісів, а закриття, складене JS або GWT, використовується для інтерфейсу. Проблема - швидкість проти масштабу. Стартапам потрібно досягти мінімально життєздатного продукту. Зазвичай вони невеликі команди з 1-3 інженерів і цінують швидкість ітерації над продуктивністю чи ремонтом. Наткнутися на проблеми з масштабованістю або проблеми з підтримкою коду команди - це проблема, яку "ви хотіли б мати", тобто до моменту, коли ви досягнете цього етапу, це знак, що ваша первісна реалізація допомогла вам за початкову групу залучення клієнтів або інвестиції. Ви можете дозволити собі переписати додаток у цей момент.

Така компанія, як Google, може дозволити собі розкіш будувати речі для збільшення масштабів, хоча вони можуть витрачати час на впровадження масштабування на те, що може не отримати користувачів, оскільки вони можуть поглинути втрати.

Принаймні, це моя думка, що багато багатьох «крутих», «хіп», «сучасних» компаній будують невеликі програми з невеликими командами, де швидкість і простота ітерації є найбільшою вимогою.

Традиційні веб-програми на Java, хоча і добре структуровані, дуже далеко не "швидко розвиваються". Хоча я коли-небудь писав один повноцінний веб-додаток (Java / Tomcat / Struts), він був надзвичайно прискіпливим, потребував більше часу, ніж очікувалося, налагодження, і, як правило, болісно під час впровадження рівня бізнес-логіки. Що стосується потенційної оборони Java, це був єдиний веб-додаток, який я написав на Java (хоча я звик програмувати додатки на системному рівні в Java), і я вважаю, що міг написати другий веб-додаток трохи швидше вдруге.

Сказавши це, я також писав додатки в PHP і C #, і вони просто працюють краще і набагато прощають, ніж Java. Більше того, Ruby on Rails був написаний спеціально для швидкого розвитку додатків, які, як сказав Роббі, дозволяють легко отримувати доступ до баз даних CRUD. Проблема полягає в тому, що більшість веб-сайтів, які ви розробляєте самостійно, не потребують рівня налаштування, який пропонує Java (і вимагає від вас виконання). Крім того, кожен об'єкт з'єднання з БД повинен бути написаний вручну, і це не так просто для шаблонування. Можливо, є краща рамка, особливо така, яка використовує переваги нових функцій підтримки динамічної мови Java 7 , але я ще не провів дослідження.

Проста відповідь: крива навчання базової продуктивності.

Рамкові системи, такі як RoR, як правило, вкладають "магію" в мову / синтаксис. Налаштувати ваш основний синтаксис RoR дуже просто та отримати додаток та роботу.

Java була спочатку мовою, а інструменти та рамки з'явилися пізніше. Таким чином, ви повинні спочатку вивчити Java, а потім ви повинні вивчити Весну, або Грааль, або ваш супер IDE, або будь-що інше. Улюблений приклад Ruby, він не вимагає сеттерів та геттерів. Факт полягає в тому, що Java IDE також позбулися ручного кодування ... але це все ще є у вашому джерелі. Перевага такого підходу полягає в тому, що під рамками є мова, яка відповідає всім розробникам Java.

Ця користь сумнівна для малих стартапів, де час є суттєвим. Зазвичай вони роблять дуже мало, що не могли б зробити з поза рамками. Таким чином, вони можуть захопити свою систему RAD на власний вибір і мати додаток наживо наступного дня.

Але якщо поглянути на Facebook і Twitter, як вони розширюються, вони виявили речі, з якими не можна було впоратися з нестандартних рам, і тому їм довелося використовувати технології нижчого рівня.

Ця свята війна, яку розробники рамки мають, що вони можуть робити все швидше, є хибною, вони можуть зробити багато того, що їм потрібно, і простіше, і з меншою кривою навчання. І для багатьох речей це "досить добре". Використовуйте те, що підходить для проблеми.

Залежить від того, як ви визначаєте "розробку сучасних веб-додатків". Якщо ви говорите про запуску, швидкі веб-сайти, вам потрібно буде розглянути мови та рамки, розроблені для цієї мети. Якщо ви шукаєте стабільну, масштабовану, веб-розробку на рівні підприємств, ви шукаєте мови та рамки, які підтримують ці ідеали. У моїй книзі це дві дуже різні цілі. RoR, Groovy та ін. Хороші для перших, а Java більше підходить, взагалі, для другого.

Google App Engine підтримує Java, так що ви можете писати весь веб-додаток на Java, використовуючи Eclipse як інтерфейс IDE та розгортання, з достатньо документально підтвердженим API Google - тому я б не сказав, що він не використовується або не використовується придатний для використання.

У запуску, над яким я працюю, ми вирішили використовувати як Java, так і JRuby для реалізації нашого API, оскільки вони доповнюють один одного.

Для інфраструктури, розподілу процесів та комунікацій ми використовуємо надійність Java, тоді як для реальної реалізації кінцевих точок API ми вибрали JRuby, оскільки всі дзвінки включають JSON і має набагато більше сенсу маніпулювати представленням із типовим типом (JSON) з використанням вільно. -типізована мова (Ruby).

Якщо ми бачимо, що один з наших класів JRuby стає вузьким місцем, ми просто повторно реалізуємо його безпосередньо на Java (в основному це рядковий переклад). Це може траплятися досить часто з класами, які повинні робити багато обчислень, і в цьому контексті JRuby поводиться так само, як мова прототипування.

Ми реалізували власний завантажувач динамічного класу, що означає, що ми можемо змінювати класи Java на ходу, не перезавантажуючи сервер, і ми були дуже задоволені вибором. Тож аргумент "потрібно кожного разу збирати та перезавантажувати" не має великої ваги.

Ключовим моментом є уникання всіх матеріалів Java EE - це величезне, громіздке та антигігічне.

У мене ще є відчуття, що Java використовується в багатьох веб-розробках. Але зазвичай це стосується більше бізнес-орієнтованих, не головним чином, технологічних, великих компаній, які, як правило, є менш відкритими, ніж нові стартапи, які повинні отримати деяку тягу та просувати власну роботу, а також більше зацікавлені в технології . Тож, навіть якщо він використовується на багатьох корпоративних веб-сайтах, ви, мабуть, ніколи не дізнаєтесь, оскільки вони не потурбуються публічно розповісти про свій стек технологій.

Це було сказано, коментуючи всі початкові питання ...

Це слабкість мови? У порівнянні з іншими мовами, такими як Python або Ruby, Java є багатослівним і, як правило, потрібно більше коду, щоб робити подібні речі. Але це не лише можливості мови, а й спільнота, яка її оточує, і тип розробників, які використовують ці інструменти. Таким чином, більшість модулів та інструментів на Python, Ruby, PHP тощо є відкритим кодом і їх легше знайти, ніж у світі Java, лише тому, що цей більш орієнтований на надання (та заряджання) послуг. Наприклад, спільнота Ruby дійсно орієнтована на веб-розробку, тому кожен розробник, який може використовувати Ruby, буде знати про проблеми та доступні інструменти для веб-проекту. Це не обов'язково стосується розробників Java, які могли працювати над іншими системами, такими як системи звітування. Звичайно, будь-який хороший розробник наздожене,

Це несправедливий стереотип Java, оскільки він існує так довго (він був несправедливо пов'язаний із його старими технологіями і не отримує визнання за свої "сучасні" можливості)? Java насправді не така стара, і, справедливо кажучи, значно покращилась. Це була класна, відповідна платформа близько 10 років тому. Але відтоді з'явилися нові платформи з новими проблемами на увазі, як Ruby on Rails. Основним сектором Java був, в основному, корпоративний світ з різними проблемами, тому люди шукають нові проекти за межами, які шукають різні інструменти. Крім того, головна перевага дизайну Java, будучи багатоплатформою, сьогодні не настільки актуальна, як раніше.

Чи занадто сильний стереотип розробників Java? (Java просто більше не "крута"). У цьому є і правда. Ява все ще є мовою для вивчення "влаштування на роботу". Отже, якщо вам все одно, а просто хочете щось навчитися заробляти гроші, ви закінчите вивчати трохи Java і більше не дбаєте про вдосконалення. Знову ж таки, багато про сприйняття та наочність. Є багато чудових розробників Java, які кодують, не ділячись своїми знаннями, тоді як є багато розробників PHP, можливо, не так добре, які пишуть блоги та співпрацюють у відкритому коді. Це призводить до думки, що розробники PHP кращі за Java, оскільки ви маєте певні відгуки про них.

Чи справді програми, написані іншими мовами, швидше збирати, простіше в обслуговуванні та чи ефективніші вони? Я б сказав, що вони швидше будуються. Принципи таких мов як PHP, Python або Ruby роблять їх досить непоганими для створення програмного забезпечення, яке може постійно змінюватися. Наприклад, динамічне введення полегшує зміну інтерфейсу. У Java важливий чітко визначений інтерфейс, який призводить до стабільніших (і їх важко змінити) інтерфейсів. Це дуже важливо в новому стартапі, головна проблема - отримати продукт, перш ніж у вас закінчуються гроші. Щодо продуктивності, то дуже легко зрозуміти потреби та спробувати використати магічні трюки для досягнення необхідної продуктивності, наприклад, "Java швидша за Ruby. Період" або "MongoDB - це масштаб веб-сторінок".

Чи Java використовується лише великими компаніями, які занадто повільно адаптуються до нової мови? Однозначно, маючи в компанії вже наявну команду розробників Java, це полегшує використання тієї ж мови для нових проектів. Це сприймається як "безпечна ставка", особливо якщо основою компанії є не технології. Але, у будь-якому випадку, Java не використовується ТОЛЬКО у великих компаніях, є ще багато стартапів, які використовують Java для класних матеріалів (наприклад, FightMyMonster або Swrve широко використовує Java), але я б сказав, що загальна тенденція в запуску. сцена полягає у використанні інших мов. Це також спосіб залучити людей, оскільки більшості людей буде цікавіше працювати з Ruby, Python або PHP, сприйманими як "дружніші" та "веселіші"

Це правда, але не через Яву та її екосистему. Це через те, що люди, які користуються Java, схильні створювати великі безладдя і важкі гидоти.

Є достатньо фреймворків (spring-mvc, grails, play тощо), які дозволяють швидко будувати речі. Той факт, що люди перенапружують свої системи - це проблема, яка виникає із збільшенням знань, які люди отримують під час роботи з екосистемою Java - ви знаєте багато іншого, і у вас є їх доступні (є інструменти для всього), і "все виглядає як цвях ».

Якщо ви "хакі", ви можете зробити те ж саме з Java, що і з іншими мовами, і ось дослідження, яке свідчить про те, що:

Дослідження 49 програмістів: система статичного типу не вплинула на час розробки ... http://www.cs.washington.edu/education/courses/cse590n/10au/hanenberg-oopsla2010.pdf

Щоб додати лише трохи до сказаного, я думаю, що багато чого стосується того, як швидко ви можете перейти від нічого (буквально) до функціонального веб-додатку.

Якщо все, що ви маєте сьогодні, - це ідея, іти від того, де ви зараз пишете веб-додаток, це так само просто, як і впасти, будь то вибрати хостинг-провайдера або власну інфраструктуру (наприклад, зображення EC2). На моєму досвіді вибір Java, як правило, більше роботи, і часто також коштує дорожче.

Крім того, якщо ви користуєтесь Linux та PHP / Python / Ruby, інструменти та платформа є безкоштовними та розроблені, щоб підтримувати один одного. Для Java іноді здається, що два світи (ОС і Java) іноді, здається, не працюють в гармонії один з одним.

Хто каже, що це не так?

Весняний MVC + Весняні дані JPA або Mongo + Чебрець для шаблонування + кава-плагін-плагін для кави в JS-трансляцію, і ви готові йти.

Багато хто може пов'язувати розробку Java та веб-додатків з жахами J2EE, які разом із жахливими серверами додатків J2EE від великих синіх та червоних корпорацій дорівнювали тижням роботи до того, як основний "Hello World" був онлайн.

Щоправда, останні технічні характеристики та реалізації JEE мають меншу вагу, але я все-таки думаю тричі, перш ніж запропонувати щось подібне для короткого циклу проекту швидкого розвитку.

Це все ще заснований на стандартах спосіб розвитку веб-додатків на Java. Альтернативи, багато з яких згадуються в інших відповідях, представляють більш змішану та заплутану картину із занадто великим вибором.

Інші мови зображують єдине рішення під ключ замість цього безлічі. Це робить цей вибір більш придатним за призначенням, коли у вас є більш важлива риба для смаження.

Я думаю, що він використовується набагато більше, ніж ви могли б подумати - використання знаходиться трохи нижче ватерлінії. Існує багато, багато рубінів на рейкових обгортках навколо товстих, вишуканих послуг Java. Особливо, коли ти починаєш займатися будь-чим, що наближається до великих даних. . .