Большие вопросы об изображении относительно Django, Java, Python, HTML и разработки веб-сайтов, в целом [закрытой]
8 ответов
Хм, вы задали целый список вопросов. Я выберу пару важных и отвечу на них.
Что касается обоснования для таких языков, как Python... правда в том, что многие веб-приложения либо привязаны к вводу-выводу, либо к базе данных. В этом случае не имеет большого значения, если используемый язык не такой быстрый, как C++ - узкое место находится в другом месте. Кроме того, огромное количество основных процедур и структур данных Python написано на C. Python используется для управления самым высоким уровнем логики, но большая часть работы происходит в быстром родном коде. Возможно, вы удивитесь, узнав, что на моей нынешней работе я пишу на Python программное обеспечение для 3D-анимации. Конечно, многое из того, что происходит за кулисами, было написано на C++. Для этого есть название: "Чередование жестких и мягких слоев". Причина, по которой мы используем Python, довольно проста - наш выбор - Python или C++ из-за API, на которых мы пишем, и мы в несколько раз более продуктивны на Python. Я бы спросил, в чем смысл существования C++, но это уже другая тема (и флеймбайт ;)).
Что касается вопросов визуального представления... Традиционно существовало довольно четкое разделение между логикой приложения на стороне сервера и логикой в браузере, частично потому, что единственный язык, на присутствие которого в браузере можно рассчитывать, - это Javascript (и даже тогда вы не можете рассчитывать на его присутствие, если оставить в стороне существование браузеров типа Lynx). Поэтому вы писали серверную логику на каком-нибудь фреймворке вроде Django, а затем использовали какой-нибудь фреймворк Javascript, чтобы сделать внешние вещи, и (в последние несколько лет) использовали что-то вроде AJAX, чтобы позволить им взаимодействовать немного более гладко.
Эта парадигма все еще остается доминирующей, но ситуация начала меняться. Многие серверные фреймворки начали включать средства для генерации Javascript тем или иным способом. И люди начали писать компиляторы, которые переводят с других языков на Javascript. Одним из ярких примеров является GWT от Google, который переводит с Java на Javascript: http://code.google.com/webtoolkit/ Однако есть и другие примеры подобного подхода. Несколько лет назад я много программировал в библиотеке common lisp под названием parenscript ( http://common-lisp.net/project/parenscript/), и есть начало библиотеки Clojure ( http://clojure.org/) для создания чего-то подобного. Также, одним из самых интересных наборов фреймворков является Seaside/Magritte ( http://www.seaside.st/ и http://www.lukas-renggli.ch/smalltalk/magritte), которые используют продолжения для управления состоянием виджетов. Существуют аналогичные фреймворки для scheme и common lisp.
Что касается того, что html похож на ассемблер, я склонен согласиться в тех случаях, когда я пишу html. В таких случаях я склонен использовать некий слой абстракции для генерации html. Но огромное количество html в мире создается дизайнерами. Некоторые из них используют приложения с графическим интерфейсом для создания html, а лучшие - текстовые редакторы. Но большинство из них не хотят иметь дело с чем-то более сложным, чем простой шаблонизатор в html, который они знают.
Одна вещь, которую вы должны понять об эволюции Интернета, заключается в том, что http и html изначально не были разработаны для выполнения тех вещей, для которых они используются сегодня. К тому же, основные браузеры очень часто были действительно сломаны. И, кроме того, вы не можете контролировать, какие средства доступны пользователю - он может использовать любой браузер, с Java, Javascript, Flash и т.д. или без них, и с любой из множества перестановок багов в зависимости от браузера. Поэтому только в последние несколько лет ситуация стабилизировалась настолько, что люди стали немного менее консервативны в отношении средств, которые они используют на стороне клиента. По-прежнему полезно убедиться, что страницы деградируют изящно, когда это возможно. Веб-страница общего назначения должна быть пригодна для использования в текстовом браузере, хотя, конечно, многие типы веб-приложений невозможно заставить работать в такой ограниченной среде.
HTML 5 собирается встряхнуть многое из этого. Но пройдет еще много времени, прежде чем можно будет с уверенностью утверждать, что все используют браузер, способный работать с HTML 5, и еще дольше, прежде чем можно будет считать, что все используют браузеры, в которых реализован весь HTML 5. В любом случае, я бы посоветовал вам присмотреться к некоторым менее заметным проектам, таким как Seaside, например. Там происходит много экспериментов. Но веб всегда был сложной средой для такого рода вещей.
Django не пытался вводить новшества в том, как веб-сайты отображаются в браузере. Их целью было упростить процесс создания веб-сайта. Они могли бы использовать новые способы создания виджетов в браузере как часть этой цели, но они этого не сделали. При классическом построении веб-сайтов приходилось избавляться от множества проблем.
Если вы создаете веб-сайты, вы будете иметь дело с HTML. Ваша аналогия с ассемблером интересна, но в этой аналогии не появилось никаких популярных языков высокого уровня. Вероятно, это связано с тем, что каждый язык более высокого уровня по необходимости налагает некоторые ограничения на то, что может быть выражено, и сеть не находится на грани того, чтобы желать подобного соответствия.
Python - более простой в использовании язык, чем C ++, и на нем действительно можно быстрее развиваться. Тебе следует это попробовать. Автоматическое управление памятью - одна из причин, но другие - это простые в использовании структуры данных, не требующие разрешения компилятора делать то, что вы хотите, обширные сторонние библиотеки для развития и свободный от беспорядка язык, на котором можно проявлять себя. О скорости: веб-сайты не привязаны к вычислениям, они привязаны к вводу-выводу, поэтому скорость языка редко имеет значение.
О специальной природе веб-разработки. Вы исходите из опыта разработки Windows, когда один поставщик определил всю среду и хорошо с ней справился.Веб-разработка носит спонтанный характер, потому что сама сеть носит спонтанный характер. Ни одна группа не определила его, он вырос органически благодаря участию многих.
Материал javascript может показаться пугающим, но сегодня есть довольно приличные библиотеки, которые являются Free/OSS, прежде всего jquery. Я рассматриваю jquery как частичную замену Flash.
Вам не нужно так много дополнительного javascript, чтобы использовать его продуктивно. Я бы определенно использовал jquery, если бы мне нужно было сделать интерфейс, подобный тому, что использует chess.com.
И я раньше думал, что html можно сравнить с ассемблером, так что обычный разработчик приложений прошлых лет мог знать и иногда даже использовать немного ассемблера, но в целом почти никогда им не пользовался, тогда как, насколько я могу судить, html (а также CSS и javascript) по-прежнему должен быть освоен и постоянно написан каждым веб-разработчиком, независимо от того, используют ли они Django или что-то другое. Верно ли это утверждение?
Да - если вам нужен сайт, кому-то придется писать HTML.
HTML отличается от ассемблера тем, что вы не можете писать парсеры для новых языков на HTML. HTML - это просто декларативный язык для добавления смысла в текст. Как таковой, главное, чтобы все в мире согласились с тем, как его отображать и что означают теги. Со временем на смену ему может прийти что-то новое, но HTML до сих пор доказал свою работоспособность и жизнеспособность. Его также довольно легко изучить, и он бесплатный.
Скорее всего, для такого сайта используются Java-апплеты? Насколько уместен был бы Django для такого сайта. Можно ли использовать Django в сочетании с чем-то вроде Flash или даже Java-апплетов?
Django действительно занимается только серверной стороной веб-сайтов. Клиентская часть (т.е. то, что запускается в браузере) остается на ваше усмотрение. (Кроме встроенного администратора сайта.)
Существуют ли на самом деле полноценные сайты, написанные исключительно на Java, возможно, использующие Java API очень высокого уровня?
Я не думаю, что это распространено. Java-апплеты почти не используются, и некоторые люди (cough Steve Jobs cough простите за кашель, я сказал "Steve Jobs") думают, что Flash пойдет тем же путем.
В дополнение ко всему, что до сих пор говорили все, просто создание очень простого веб-сайта с использованием HTML, некоторого CSS и, возможно, даже некоторого JavaScript, вероятно, даст вам хорошее представление о том, как эти три работают . Место вроде HTMLDog - хорошее место для начала.
Кроме того, прочтите немного о HTTP-протоколе , поскольку это все еще то, что используют обычные веб-страницы и, следовательно, определяет основы того, как серверы и клиенты взаимодействуют в сети.
HTTP, HTML, CSS и JavaScript - это (и, вероятно, еще какое-то время) то же самое, когда вы используете Java, Django, ASP.NET или PHP для логики своего приложения. Если вы больше занимаетесь веб-разработкой, это актуально независимо от того, какую серверную технологию вы когда-либо выбрали бы. Кроме того, неплохо иметь общее представление о браузерах. И то, как они обрабатывают визуальный рендеринг HTML и CSS, а также то, как обрабатываются сеансы, файлы cookie и запросы.
Все инновации будут касаться проблем с базами данных, бизнес-логики, возможности повторного использования кода и т.д., но на самом деле ничего нового в отношении инновационных визуальных элементов управления или графики для веб-сайта
Верно. Хорошая оценка. Это проблема?
html может быть аналогичен ассемблеру, поэтому обычный разработчик приложений из прошлых лет может знать и иногда даже использовать небольшой ассемблер, но, как правило, вряд ли когда-либо будет использовать его
False. Действительно, даже не близко. Все браузеры используют HTML. Это не может быть легко изменено.
chess.com ... Скорее всего, они используют Java-апплеты для такого сайта?
Используйте исходный код в своем браузере, чтобы ответить на этот вопрос для себя. В общем, вы должны делать это для каждого посещаемого веб-сайта. Вы узнаете много нового о сети и веб-разработке.
Будет ли Django использоваться вместе с чем-то вроде Flash или даже Java-апплетами
Да. Мы используем FLEX и Django.
Кроме того, когда такой сайт, как chess.com, переносится на мобильное устройство, то, что используется для его написания - те же инструменты разработки, что и для настольных компьютеров, или что-то совершенно другое (Да, мне нужно многое наверстать. )
Да.
Существуют ли на самом деле полные веб-сайты, написанные исключительно на Java, возможно, с использованием Java API очень высокого уровня?
Да.
Почему кто-то сказал (как я где-то читал), что они презирают Java, поэтому они и попали в Ruby on Rails и Django.
Некоторым людям нравится презирать Java. В их аргументе мало технических оснований.
После того, как вы освоите Java и Python, вы обнаружите, что Python менее многословен.Вы делаете больше, меньше печатая.
каково оправдание их существования [Python PHP]?
Они лучше, чем альтернативы. Для конкретных вещей, которые нужно делать людям, Python (или PHP) лучше, чем альтернативы. Для «всего» или даже для широкого класса вещей это может быть не совсем ясно.
Мы занимаемся специальной обработкой данных. Гибкость Python абсолютно превосходит альтернативы.
Во-первых, Python интерпретируется намного медленнее, чем, скажем, C ++.
Оказывается, это вряд ли имеет значение. Веб-сайты не зависят от чистой скорости одного элемента архитектуры.
Почему веб-сайты написаны на Python или PHP
Это проще, чем альтернативы.
- единственная проблема здесь - независимость от платформы.
Нет.
Мне не верится, что разработка приложений на Python выполняется намного быстрее, чем на C ++.
Вы много сделали с Python? Вы должны попробовать в течение года или около того. Это делает C ++ довольно утомительным и подверженным ошибкам по сравнению.
основная причина использования Python - сборка мусора.
Нет.
Из того, что я читал, ROR пытается сделать все за вас за кулисами, поэтому он медленный и не масштабируемый (а также раздуваемый и не готовый к работе в прайм-тайм).
Ну, во-первых, не стоит верить всему, что вы читаете в Интернете:
- Я бы не сказал, что RoR не готов к прайм-тайму. У RoR, как и у любого другого инструмента, есть свои применения.Если вы создаете сайт вроде Twitter, возможно, Rails не лучший инструмент (как выяснил Twitter). В то время как все думают , что создают высокопроизводительный сайт, большинство разработчиков - нет, и Rails, вероятно, подойдет. Более того, Rails может масштабироваться, и была проделана большая работа, чтобы еще больше улучшить эту ситуацию.
- Причина, по которой Rails иногда имеет проблемы с производительностью, заключается не в том, что он пытается делать все за вас, а в природе самого интерпретатора Ruby, который (до Ruby 1.9) был довольно медленным, и все еще не так быстро, как другие интерпретируемые языки.
И первое, что меня удивляет в Django, это то, что, похоже, нет никаких новшеств в отношении фактического представления. Все инновации будут касаться проблем с базами данных, бизнес-логики, возможности повторного использования кода и т.д., но на самом деле ничего нового в отношении инновационных визуальных элементов управления или графики для веб-сайта.
Да, но это нововведение. До таких фреймворков, как Django и Rails, большая часть этой внутренней работы выполнялась вручную. Django освобождает время разработчика для работы над дополнительными функциями уровня приложения.
И раньше я мог подумать, что html может быть аналогичен ассемблеру, поэтому обычный разработчик приложений из прошлых лет может знать и иногда даже использовать небольшой ассемблер, но обычно вряд ли когда-либо будет его использовать, тогда как из того, что я вижу, html (а также CSS и javascript) по-прежнему необходимо постоянно осваивать и писать каждому веб-разработчику, независимо от того, используют ли они Django или что-то еще. Это правда?
Да, в значительной степени. Ничего лучше, чем HTML, CSS и JS, не представилось. Хотя я согласен с тем, что в некотором смысле HTML кажется "низкоуровневым" в том же смысле, что и язык ассемблера низкоуровневым, я думаю, что большинство согласится с тем, что по сравнению с проблемной областью работать с HTML намного приятнее.
Будет ли Django использоваться вместе с чем-то вроде Flash или даже Java-апплетов?
Можно. Flash и Java просто встроены в HTML-страницы, а Django выводит HTML, так что это, безусловно, возможно.
Существуют ли на самом деле полные веб-сайты, написанные исключительно на Java, возможно, с использованием Java API очень высокого уровня? Почему кто-то сказал (как я где-то читал), что они презирают Java, поэтому они и попали в Ruby on Rails и Django.
В дополнение к апплетам вы можете написать бэкэнд на Java (например, Java Server Pages). Я думаю, что большинство веб-разработчиков, которые работали с обоими, согласятся, что Ruby и Python намного удобнее в использовании, чем Java. Веб-фреймворки Java - это своего рода боль, в Java отсутствует REPL, в Java есть отдельный этап компиляции ... Java также имеет статическую типизацию; вы можете целый день спорить о преимуществах динамической печати по сравнению сстатическая типизация, но и Rails, и Django используют возможности набора текста и самоанализа Ruby и Python, чтобы сделать большую часть кода менее многословной, чем код Java. (Делает ли это Ruby и Python лучше , чем Java, - это субъективно.)
А что касается Python (а также PHP), каково оправдание их существования? Во-первых, Python интерпретируется намного медленнее, чем, скажем, C ++. Почему веб-сайты написаны на Python или PHP - здесь единственная проблема - независимость от платформы. Мне не верится, что разработка приложений на Python происходит намного быстрее, чем на C ++ (помимо проблемы со сборкой мусора - это то, что является основной причиной для Python -сборка мусора.)
Производительность - это еще не все. Почти все хотят думать, что их код критичен к производительности, но часто это не так. Как отмечалось в нескольких других ответах, большинство веб-приложений в любом случае связаны с вводом-выводом - они либо ждут доступа к базе данных, либо ждут в сети, и оба этих типа операций на порядки медленнее, чем с интенсивным использованием ЦП. задачи, даже с медленно интерпретируемыми языками. Кроме того, большая часть обработки в веб-приложениях происходит со строками, и обработка строк намного лучше в Python или Ruby, чем, например, в C или C ++. Python и Ruby также являются более лаконичными языками, и оба предлагают REPL, который может сократить время разработки. Кроме того, легко писать модули расширения C как в Python, так и в Ruby, поэтому, если вы действительно действительно найдете путь кода, требующий оптимизации, вы всегда можете перейти к C, если хотите.
Однако сборка мусора - это плюс.
И я раньше думал, что html может быть аналогом ассемблера, так что обычный разработчик приложений прошлых лет мог знать и иногда даже использовать немного ассемблера, но в целом почти никогда им не пользовался, тогда как, насколько я вижу, html (а также CSS и javascript) по-прежнему должен быть освоен и постоянно написан каждым веб-разработчиком, независимо от того, используют ли они Django или что-то другое. Это верное утверждение?
Вот почему я использую Seaside. Вам все равно придется разбираться в html, css и javascript, но по крайней мере есть абстракция языка программирования над html. Я никогда не вернусь к системе, основанной на шаблонах.