Увы, не соглашусь, на самом деле, по сложности – одинаково.
На C# можно ходить в базу через ODBC, это практически так же просто, как и через PDO.
Хотя, на php можно еще и через MySQLi и подобные ходить, но это не лучший способ.
Использовать какие-нибудь Query Builders? Да без проблем как в php так и в C# такого треша валом. ORM? – тоже и там и там есть несколько реализаций.
Проще только от того, что меньше статической типизации? – да, соглашусь, тут проще немного, но на самом деле это не существенная разница.
С нодой, все так же. Да и с Java все так же обстоит.
Если смотреть на JS, как на DSL для браузера, – согласен, порог вхождения минимальные. Изучил jQuery и уже можешь что-то полезное писать.
Но если взять более современные подходы к JS, с нодой, бабелем, npm и прочими – это ничем не проще того же C# с его NuGet, ASP.NET и WebApi.
А если смотреть на JS, как на платформу для бекенда – то тут тем более не будет проще. Нужно все те же знания по базам данных, по архитектуре бекенда и т.д.
Что мешает написать фреймворк на C#? Ну кроме того, что все уже и так написано ;-)
Видать давно вы не начинали изучать C# с нуля :-)
Сейчас в нем так много синтаксического сахара, что этому может даже JS позавидовать)))
одна интегрированная среда разработки
VisualStudio, VisualStudioCode, MonoDevelop, IDE для Unity3D, JetBrains Ride
один популярный фреймворк
.NET + ASP.NET, .NET Core + ASP.NET Core, Unity3D, Xamarin, – и это только те, которые на слуху у человека не из мира .NET)
Притом под ASP там еще есть: WebForms, WebAPI, etc., а под сам .NET: WPF, WCF, WTF =)
один источник документации
MSDN – довольно плохой источник информации или вы все же про StackOverflow?)))
Справедливости ради, стоит отметить, что тут идет не правильное сравнения.
Вы в данном случае сравниваете JS, как DSL для браузера с языком общего назначения, на котором в принципе можно написать браузер))
Для примера: Сколько будет времени написать бухгалтерскую программу на 1C и сколько на JS?
какие вещи в C# делают порог вхождения для новичков высоким?
Ограничения со стороны языка и платформы, чем больше ограничений тем лучше будет код,
но для начинающего специалиста это кажется не понятным: «почему я не могу сделать так?», «почему все так сложно?»
Обилие языковых фич. Чем больше фич в языке, тем сложнее новичку в нем разобраться.
Чем больше возможностей сделать одно и то же, тем сложнее будет проект для понимания и поддержки.
Linq – удобная штука, но «писать на SQL, пока ты пишешь на C#» – это пенальти для понимания кода.
Специфичный ООП, у класса может быть 2 метода с одинаковой сигнатурой, один для класса, другой для интерфейса, и какой из этих методов будет вызван зависит от того, какой тип переменной используется.
ps: Если изучаешь язык по мере его развития, то обилие функционала не кажется таким страшным и каждая новая фича в радость. Но когда язык наращивает сильно много функционала, то новичкам становится очень тяжело его осилить. Это стоит учитывать.
В частности асинхронность — это работа исключительно через Thread Pool
Чем отличается тредпул (из коробки, ака «асинхронность») от пула потоков, которые девелопер будет создавать для «многопоточности»?
по-моему, тут что-то не так с определением, и то, о чем вы говорите, это больше походит на реактивность (но с реактивностью это vintage нас рассудит).
Асинхронность, может быть только в случае, когда не используется CPU, сейчас самый простой пример — это IO-bound операции. Все остальное — это вариации многопоточности.
JavaApplet, как и вся джава – это стандарт, который может быть реализован разными компаниями. Но должен будет пройти сертификацию.
Flash… в целом он тоже стандартизирован и ближе к закату отдали в сообщество.
про Silverlight не могу сказать.
на счет уязвимостей. Уязвимости они не в технологии, они в имплементации, так что WebAssembly не защищен от уязвимостей.
У WebAssembly будет всего 2-3 реализации: под WebKit, под FF и под IE, т.е. от основных игроков рынка.
Но технология перспективная, так что нужно будет дождаться, когда она выйдет в свет в полной мере.
Не согласен. Если у вас есть ровно одно свободное ядро, на котором надо выполнить 1млн операций, то как их не диспетчерезируй, быстрее они этого не выполнятся.
И тут стоит отметить, что в случае с программой, которая создаст несколько реальных потоков – она будет получать больше процессорного времени для выполнения своих задач, чем однопоточная нода.
допустим OS будет диспетчеризировать 9 потоков + 1 поток вашей программы.
В случае с NodeJs, в системе будет всего 10 потоков. И тут, идем интуитивно, из 1 секунды, каждый поток будет выполняться по 100 мс (это не совсем так, потому что приоритеты и т.д.), т.е. NodeJs будет делать полезные действия всего 100 мс в каждой секунде.
В случае с приложением с реальными потоками: допустим у нас будет 20 потоков (9 потоков системы + 1 поток приложения + 10 потоков которые породило приложение).
В этом случае каждый поток будет выполняться по 50 мс в секунду, итого, наше приложение получает уже 550 мс процессорного времени в одну секунду.
И пусть из них дополнительно 20 мс уйдет на планирование (а это очень много!).
Итого, NodeJs будет выполнять полезные дейсвтия 100 мс, железные потоки — (550 — 20) мс.
Но в реальности это выглядит не так эпично, т.к. есть приоритеты потоков, а отбирая квант времени у других подсистем, они будут работать медленнее, что в общем скажется на работе всей системы. Так что в реальности «железные» потоки Будут все де выигрывать, но этот выигрыш будет примерно 150-300% (зависит от многих факторов).
Но NodeJs будет выигрывать на IO операциях, для которых не нужно использовать процессор, и то, если другая система не будет использовать все тот же asyncIO подход =)
1 миллион сложений мой браузер сделал за 25мс. Если этот код разбить на два потока...
Есть закон Амдала, который позволяет расчитать примерный выигрыш от введения нескольких потоков.
Если кратко, то следствие: минимальное время выполнения задачи равно времени выполнения действий которые нельзя распаралелить. Потому, интуитивное «поделить на 2» – не будет работать. И это не говоря про то, что результат от запуска к запуску будет меняться, особенно в браузере, где «постороннего шума» невероятно много.
Я встречал, как кто-то в потоке обработки HTTP запроса создавал тред-пул для выполнения довольно тривиальных действий.
Девелопер действительно постарался, он сделал пул потоков, он хотел как лучше, но упустил из виду то, что придет 100 запросов и он создаст +200 потоков и системе станет очень плохо.
Вы правы на счет того, что все не так просто, как описал 0xd34df00d, но все не совсем так, как вы думаете.
Второй поток надо создать
Обычно, когда готовится многопоточность, используется пул потоков, у которого есть своя очередь задач. Так что потоки создаются только на старте приложения, т.е. это не так дорого, как вы думаете.
А дальше там все еще интереснее: потоки, системный планировщик и прочее, но это тянет на небольшую статью/заметку, так что расписывать в комменте не буду.
И то это всё только при условии, что у нас есть ещё одно свободное процессорное ядро, иначе эти потоки просто встанут в очередь и точно так же выполнятся последовательно, только ещё с накладными расходами на содержание потоков, и всё гарантированно будет работать медленнее.
Тут стоит отметить, что системная диспетчеризация работает быстрее, чем программная. Как минимум, потому, что поток, в котором выполняется программная диспетчеризация так же может исчерпать кварт времени и он будет приостановлен для выполнения другого потока.
Говорить, что это будет Гарантированно медленнее – это поспешные выводы.
ps: Не стоит забывать, что за популярностью JS, NodeJS и асинхронности стоит львиная доля маркетинга и на самом деле далеко не все так красиво, как рассказывают в «рекламе».
pps:
12,5мс (максимальный теоретический выигрыш от параллельности)
А можете предоставить источник? Я так полагаю, вы читали какую-то научную работу на эту тему?
Хороший JS разработчик стоит столько же, сколько и хороший Java разработчик, но введу того, что JS легче изучить, туда сейчас идет очень много людей. Из-за этого специалисты начинающего и среднего уровня стоят довольно дешево.
JS не на много проще, чем Java. Вернее проще в одних моментах и на много сложнее в других. Java сложнее для старта, но в сотни! раз проще для поддержки проекта, если это не уродливый JavaEE, где куча XML.
Многопоточность в Java используется не часто, по крайней мере для WEB. Да, сервера сами по себе многопоточны, но каждый HTTP запрос обрабатывается в одном потоке без взаимодействия с другими. Нужно еще постараться, чтобы выстрелить себе в ногу в этом месте.
Верстальщики, как и JS девелоперы, это же подмножество фронтедщиков или нет?
т.к. Фронтэнд — это все, что связано с клиентской частью приложения, с отображением.
но если в общем это уже зависит от того, какие требования к фронтендщику предьявляют в какой-то конкретной компании, в более крупных — разделяют на 2 должности, в более мелких — это один человек.
Известно, что функция может возвращать значение только через return (а стрелочная может и без него),
и тут назревает логичный вопрос: Если в конце тела функции нету return, то в чем здесь проблема в языке или в том, кто даже основ языка не прочитал?
Есть множество языков, где есть return, но его можно не использовать (php кажется, один из таких, а еще Scala) и есть множество языков, где return отсутствует как таковой (если не ошибаюсь, к ним относится Python).
Во всех этих языках результат последнего действия будет возвращен как результат функции.
Так это не в return дело, а в том что девелопер привык писать на языке, который не использует return.
Если девелопер начинал обучение с более низкоуровневых языков Pascal/C/C++/C#/etc. то ему будет напротив непривычно, что return не используется.
return коварен в Scala, где он при определенных условиях может сделать больше, чем ожидается. Но в JS он ведет себя как в большинстве C-подобных языков.
js, как язык существует уже почти 20 лет (или больше?), но js, как полноценный язык, на котором можно писать больше, чем обработчик onclick, существует всего лет 5-7, ну а js, который уже имеет зачатки для больших проектов (ES2015) и того меньше, – ему всего 2 года.
Но язык и платформа невероятно быстро развиваются. И большим недостатком этого развития является то, что «каждый тянет одеяло на себя» (на фоне этого развития можно стать SuperStar! если успеешь сделать библиотеку, которой все будут пользоваться, такую как jQuery). И теперь давно минувшие «браузерные войны» превратились в «войны фреймворков».
К тому же стоит смотреть на историю развития: сначала Прототипное ООП продвигалось, как лучшее в мире, потом пришли Классы, которые невзлюбили те, что освоили прототипное, а теперь и вовсе хайп на стороне функционального js.
Ах, еще JSX появился, который позволяет писать на js внутри html пока пишешь на js, который тоже не все любят.
– Это все ведет к разделению сообщества на множество мелких юзергрупп, каждая из которых проповедует свою истину и не сильно любит чужую.
ps: А хайп девелопмент очень просто объяснить. Большинство JS девелоперов выросли на фронтендах, где все делается не так просто, как на бекенде, и любая новая библиотека призванная улучшить ситуацию воспринимается на ура.
1. const — слышу о нём почти отовсюду. Но вот незадача — почему все думают что он должен работать точно так же как в С/С++/<вставьте любимый язык>.
Вот только const в ES2015 – работает точно так же как в C/C++/C#/Java: он запрещает изменять ссылку, но не запрещает изменять значения внутри объекта. Изменяемые объекты и коллекции будут работать одинаково – будут изменяться даже если их объявить с const (в java const назвали final, чтобы не давать ожидания, что весь объект будет неизменяемым).
С тем же NodeJS, многие его хаят за то, что он посягает на святая-святых — backend.
На самом деле NodeJs вполне подходит для некоторых задач WEB бекенда.
Тяжелые расчеты или преобразования он сделать не может в силу единого event loop и отсутствия многопоточности, но получить данные из базы или перенаправить запрос куда-то в другой сервис (то, что сейчас многие бекенды делают) – с этой задачей NodeJs справится без проблем. Единственное чего нехватает – flow types, чтобы уменьшить количество тупых ошибок.
На C# можно ходить в базу через ODBC, это практически так же просто, как и через PDO.
Хотя, на php можно еще и через MySQLi и подобные ходить, но это не лучший способ.
Использовать какие-нибудь Query Builders? Да без проблем как в php так и в C# такого треша валом. ORM? – тоже и там и там есть несколько реализаций.
Проще только от того, что меньше статической типизации? – да, соглашусь, тут проще немного, но на самом деле это не существенная разница.
С нодой, все так же. Да и с Java все так же обстоит.
Но если взять более современные подходы к JS, с нодой, бабелем, npm и прочими – это ничем не проще того же C# с его NuGet, ASP.NET и WebApi.
А если смотреть на JS, как на платформу для бекенда – то тут тем более не будет проще. Нужно все те же знания по базам данных, по архитектуре бекенда и т.д.
Что мешает написать фреймворк на C#? Ну кроме того, что все уже и так написано ;-)
Сейчас в нем так много синтаксического сахара, что этому может даже JS позавидовать)))
VisualStudio, VisualStudioCode, MonoDevelop, IDE для Unity3D, JetBrains Ride
.NET + ASP.NET, .NET Core + ASP.NET Core, Unity3D, Xamarin, – и это только те, которые на слуху у человека не из мира .NET)
Притом под ASP там еще есть: WebForms, WebAPI, etc., а под сам .NET: WPF, WCF, WTF =)
MSDN – довольно плохой источник информации или вы все же про StackOverflow?)))
Вы в данном случае сравниваете JS, как DSL для браузера с языком общего назначения, на котором в принципе можно написать браузер))
Для примера: Сколько будет времени написать бухгалтерскую программу на 1C и сколько на JS?
но для начинающего специалиста это кажется не понятным: «почему я не могу сделать так?», «почему все так сложно?»
Чем больше возможностей сделать одно и то же, тем сложнее будет проект для понимания и поддержки.
ps: Если изучаешь язык по мере его развития, то обилие функционала не кажется таким страшным и каждая новая фича в радость. Но когда язык наращивает сильно много функционала, то новичкам становится очень тяжело его осилить. Это стоит учитывать.
по-моему, тут что-то не так с определением, и то, о чем вы говорите, это больше походит на реактивность (но с реактивностью это vintage нас рассудит).
Асинхронность, может быть только в случае, когда не используется CPU, сейчас самый простой пример — это IO-bound операции. Все остальное — это вариации многопоточности.
Flash… в целом он тоже стандартизирован и ближе к закату отдали в сообщество.
про Silverlight не могу сказать.
на счет уязвимостей. Уязвимости они не в технологии, они в имплементации, так что WebAssembly не защищен от уязвимостей.
У WebAssembly будет всего 2-3 реализации: под WebKit, под FF и под IE, т.е. от основных игроков рынка.
Но технология перспективная, так что нужно будет дождаться, когда она выйдет в свет в полной мере.
Был Silverlight, он принимал байткод, — закопали.
Был JavaApplet… — закопали.
кто следущий WebAssembly?
И тут стоит отметить, что в случае с программой, которая создаст несколько реальных потоков – она будет получать больше процессорного времени для выполнения своих задач, чем однопоточная нода.
допустим OS будет диспетчеризировать 9 потоков + 1 поток вашей программы.
В случае с NodeJs, в системе будет всего 10 потоков. И тут, идем интуитивно, из 1 секунды, каждый поток будет выполняться по 100 мс (это не совсем так, потому что приоритеты и т.д.), т.е. NodeJs будет делать полезные действия всего 100 мс в каждой секунде.
В случае с приложением с реальными потоками: допустим у нас будет 20 потоков (9 потоков системы + 1 поток приложения + 10 потоков которые породило приложение).
В этом случае каждый поток будет выполняться по 50 мс в секунду, итого, наше приложение получает уже 550 мс процессорного времени в одну секунду.
И пусть из них дополнительно 20 мс уйдет на планирование (а это очень много!).
Итого, NodeJs будет выполнять полезные дейсвтия 100 мс, железные потоки — (550 — 20) мс.
Но в реальности это выглядит не так эпично, т.к. есть приоритеты потоков, а отбирая квант времени у других подсистем, они будут работать медленнее, что в общем скажется на работе всей системы. Так что в реальности «железные» потоки Будут все де выигрывать, но этот выигрыш будет примерно 150-300% (зависит от многих факторов).
Но NodeJs будет выигрывать на IO операциях, для которых не нужно использовать процессор, и то, если другая система не будет использовать все тот же asyncIO подход =)
Есть закон Амдала, который позволяет расчитать примерный выигрыш от введения нескольких потоков.
Если кратко, то следствие: минимальное время выполнения задачи равно времени выполнения действий которые нельзя распаралелить. Потому, интуитивное «поделить на 2» – не будет работать. И это не говоря про то, что результат от запуска к запуску будет меняться, особенно в браузере, где «постороннего шума» невероятно много.
Девелопер действительно постарался, он сделал пул потоков, он хотел как лучше, но упустил из виду то, что придет 100 запросов и он создаст +200 потоков и системе станет очень плохо.
Но это по большей части исключение из правил.
Обычно, когда готовится многопоточность, используется пул потоков, у которого есть своя очередь задач. Так что потоки создаются только на старте приложения, т.е. это не так дорого, как вы думаете.
А дальше там все еще интереснее: потоки, системный планировщик и прочее, но это тянет на небольшую статью/заметку, так что расписывать в комменте не буду.
Тут стоит отметить, что системная диспетчеризация работает быстрее, чем программная. Как минимум, потому, что поток, в котором выполняется программная диспетчеризация так же может исчерпать кварт времени и он будет приостановлен для выполнения другого потока.
Говорить, что это будет Гарантированно медленнее – это поспешные выводы.
ps: Не стоит забывать, что за популярностью JS, NodeJS и асинхронности стоит львиная доля маркетинга и на самом деле далеко не все так красиво, как рассказывают в «рекламе».
pps:А можете предоставить источник? Я так полагаю, вы читали какую-то научную работу на эту тему?
т.к. Фронтэнд — это все, что связано с клиентской частью приложения, с отображением.
но если в общем это уже зависит от того, какие требования к фронтендщику предьявляют в какой-то конкретной компании, в более крупных — разделяют на 2 должности, в более мелких — это один человек.
и тут назревает логичный вопрос: Если в конце тела функции нету return, то в чем здесь проблема в языке или в том, кто даже основ языка не прочитал?
Во всех этих языках результат последнего действия будет возвращен как результат функции.
Если девелопер начинал обучение с более низкоуровневых языков Pascal/C/C++/C#/etc. то ему будет напротив непривычно, что return не используется.
return коварен в Scala, где он при определенных условиях может сделать больше, чем ожидается. Но в JS он ведет себя как в большинстве C-подобных языков.
Но язык и платформа невероятно быстро развиваются. И большим недостатком этого развития является то, что «каждый тянет одеяло на себя» (на фоне этого развития можно стать SuperStar! если успеешь сделать библиотеку, которой все будут пользоваться, такую как jQuery). И теперь давно минувшие «браузерные войны» превратились в «войны фреймворков».
К тому же стоит смотреть на историю развития: сначала Прототипное ООП продвигалось, как лучшее в мире, потом пришли Классы, которые невзлюбили те, что освоили прототипное, а теперь и вовсе хайп на стороне функционального js.
Ах, еще JSX появился, который позволяет писать на js внутри html пока пишешь на js, который тоже не все любят.
– Это все ведет к разделению сообщества на множество мелких юзергрупп, каждая из которых проповедует свою истину и не сильно любит чужую.
ps: А хайп девелопмент очень просто объяснить. Большинство JS девелоперов выросли на фронтендах, где все делается не так просто, как на бекенде, и любая новая библиотека призванная улучшить ситуацию воспринимается на ура.
Вот только const в ES2015 – работает точно так же как в C/C++/C#/Java: он запрещает изменять ссылку, но не запрещает изменять значения внутри объекта. Изменяемые объекты и коллекции будут работать одинаково – будут изменяться даже если их объявить с const (в java const назвали final, чтобы не давать ожидания, что весь объект будет неизменяемым).
На самом деле NodeJs вполне подходит для некоторых задач WEB бекенда.
Тяжелые расчеты или преобразования он сделать не может в силу единого event loop и отсутствия многопоточности, но получить данные из базы или перенаправить запрос куда-то в другой сервис (то, что сейчас многие бекенды делают) – с этой задачей NodeJs справится без проблем. Единственное чего нехватает – flow types, чтобы уменьшить количество тупых ошибок.