Как стать автором
Обновить
3
0

Пользователь

Отправить сообщение

Когда начинал переходить на Go, тоже был в восторге, какой простой, понятный язык и для всего есть готовые библиотеки. Но потом оказывается, что за простоту приходится платить и в нем нет многих вещей к которым привык в других языках. Библиотеки на все случаи жизни оказываются не доделаны и многое ещё не реализовано. В итоге пришось написать dll на другом языке, чтобы обойти узкие места в Go. В общем разочарован, возможно нужно глубже копать, но хочется писать код, а не искать как же всё-таки заставить его работать

Я бы не стал так категорично говорить, что нужно избегать гос.конторы. Большая часть про них это правда, но если мы говорим о возможности зарабатывать в будущем, то в маленьких городах, по крайней мере раньше, было довольно сложно найти работу программистом, не 1С. Я в свое время ушёл из 1С в гос контору, потому что там кодили на Delphi. Проработав там пару лет меня взяли в софтверную компанию благодаря опыту в гос конторе.
Не хочу поднимать холивар, но хватит пинать Delphi, есть круг задач которые на нем очень хорошо решаются.
"Не работайте «мастером на все руки»" — не совсем согласен. Проработав в госучреждении приходилось выполнять и работу программиста и работу админа. Да админ из меня так себе, но знания эти точно не лишние для программиста. И что такое не работать мастером на все руки? Есть fullstack разработчики, они чем-то не тем занимаются? Мне приходится кодить на Delphi, Go, Typescript, да я не отличный программист на TS, но знание всех этих языков точно не мешает руководить разработкой

Вы тут говорите о принципе построения веб-приложений, а именно event-based approach и state-based approach

Да, это два принципиально разные подходы, об этом я и говорю, что Svelte никак принципиально не меняет разработку по сравнению с Vue
То что вы не можете отличить React/Vue/Angular/Svelte лишь говорит о том, что опыта использования этих фреймворков у вас не очень много

Я их могу отличить, но когда приходится читать много кода на разных языках, то на такие мелочи перестаешь обращать внимание

В давние времена приходилось все делать руками, из js лесть в DOM искать нужный элемент и при изменении состояния менять его или создавать новые элементы. Сейчас все это на себя берут Angular/Vue/React. Вот между этими подходами огромная разница. А разница между тем как написать :if или *ngIf уже не существенна лично для меня

Принципиально другой подход, в данном случае просто слегка разные ключевые слова и синтаксис

<h1 style="color:red">Hello {{ name }}!</h1>
<h1 style="color:red">Hello {{ name }}!</h1>
<h1 style="color:red">Hello {name}!</h1>

<input v-model="name">
<input [(value)]="name">
<input bind:value={name}>

<button v-if="count < 10" @click="count++">
<button *ngIf="count < 10; else elseBlock" (click)="count = count + 1">
{#if count < 10} <button on:click={e => count++}>

<div v-else>
<ng-template #elseBlock>
{:else}


Для Вас это действительно принципиальная разница?

Почему Svelte постоянно сравнению с React? Я когда вижу в статьях код написанный на Svelte, не сразу отличаю его от Angular и Vue.

"если нужен другой компонент со звуком?"
"не выдумывать новые компоненты"
Так нужен компонент или не нужен?

Мне кажется мы друг друга не правильно поняли, вы предложили, то что я написал в первом комете

Это понятно, здесь видимо логирование просто как пример привели, наверное не самый удачный

Чем это хуже кучи непонятных обёрток?

Один компонент MyButton у него свойство settings: {
logger: boolean,
sound: boolean,
popup: boolean
}
И обрабатывайте как вам нужно

Три раза прочитал, так и не понял зачем все это. Нужна кнопка с логированием, сделайте компонент назовите LoggerButton и используйте его, там где нужно логирование. Нужно куча всякого функционала, создайте кнопку MyButton, добавьте необходимые св-ва и в соответствии с ними меняйте логику поведения.
Или я не правильно понял поставленной задачи

Это все преимущества? Не увидел ни одной весомой причины, почему я должен с Vue перейти на это

Как дела у всех этих модных GraphQL и gRpc обстоят с документированием api? У GraphQL на сколько помню все довольно не плохо, а у gRpc?

Тоже думали про GraphQL, но в итоге отказались, он решает одни проблемы и приносит новые. Одно не пойму, синтаксис GraphQL и gRpc похож на json, почему его не сделать полностью совместимым, была бы сразу поддержка парсинга на всех языках. В итоге пока как самый простой вариант остановился на json-rpc. Простой стандарт, реализация вызовом между сервисами на разных языках делается за пару часов и никого не надо долго обучать как с этим работать

Раза три с помощью нее бросал) В итоге бросил совершенно противоположным способом. Заметил что курю в определенные моменты: после приема пищи, по пути на работу когда дохожу до определенного места, за компанию и т.д. В итоге решил не запрещать себе купить, а курить осознано, когда захотел закурить идёшь не сразу, а например через минуту или когда задачу закончишь. Не курить за компанию, если не хочется. В итоге быстро дошел до 4-5 сигарет в день, а после и вообще перестал.

FireDac вроде как умеет работать с PostgreSql. К ресту запросы через TIdHttp спокойной делаются и ssl там есть. Для json есть superobject. VirualTreeView отличный в DevExpress

Впервые публиковал, не нашел где указать. Не подскажете как теперь исправить

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность