Но раз Вы отлично знаете JS, тогда приглашаю в паблик, там будут этапы разработки и части кода, когда выпишусь. Аудит со стороны не помешает, мне как раз нужна будет помощь с асинхронными функциями у сервера. Так что Ваш вклад приветствуется :)
Насчёт тейка про менеджемент. Технически это инструмент, строгая типизацая в JS. На языке менеджемента это конституция чистого кода, которая обязывает её следовать. Это не плохо и не хорошо, просто это мотив, зачем такие инструменты создаются.
Опять же, почему правила JavaScript это "проблема плохой типизации"? Типизация JS имеет особенности, которые прописаны в самом движке, это преобразование типов, которое имеет свою логику.
Насчёт Вашей колкой "просьбы" освоить языки со сторогой типизацией, я пробовал, но не втянуло, JS нравится больше. В ответ на Вашу пассивную агрессию предлагаю "попробовать освоить сам JS и Вы удивитесь, как станет лучше, когда вы знаете основы языка")
В любом случае, я заметил, что диалог уходит в вечный спор про holy war типизаций, который не приведёт к значимому результату. Так что предлагаю либо наблюдать за развитием проекта и тем, как используется JS в рамках моего проекта, либо продолжать длинную ветвь комментариев, что я бы счёл неуважением к моим зрителям, которым всё это читать :)
Конечно, TypeScript придумали не просто так, ведь нужно поддерживать единую структуру кода среди разработчиков. В конце концов, Microsoft, как и любая компания, работающая на выгоду, делает подобные вещи не ради всеобщего блага, просто это также инструмент менеджемента, который позволяет использовать статическую типизацию в JS.
Я ничего не имею против TypeScript и тех, кто его использует, просто я считаю динамическую типизацию и его особенности в JS наоборот фичей. Кому-то она мешает, а мне помогает.
Благодарю, тоже никаких претензий, просто отвечаю на вопросы насчёт моего проекта :) (не люблю слово "продукт", убивает душу, словно это товар)
Да, это возвращение в прошлое, но на современных реалиях. Не вижу ничего зазорного в том, чтобы брать лучшее из разных временных эпох, в конце концов это не просто "раньше было лучше", а конкретный собирательный образ из того, что было хорошо, а что можно улучшить)
Тогда это меняет дело. Если тема заходит о языках, то чистый JS в моём движке используется по четырём причинам:
1) браузер понимает на фронте именно нативный чистый JS, все остальные диалекты типо JSX или того, что у Svelte (если Вы имеете в виду их) потом переводятся всё равно в чистый JS через чёрный ящик транспилятора, это посредники. А так есть прямое общение с браузером.
2) Ради большинства диалектов приходится пересобирать проект, потому что, как я сказал выше, это всё равно пережёвывается в нативный JS. Удобно ли писать фронт? Наверное. Удобно ли ждать сборку после каждого изменения? Вряд ли.
3) Каждый фреймворк предлагает отдельный язык для фронта и каждый из них учить. Это в целом странно и если лезть глубже, то это убивает айти рыночек, это делает из программистов одноразовых джунов, которые живут до тех пор, пока живёт фреймворк. Когда фреймворк предлагает свой диалект, человек его учит, тратит месяцы, работает на нём и всё хорошо. Но как только фреймворк устаревает, человек уже не нужен с этими знаниями, почему?.. он учил диалект, а не сам язык, его знания ограничены диалектом, и это не его вина. Поэтому я пишу на чистом JS, так как это будет полезно для тех, кто его освоит. Они будут знать не что-то выдуманное, а сам JS и ООП. Это база.
4) Это самый отличный вариант для контроля и стабильности. Что значит создавать диалект или свой язык? Это: писать транспилятор, писать плагины для известных редакторов кода, писать документацию не к объектам, а к самому языку, это продавать курсы. Для гаражной инженерии с бюджетом в два дошика это на грани возможного. А JS стирает эту грань и позволяет создавать что-угодно из объектов и его методов. В этом прелесть.
Каждый инструмент для своей области задач. Проект не создан, чтобы "убить условный React или NestJS". Зачем его убивать, если он хорош для крупного бизнеса? А вот инструментов для инди и стартапов пока маловато, и использование гигантов это перебор.
Именно так. Для менеджемента и для организации разных отделов команд микросервисы - идеальное решение таких задач. Но в плане работоспособности есть жинзненноважный код и сколько его ни дели, при ошибке базовые функции станут недоступны.
Для того, что я описал, есть практически всё в Интернете - фишка в подходе, всё переписано под единый организм. Можно взять разные детали разных фирм, которые вроде как совместимы, и собрать велосипед. А можно штамповать детали вручную, которые будут идеально подогнаны друг к другу и дадут поставить на свой велосипед реактивный двигатель или пулемёт.
Зачем? Я сделал свой верстак для своих задач, который решает все мои проблемы, и предлагаю чертежи верстака для людей :)
А я предлагаю писать фронт на чистом JS?) У движка есть система компонентов, которая работает на чистом JS, вдохновленная подходом jQuery, в будущем планируется добавить и реактивный подход.
Благодаря тому, что компоненты можно компоновать на сервере через файлы *.comp.js, можно сделать набор UI-элементов на все случаи жизни. Впрочем, я не против заняться написанием и компонентов для своего движка.
И чистый JS никто не отбирает, и компоненты есть :)
Я сейчас просмотрел технологии, которые вы приводите в пример. Это здорово, что в Svelte рендерят из AST и обратно, но причём тут сам JS? Это же фактически его диалект и надстройка. Это не компилятор самого JS, а транспилятор - перевод из диалекта в классический. Это не делает его компилируемым.
Что насчёт Вашего аргумента про гугол и Lighthouse.. То есть вы по сути подтвердили мои слова, что вы имели в виду JIT-компиляцию?Ведь благодаря ей JS и можно использовать как интерпретируемый язык. В рантайме Bun, который я использую, JIT есть, так что с оптимизацией проблем не будет.
Всё, что не лезет в сам рантайм JS или его движок работы, а делает что-то поверх - это надстройка и синтаксический сахар.
Насчёт Apache, опять говорю, я не идеализирую, я четко в тексте написал "Да, раньше технологии были не ахти, но по сравнению с современностью это эталон удобства и оптимизации". Я и так знаю, что раньше было очень много уязвимостей, даже у того же самого PHP их очень много, что активно используется в CTF. Это и есть цель моего проекта - исправить эти ошибки. Не стоит предъявлять за то, что я не говорил. :)
Также я заметил, что суть диалога ушла в другую сторону, которая не приводит ни к чему, кроме соревнований в знаниях. Так что давайте определимся. Если ваша цель - развести демагогию за терминологию, является ли JS компилируемым или интерпретируемым языком - тема интересная, почему бы и нет, узнаю новое. Если ваша цель связана с обсуждением непосредственно движка, то милости прошу следить за разработкой, ваш опыт будет очень ценным для нового инструмента.
Я и не говорю ничего против компиляторов в компилируемых языках, но речь про JavaScript. То, что вы называете "компиляцией" в JS (возможно, можете подробнее указать) - это называется транспиляция (или же минификация), это просто сжатие кода. Если вы имеете в виду JIT, то он по умолчанию есть в рантайме.
Главная проблема подхода компиляторов (транспиляторов) в JS в том, что это не компилируемый язык, а интерпретируемый. Он не создан для компиляции, можно потратить время на сборку, но это его не ускорит, потому что JS интерпретируемый.
Что насчёт сканеров уязвимостей.. А смысл от того, файловый это роутинг или прописанный через фильтры, если факт один - открыто N-ое кол-во URL, при том, что они заранее неизвестны? Если сканер уязвимостей умудрился прочитать содержание директорий, то это означает, что сервер дырявый, у которого не прописали одну строчку в конфиге - запретить просмотр директорий. Это проблема не подхода, а некомпетентности, когда сисдамин не додумался до "Options -Indexes".
Спасибо за ответ. Отличная фраза: "идеалистическое представление о раннем вебе", это станет отличным лозунгом моего проекта. Как я ниже описал, ранний веб был очень удобен, хоть и "имел недостатки", то есть я их не отрицаю. Но такие вещи, как файловый роутинг мне нравились, где я видел эндпоинты API без открытия кода наглядно и без вставок функций. К этому и стремимся - чтобы идеалистическое представление стало реальностью.
Насчёт конфигов, я против больших конфигов не потому что их компилятор пережуёт, а потом что их почему-то пережёвывает человек. Очевидно, многие части можно сократить или автоматизировать, поменяв структуру или связав это с сервером.
Что насчёт компилятора, я могу сказать только одно: если вместо отказа от компилятора в динамичном (!) вебе он защищается тейком "компилятор умный, сам вырежет всё, что не надо и оставит что надо", то компилятор уже Вас победил, и я предлагаю решение этого в данной статье.
В отличии от компиляторов, которые пишут про "tree-shaking", а что от чего зависит - это чёрный ящик, мой инструмент даёт Вам контроль над тем, что сервер пережёвывает. И это не потому что я так заявил, а потому что инструмент изначально создан без нужды компилировать. Вся минификация и оптимизация происходит внутри движка и держится под капотом.
Так что если Вам может стать интересен такой опыт, то по ссылкам ниже буду параллельно вести дневники разработки. С учётом того, что я сейчас начинаю ремейк на Bun, вы сможете предложить свои идеи для улучшения инструмента. :)
Этап момента, когда вместо дизайна нам подают выжиику, звучит интересно, однако пока нейросети глючат, до этого этапа далековато.
А также не забываем, что маркетологам и рекламщикам тоже нужно поработать, так что даже на этапе выжимки какая-нибудь реклама да будет внедряться. Уже были проекты, которые буквально вмонитровали в фильмы рекламную интеграцию, как будто она так снята и была, и скорее всего, такое будущее будет ближе, так как оно выгоднее для индустрии.
Но в целом концепт интересный. В нём есть отличный потенциал, но его убъют рекламщики, а базовые пользователи захотят цветастых картинок.
Так что я думаю, этот концепт будет отличной идеей для определённой области, где из поиска информации можно выжать максимум
Это и необходимо предотвратить. Мы живём в мире, где мало сделать хорошо, нужно ещё "показать". Но это и не повод останавливаться.
Многие технологии создаются одиночками, кто-то получает известность, кто-то нет, а кто-то продал своё авторство корпорациям.
Для начала стоит поразмышлять о своём проекте и спросить самого себя "Чем проект лучше аналогов и есть ли у него аналоги? Какие проблемы решает? Что может предложить?". Если на эти вопросы удалось найти ответ, значит всё хорошо, это та самая этикетка продукта, которая привлекает покупателей на полке.
Если же ответа нет, то его надо придумать. Инновации и уникальность - это то, что нельзя купить или получить по щелчку пальца, как вдохновение или идея. Невозможно победить корпоратов на их поле, где у них безграничные деньги и юристы.
Если же это буквально "продукт", то тогда нужно выбрать те параметры, которые ты сможешь улучшить или уже улучшил по сравнению с аналогами и указывать именно на эти преимущества.
Я очень рад, что в коммьюнити есть люди, которые пытаются решать проблемы самостоятельно, это радует.
Не стоит забрасывать, фронтенд-библиотека без лишних компиляций очень нужна. Особенно когда можно совместить jQuery и React стили. Я надеюсь, проект получится отличный :)
Потому что я пишу на классическом JS, я считаю, что чистый код можно писать где угодно. Что насчёт того, что кроме mvp нет репозитория, потому что проект на стадии разработки.
Суть: показать концепт, закрепить, что вот придумал такую вещь, собрал рабочий прототип и дальше дело за разработкой.
Зачем заходить в телегу? Застать всё это с самого начала. Моя цель не "продать", а "показать", я за аудит. И может, именно вы заметите в ядре уязвимость, которую удастся устранить
В этом и суть моего движка, что его не надо собирать. Он делает то, что забросили с десяток лет назад - берёт концепцию динамического веба, где ты буквально редачишь файл и он изменяется в реальном времени.
Спасибо за ответ, согласен. Отсылку на Линуса выкупил, статья вышла раньше, чем я ожидал.
Специально к релизу готовил начать работу над ремейков на Bun, где буду публиковать код. Так что ваш социальный аудит будет с самого зарождения. Именно так получится устранить все баги в зачатке.
Вот и отлично, тогда расходимся :)
Но раз Вы отлично знаете JS, тогда приглашаю в паблик, там будут этапы разработки и части кода, когда выпишусь. Аудит со стороны не помешает, мне как раз нужна будет помощь с асинхронными функциями у сервера. Так что Ваш вклад приветствуется :)
Насчёт тейка про менеджемент. Технически это инструмент, строгая типизацая в JS. На языке менеджемента это конституция чистого кода, которая обязывает её следовать. Это не плохо и не хорошо, просто это мотив, зачем такие инструменты создаются.
Опять же, почему правила JavaScript это "проблема плохой типизации"? Типизация JS имеет особенности, которые прописаны в самом движке, это преобразование типов, которое имеет свою логику.
Насчёт Вашей колкой "просьбы" освоить языки со сторогой типизацией, я пробовал, но не втянуло, JS нравится больше. В ответ на Вашу пассивную агрессию предлагаю "попробовать освоить сам JS и Вы удивитесь, как станет лучше, когда вы знаете основы языка")
В любом случае, я заметил, что диалог уходит в вечный спор про holy war типизаций, который не приведёт к значимому результату. Так что предлагаю либо наблюдать за развитием проекта и тем, как используется JS в рамках моего проекта, либо продолжать длинную ветвь комментариев, что я бы счёл неуважением к моим зрителям, которым всё это читать :)
Конечно, TypeScript придумали не просто так, ведь нужно поддерживать единую структуру кода среди разработчиков. В конце концов, Microsoft, как и любая компания, работающая на выгоду, делает подобные вещи не ради всеобщего блага, просто это также инструмент менеджемента, который позволяет использовать статическую типизацию в JS.
Я ничего не имею против TypeScript и тех, кто его использует, просто я считаю динамическую типизацию и его особенности в JS наоборот фичей. Кому-то она мешает, а мне помогает.
Благодарю, тоже никаких претензий, просто отвечаю на вопросы насчёт моего проекта :) (не люблю слово "продукт", убивает душу, словно это товар)
Да, это возвращение в прошлое, но на современных реалиях. Не вижу ничего зазорного в том, чтобы брать лучшее из разных временных эпох, в конце концов это не просто "раньше было лучше", а конкретный собирательный образ из того, что было хорошо, а что можно улучшить)
Тогда это меняет дело. Если тема заходит о языках, то чистый JS в моём движке используется по четырём причинам:
1) браузер понимает на фронте именно нативный чистый JS, все остальные диалекты типо JSX или того, что у Svelte (если Вы имеете в виду их) потом переводятся всё равно в чистый JS через чёрный ящик транспилятора, это посредники. А так есть прямое общение с браузером.
2) Ради большинства диалектов приходится пересобирать проект, потому что, как я сказал выше, это всё равно пережёвывается в нативный JS. Удобно ли писать фронт? Наверное. Удобно ли ждать сборку после каждого изменения? Вряд ли.
3) Каждый фреймворк предлагает отдельный язык для фронта и каждый из них учить. Это в целом странно и если лезть глубже, то это убивает айти рыночек, это делает из программистов одноразовых джунов, которые живут до тех пор, пока живёт фреймворк. Когда фреймворк предлагает свой диалект, человек его учит, тратит месяцы, работает на нём и всё хорошо. Но как только фреймворк устаревает, человек уже не нужен с этими знаниями, почему?.. он учил диалект, а не сам язык, его знания ограничены диалектом, и это не его вина. Поэтому я пишу на чистом JS, так как это будет полезно для тех, кто его освоит. Они будут знать не что-то выдуманное, а сам JS и ООП. Это база.
4) Это самый отличный вариант для контроля и стабильности. Что значит создавать диалект или свой язык? Это: писать транспилятор, писать плагины для известных редакторов кода, писать документацию не к объектам, а к самому языку, это продавать курсы. Для гаражной инженерии с бюджетом в два дошика это на грани возможного. А JS стирает эту грань и позволяет создавать что-угодно из объектов и его методов. В этом прелесть.
Правильный ход мыслей :)
Каждый инструмент для своей области задач. Проект не создан, чтобы "убить условный React или NestJS". Зачем его убивать, если он хорош для крупного бизнеса? А вот инструментов для инди и стартапов пока маловато, и использование гигантов это перебор.
Именно так. Для менеджемента и для организации разных отделов команд микросервисы - идеальное решение таких задач. Но в плане работоспособности есть жинзненноважный код и сколько его ни дели, при ошибке базовые функции станут недоступны.
Для того, что я описал, есть практически всё в Интернете - фишка в подходе, всё переписано под единый организм. Можно взять разные детали разных фирм, которые вроде как совместимы, и собрать велосипед. А можно штамповать детали вручную, которые будут идеально подогнаны друг к другу и дадут поставить на свой велосипед реактивный двигатель или пулемёт.
Зачем? Я сделал свой верстак для своих задач, который решает все мои проблемы, и предлагаю чертежи верстака для людей :)
А я предлагаю писать фронт на чистом JS?) У движка есть система компонентов, которая работает на чистом JS, вдохновленная подходом jQuery, в будущем планируется добавить и реактивный подход.
Благодаря тому, что компоненты можно компоновать на сервере через файлы *.comp.js, можно сделать набор UI-элементов на все случаи жизни. Впрочем, я не против заняться написанием и компонентов для своего движка.
И чистый JS никто не отбирает, и компоненты есть :)
Я сейчас просмотрел технологии, которые вы приводите в пример. Это здорово, что в Svelte рендерят из AST и обратно, но причём тут сам JS? Это же фактически его диалект и надстройка. Это не компилятор самого JS, а транспилятор - перевод из диалекта в классический. Это не делает его компилируемым.
Что насчёт Вашего аргумента про гугол и Lighthouse.. То есть вы по сути подтвердили мои слова, что вы имели в виду JIT-компиляцию?Ведь благодаря ей JS и можно использовать как интерпретируемый язык. В рантайме Bun, который я использую, JIT есть, так что с оптимизацией проблем не будет.
Всё, что не лезет в сам рантайм JS или его движок работы, а делает что-то поверх - это надстройка и синтаксический сахар.
Насчёт Apache, опять говорю, я не идеализирую, я четко в тексте написал "Да, раньше технологии были не ахти, но по сравнению с современностью это эталон удобства и оптимизации". Я и так знаю, что раньше было очень много уязвимостей, даже у того же самого PHP их очень много, что активно используется в CTF. Это и есть цель моего проекта - исправить эти ошибки. Не стоит предъявлять за то, что я не говорил. :)
Также я заметил, что суть диалога ушла в другую сторону, которая не приводит ни к чему, кроме соревнований в знаниях. Так что давайте определимся. Если ваша цель - развести демагогию за терминологию, является ли JS компилируемым или интерпретируемым языком - тема интересная, почему бы и нет, узнаю новое. Если ваша цель связана с обсуждением непосредственно движка, то милости прошу следить за разработкой, ваш опыт будет очень ценным для нового инструмента.
Благодарю за понимание :)
Я и не говорю ничего против компиляторов в компилируемых языках, но речь про JavaScript. То, что вы называете "компиляцией" в JS (возможно, можете подробнее указать) - это называется транспиляция (или же минификация), это просто сжатие кода. Если вы имеете в виду JIT, то он по умолчанию есть в рантайме.
Главная проблема подхода компиляторов (транспиляторов) в JS в том, что это не компилируемый язык, а интерпретируемый. Он не создан для компиляции, можно потратить время на сборку, но это его не ускорит, потому что JS интерпретируемый.
Что насчёт сканеров уязвимостей.. А смысл от того, файловый это роутинг или прописанный через фильтры, если факт один - открыто N-ое кол-во URL, при том, что они заранее неизвестны? Если сканер уязвимостей умудрился прочитать содержание директорий, то это означает, что сервер дырявый, у которого не прописали одну строчку в конфиге - запретить просмотр директорий. Это проблема не подхода, а некомпетентности, когда сисдамин не додумался до "Options -Indexes".
Спасибо за ответ. Отличная фраза: "идеалистическое представление о раннем вебе", это станет отличным лозунгом моего проекта. Как я ниже описал, ранний веб был очень удобен, хоть и "имел недостатки", то есть я их не отрицаю. Но такие вещи, как файловый роутинг мне нравились, где я видел эндпоинты API без открытия кода наглядно и без вставок функций. К этому и стремимся - чтобы идеалистическое представление стало реальностью.
Насчёт конфигов, я против больших конфигов не потому что их компилятор пережуёт, а потом что их почему-то пережёвывает человек. Очевидно, многие части можно сократить или автоматизировать, поменяв структуру или связав это с сервером.
Что насчёт компилятора, я могу сказать только одно: если вместо отказа от компилятора в динамичном (!) вебе он защищается тейком "компилятор умный, сам вырежет всё, что не надо и оставит что надо", то компилятор уже Вас победил, и я предлагаю решение этого в данной статье.
В отличии от компиляторов, которые пишут про "tree-shaking", а что от чего зависит - это чёрный ящик, мой инструмент даёт Вам контроль над тем, что сервер пережёвывает. И это не потому что я так заявил, а потому что инструмент изначально создан без нужды компилировать. Вся минификация и оптимизация происходит внутри движка и держится под капотом.
Так что если Вам может стать интересен такой опыт, то по ссылкам ниже буду параллельно вести дневники разработки. С учётом того, что я сейчас начинаю ремейк на Bun, вы сможете предложить свои идеи для улучшения инструмента. :)
Спасибо за ответ, интересный взгляд на будущее.
Этап момента, когда вместо дизайна нам подают выжиику, звучит интересно, однако пока нейросети глючат, до этого этапа далековато.
А также не забываем, что маркетологам и рекламщикам тоже нужно поработать, так что даже на этапе выжимки какая-нибудь реклама да будет внедряться. Уже были проекты, которые буквально вмонитровали в фильмы рекламную интеграцию, как будто она так снята и была, и скорее всего, такое будущее будет ближе, так как оно выгоднее для индустрии.
Но в целом концепт интересный. В нём есть отличный потенциал, но его убъют рекламщики, а базовые пользователи захотят цветастых картинок.
Так что я думаю, этот концепт будет отличной идеей для определённой области, где из поиска информации можно выжать максимум
Это и необходимо предотвратить. Мы живём в мире, где мало сделать хорошо, нужно ещё "показать". Но это и не повод останавливаться.
Многие технологии создаются одиночками, кто-то получает известность, кто-то нет, а кто-то продал своё авторство корпорациям.
Для начала стоит поразмышлять о своём проекте и спросить самого себя "Чем проект лучше аналогов и есть ли у него аналоги? Какие проблемы решает? Что может предложить?". Если на эти вопросы удалось найти ответ, значит всё хорошо, это та самая этикетка продукта, которая привлекает покупателей на полке.
Если же ответа нет, то его надо придумать. Инновации и уникальность - это то, что нельзя купить или получить по щелчку пальца, как вдохновение или идея. Невозможно победить корпоратов на их поле, где у них безграничные деньги и юристы.
Если же это буквально "продукт", то тогда нужно выбрать те параметры, которые ты сможешь улучшить или уже улучшил по сравнению с аналогами и указывать именно на эти преимущества.
Главное не бросайте дело :)
Спасибо за ответ
В этом и секрет, совместимость с nodejs в основном нужна для npm пакетов, но когда у проекта цель - минимум зависимостей, но это минимизирует риски
Благодарю за ответ. Это очень искренне
Я очень рад, что в коммьюнити есть люди, которые пытаются решать проблемы самостоятельно, это радует.
Не стоит забрасывать, фронтенд-библиотека без лишних компиляций очень нужна. Особенно когда можно совместить jQuery и React стили. Я надеюсь, проект получится отличный :)
Спасибо за вопрос, в этом и прикол, чтобы настройка проекта занимала либо один файл (как htaccess), либо пару строк в туториале.
Самоуверенность да, есть такое
Спасибо за ответ!
Потому что я пишу на классическом JS, я считаю, что чистый код можно писать где угодно. Что насчёт того, что кроме mvp нет репозитория, потому что проект на стадии разработки.
Суть: показать концепт, закрепить, что вот придумал такую вещь, собрал рабочий прототип и дальше дело за разработкой.
Зачем заходить в телегу? Застать всё это с самого начала. Моя цель не "продать", а "показать", я за аудит. И может, именно вы заметите в ядре уязвимость, которую удастся устранить
В этом и суть моего движка, что его не надо собирать. Он делает то, что забросили с десяток лет назад - берёт концепцию динамического веба, где ты буквально редачишь файл и он изменяется в реальном времени.
Спасибо за ответ, согласен. Отсылку на Линуса выкупил, статья вышла раньше, чем я ожидал.
Специально к релизу готовил начать работу над ремейков на Bun, где буду публиковать код. Так что ваш социальный аудит будет с самого зарождения. Именно так получится устранить все баги в зачатке.