Как то с ребенком занимались визуальным программированием для лего mindstorm. Простые вещи — да, наглядно. Любое усложнение алгоритма — ад. Никогда больше!
Идея здравая (избавиться от лишней философии). Но институт - место довольно инерционное. Если бекенд ещё худо-бедно устаканился, то фронт - настоящие безумие: смена парадигм в реакте, вю тоже поменялся с КомпозишнАПИ. МодульФедерейшеном можно не только детей пугать, но и взрослых. ИТ довольно подвижный сектор - в юности нам давали паскаль и бейсик. Где они сейчас? Хорошо, если сейчас в институте дают ПХП и jQuery. За мою жизнь только Си и С++ более-менее остались в ходу.
Это математику преподавали тучу лет - всё отточили в процессе. А тут разброд и шатание. Помните, когда все поголовно бросились в ООП? Джаву придумали (ненавижу её всеми фибрами души из-за web-apps). Потом решили, что можно и простых функций добавить - и вот есть Котлин. Перл взлетел на заре веба, и так же канул в лету.
Я к тому, что не так просто выбрать стек технологий, чтобы было и устойчиво, и модерново.
NoCode - как швейцарский нож: всё есть, компактно, симпатично, но все пользуются нормальными отвёртками, ножами и прочим инструментом.
У меня вопрос больше стратегический. Написали быстро прототип, используя кубики конструктора. Нужен свой кубик - ждём, пока его сделают, или сами пишем код. Получается, надо знать экосистему Конструктора, и заодно и Кодировать (например, js, css, html, react). Получается, чтобы развивать прототип, надо уметь кодить.
И давайте на чистоту, сами принципы программирования несложные: циклы, условные переходы, переменные-массивы-структуры. Ну заменили мы условие IF на визуальный кубик - мы же не упростили логику, она осталась. Так же как ORM не отменяет требований к знаниям того, как работает база данных и SQL.
Чем NoCode отличается от использования всяких фреймворков и UI китов? Точно так же набрали компонент и связываем их. Чуть сложнее на старте - гораздо гибче и производительнее в будущем.
Да можно и на беке всё решить, конечно. Будет кусок html с расставленными креслами в зале(зелеными и красными), кол-вом билетов и общей ценой с учётом скидки, попкорна и пр.
Есть несколько actions /add-booking-number?params=, /cancel-booking-number?params= и так далее. Но всегда возвращается целый кусок html с залом, ценой и т.д. Получается, что на любой запрос вы замещаете условный <div id="hall">...</div> - этот div и будет являться target-ом всегда.
Конечно, трафика будет больше, чем получить короткий json. На сервере будет сессия, time-zone, вычисления стоимости и рендер html. Будет ли работать? - Да. Изящно ли это? - Ну, это зависит...
Но если стоит задача сделать трейдинг-клиента, то тут, конечно, лучше сразу взять условный vue.
Статья о том, как с помощью названия путей на диске без единой строчки кода объяснить "чистую" архитектуру. Автор просто увеличивает энтропию вселенной используя слова Энтити, Домен, Сервис...
История хорошая. Но каким же фронт стал многословным и сложным за последние 10 лет. Mantine выглдяит симпатично. Интересно сколько от него в итоге Вы взяли? Нет ли ситуации, что Кит начинает слишком сильно направлять дизайн-мысль фронт-эндера?
И может быть, в процессе поиска, Вам попадались лаконичные, лёгкие UI киты?
Ладно БМВ на Хабре, но Гучи с Витоном? Что синьоры, выкатили код в продакшн и сразу в ЦУМ за чемоданом Louis! ;-)
Выводы в статье странные: не покупателей же измеряли. А надо было набрать крашеных блондинок на Лабутенах и Франциско Гойя показывать. Да и что показывать, тоже вопрос: Обнажённую Маха или Расстрел мадридских повстанцев?
Давайте уж лучше про тачки... Релевантнее к аудитории
В последнее время наблюдаю поворот "обратно к истокам", когда начинают ругать чрезмерный ООП подход, большую иерархию классов и over-engineering. Вон, новый-модный Rust без классов и наследования живёт и многим нравится.
Но нужен опыт. Пусть у нас есть Заказ и телефон. И нам потребовался добавить ещё один телефон.
И можно к полю user_phone добавить что-то вроде user_phone_alt и все.
А можно по-взрослому: делать список, в базе 1-ко-многим, динамическую форму с кнопками "добавить доп. телефон", "убрать телефон"...
Вообще, мы слишком разбалованы. На телефоне с небольшим экраном играет видео, а нам ещё картинку-в-картинке подавай! И спасибо за разъяснение мелочей во флаттер.
Это хорошая новость. А что для интерфейса будете использовать?
Как то с ребенком занимались визуальным программированием для лего mindstorm. Простые вещи — да, наглядно. Любое усложнение алгоритма — ад. Никогда больше!
Шикарная статья, спасибо! Хабр торт!
Идея здравая (избавиться от лишней философии). Но институт - место довольно инерционное. Если бекенд ещё худо-бедно устаканился, то фронт - настоящие безумие: смена парадигм в реакте, вю тоже поменялся с КомпозишнАПИ. МодульФедерейшеном можно не только детей пугать, но и взрослых. ИТ довольно подвижный сектор - в юности нам давали паскаль и бейсик. Где они сейчас? Хорошо, если сейчас в институте дают ПХП и jQuery. За мою жизнь только Си и С++ более-менее остались в ходу.
Это математику преподавали тучу лет - всё отточили в процессе. А тут разброд и шатание. Помните, когда все поголовно бросились в ООП? Джаву придумали (ненавижу её всеми фибрами души из-за web-apps). Потом решили, что можно и простых функций добавить - и вот есть Котлин. Перл взлетел на заре веба, и так же канул в лету.
Я к тому, что не так просто выбрать стек технологий, чтобы было и устойчиво, и модерново.
Flutter хотя бы компилит в a-la натив, пусть и используя свой GUI-движок. Котлин тоже компилит в байт код, как и Java.
А RN делает код, который запускает web-view, который запускает JS run-time совместно с JIT, и у нас 1 гб для мессенджера. Супер!
А, ну так вызов нативной api-шной кнопки через bridge всё же не полность. нативное приложение.
NoCode - как швейцарский нож: всё есть, компактно, симпатично, но все пользуются нормальными отвёртками, ножами и прочим инструментом.
У меня вопрос больше стратегический. Написали быстро прототип, используя кубики конструктора. Нужен свой кубик - ждём, пока его сделают, или сами пишем код. Получается, надо знать экосистему Конструктора, и заодно и Кодировать (например, js, css, html, react). Получается, чтобы развивать прототип, надо уметь кодить.
И давайте на чистоту, сами принципы программирования несложные: циклы, условные переходы, переменные-массивы-структуры. Ну заменили мы условие IF на визуальный кубик - мы же не упростили логику, она осталась. Так же как ORM не отменяет требований к знаниям того, как работает база данных и SQL.
Чем NoCode отличается от использования всяких фреймворков и UI китов? Точно так же набрали компонент и связываем их. Чуть сложнее на старте - гораздо гибче и производительнее в будущем.
Как это? С какого момента RN стал компилировать в натив?
А мне понравилось. Просто, понятно, легко подправить под себя. Можно поворчать на отсутствие doc-string, но в принципе, и так всё понятно. Спасибо!
Хорошие примеры с миграциями. Они часто могут подкинуть сюрпризов, да!
Да можно и на беке всё решить, конечно. Будет кусок html с расставленными креслами в зале(зелеными и красными), кол-вом билетов и общей ценой с учётом скидки, попкорна и пр.
Есть несколько actions /add-booking-number?params=, /cancel-booking-number?params= и так далее. Но всегда возвращается целый кусок html с залом, ценой и т.д. Получается, что на любой запрос вы замещаете условный <div id="hall">...</div> - этот div и будет являться target-ом всегда.
Конечно, трафика будет больше, чем получить короткий json. На сервере будет сессия, time-zone, вычисления стоимости и рендер html. Будет ли работать? - Да. Изящно ли это? - Ну, это зависит...
Но если стоит задача сделать трейдинг-клиента, то тут, конечно, лучше сразу взять условный vue.
Да кто ж спорит - даже конвертор валют с двух-сторонним по валютам связыванием удобнее писать на vue.
Htmx удобен не для приложений, а для сайтов, где обратная связь, квиз, форма опроса и прочие несложные вещи.
Статья о том, как с помощью названия путей на диске без единой строчки кода объяснить "чистую" архитектуру. Автор просто увеличивает энтропию вселенной используя слова Энтити, Домен, Сервис...
Спасибо!
История хорошая. Но каким же фронт стал многословным и сложным за последние 10 лет. Mantine выглдяит симпатично. Интересно сколько от него в итоге Вы взяли? Нет ли ситуации, что Кит начинает слишком сильно направлять дизайн-мысль фронт-эндера?
И может быть, в процессе поиска, Вам попадались лаконичные, лёгкие UI киты?
Ладно БМВ на Хабре, но Гучи с Витоном? Что синьоры, выкатили код в продакшн и сразу в ЦУМ за чемоданом Louis! ;-)
Выводы в статье странные: не покупателей же измеряли. А надо было набрать крашеных блондинок на Лабутенах и Франциско Гойя показывать. Да и что показывать, тоже вопрос: Обнажённую Маха или Расстрел мадридских повстанцев?
Давайте уж лучше про тачки... Релевантнее к аудитории
Какое шикарное сравнение!
В последнее время наблюдаю поворот "обратно к истокам", когда начинают ругать чрезмерный ООП подход, большую иерархию классов и over-engineering. Вон, новый-модный Rust без классов и наследования живёт и многим нравится.
Но нужен опыт. Пусть у нас есть Заказ и телефон. И нам потребовался добавить ещё один телефон.
И можно к полю user_phone добавить что-то вроде user_phone_alt и все.
А можно по-взрослому: делать список, в базе 1-ко-многим, динамическую форму с кнопками "добавить доп. телефон", "убрать телефон"...
Кто какой подход выберет? Чем обоснуете?
Вообще, мы слишком разбалованы. На телефоне с небольшим экраном играет видео, а нам ещё картинку-в-картинке подавай! И спасибо за разъяснение мелочей во флаттер.
Основательно как! Спасибо!