Ваша линия не закрыта. Так что не может иметь fill
. Я думаю, что вы хотите использовать вместо stroke
:
<Line
points={[73, 70, 340, 23, 450, 60, 500, 20]}
stroke="black"
/>
На производительность Javascript действительно влияют два фактора:
Ваш код - самый простой фактор, который можно исправить. По мере разработки оптимизируйте свой код как можно лучше. Легко.
Второе не всегда так просто. У меня было несколько приложений, в которых производительность в одном браузере была превосходной, а в другом - медленнее, чем в грязи. Другие отлично работают по всем направлениям. Лучшее, что вы можете сделать, это протестировать, протестировать, протестировать и снова протестировать. Если вам нужна хорошая статья, перейдите по ссылке:
Это во многом зависит от движка javascript браузера.
В целом, это язык сценариев, поэтому он не будет работать так же хорошо, как C ++ или другой компилируемый язык. Тем не менее, он хорош в том, для чего был предназначен, а именно в управлении веб-страницами.
Ну, это зависит от обстоятельств. С чем вы это сравниваете? Он сильно различается между разными браузерами.
Он может быть действительно хорошо работающим или наоборот, в зависимости от написанного кода.
Вы ДОЛЖНЫ использовать JavaScript для выполнения определенных действий, например, манипулирования dom.
Javascript - БЫСТРЫЙ, если вы используете его правильно. Иначе плохо себя ведет. Например: неограниченный цикл может повесить ваш браузер. (Но браузер спросит вас, остановить ли выполнение)
Выбор того, какие задачи выполнять на клиенте или на сервере, является важным, и эффективность JavaScript как языка - не единственный фактор, который требует
Данные, которые будут обрабатываться на клиенте, должны быть переданы клиенту. Если скрипту не нужна вся информация, которая будет отправлена клиенту, тогда время загрузки страницы пострадает, и операция фильтрации будет выполняться на менее эффективном конце ссылки (т.е. вы будете платить за сеть. время передачи до того, как пользователь получит свою информацию).
Бизнес-правила, выполняемые на клиенте, будут доступны любопытным конечным пользователям.
Бизнес-правила проверки, которые выполняются на клиенте, должны быть снова запущены на сервере,
Вы действительно можете ответить на этот вопрос только в контексте конкретной проблемы. вы пытаетесь решить. Отправьте пример, и тогда мы сможем обсудить достоинства различных технологий ...
Я полагаю, что в большинстве случаев это намного быстрее, чем отправить ответный пост!
Я бы сказал, что это неправильный ответ. Как бы вы измерили производительность JavaScript и что использовали бы для сравнения. Думаю, пока JavaScript является единственным вариантом для веб-программирования на стороне клиента (я не говорю о VBScript), вы не можете ничего сказать о его эффективности.
Также зависит от того, как вы пишете свой код. Если вы будете следовать лучшим практикам, это нормально и, как было сказано ранее, лучше, чем обратная передача!
Javascript не является неэффективным, эффективность не зависит от языка. Переводчики могут быть неэффективными. Например, интерпретатор Firefox работает очень медленно в FF для Linux и намного лучше в FF для Windows. В Chrome реализован интерпретатор, который работает намного быстрее. Есть интерпретаторы Javascript, которые не запускаются в браузере, они обычно работают быстрее.
Я предполагаю, что люди пытаются вам сказать: делайте то, что вы можете на сервере вместо размещения всего кода на стороне клиента.
Производительность Javascript отличается от браузера к другому (или от интерпретатора к другому), но javascript не должен служить тем же целям, что и языки на стороне сервера.
Современные браузеры реализуют все больше и больше своевременной компиляции для своих интерпретаторов.
Мое практическое правило состоит в том, что если вы не можете полагаться на включенный JavaScript, делайте как на сервере сколько можно. Если вы точно знаете, что JavaScript включен, сделайте как можно больше в клиенте, и вы сэкономите на полосе пропускания и нагрузке на сервер.
Я «парень с числами», поэтому, когда кто-то говорит что-то вроде «ну, X медленный» или «конечно, потому что Y быстрый», это действительно меня пугает. Итак, для начала вам нужно использовать реальные данные, если вы собираетесь проводить какую-либо оценку:
JavaScript Performance Rundown
Я также считаю, что наблюдать за Dromaeo в действии - это круто