likortera

11 ms·

61.
by likortera 4y ago
Yeah, I do the same. Most of what I do is Next.js + a good bunch of npm packages to get the "full stack". But I wouldn't call Next.js full stack because it can do SSR, or even API routes. But again, that's just me confu
62.
by likortera 4y ago
In the case of laravel, I think that having by default a pretty awesome templating system (which even allows for components), a webpack based build system for frontend assets, easy way to serve, cache and bust assets, and a trivially easy w
63.
by likortera 4y ago
well, I agree.... but to me the baseline is, as I said, Rails/Laravel/Django... there's a common subset of things you need in like 99% of web applications that are not just a rest API or a landing page.
64.
by likortera 4y ago
You shouldn't.
65.
by likortera 4y ago
Am I the only one that think nowadays anything can be called "full stack"? For me "full stack" is something like Rails, Laravel, Django, etc. Or is it just being able to run code on the server enough to be "full sta
66.
by likortera 4y ago
Spot on! One of the companies I worked for, had the brilliant idea of putting EVERYTHING related to UI/frontend in a monorepo, where almost every single file or two were a different package. I used to joke there were more package.json
67.
by likortera 4y ago
In the last 20 years doing web development, I haven't ever had one single colleague, friend or customer complaining of any site not working because they had disabled JavaScript. Literally didn't heard about anyone around me with t
68.
by likortera 4y ago
Even if building MPAS with js sprinkles, nobody is going to put the effort to build and test a non-js versions for the 0.01% of weirdos turning off JavaScript in 2022. Just don't use my service
69.
by likortera 4y ago
Even if this were true, you are sacrificing your end user experience for having a better development experience. I'm a frontend dev and I work with React all day long. I still think MPAs and stuff like HotWire/Livewire/etc sh
70.
by likortera 4y ago
I still wake up in cold sweat in the middle of the night feeling herds of yaml files are chasing me to pull me into the deep swamps of the clusters.
71.
by likortera 4y ago
Exactly. And probably what Apple, Google and Facebook do is just the exact opposite to what the other 99% of companies out there need. Who on earth can think that what they do, companies with the engineering power as these companies have, h
72.
by likortera 4y ago
I'm saying using BOTH monorepo AND microservices is a clear signal you're building a distributed monolith. What you say is also true
73.
by likortera 4y ago
If you use monorepos and at the same time you use microservices, what you are doing is called a distributed monolith.
74.
by likortera 4y ago
Well, almost everyone talking here about nonorepos why they are actually building are distributed monoliths. That's why they need changes cross all clients on the same PR.
75.
by likortera 4y ago
Then why not call it just a repo and build a monolith? I've seen people going crazy with this bullshit of monorepos to the point every single directory was a "package" when it could be just a plain module import. If you want
76.
by likortera 4y ago
More fancy words on somebody's CVs? I worked at a similarly large and almost as popular SF based company and I can assure you every innovation there was 100% motivated by somebody's desie to put.it in their CV. Nothing of what was
77.
by likortera 4y ago
Except you're now calling functions across the network. And no more complete tracebacks. And need to deploy 10 things at the same time or everything falls apart. Yes, you get the benefits, but also all the drawbacks. Those drawbacks mi
78.
by likortera 4y ago
What you are describing as the good parts sounds to me as what you get from a traditional monolith. Why build libraries and separate services if an update on some part of the codebase needs changes across all the platform? This trend of mic
79.
by likortera 4y ago
I work at a very popular company (which is a great one to work for) but the stack is pretty old, and eve worse, they are pretty old fashioned in everything tech-wise. Any kind of modernization or major improvement is usually faced with a lo
80.
by likortera 4y ago
No microservices on top of kubernetes? no SPA with SSR? You are doing it wrong. I'm gonna write an alternative which will be WebScale. j/k of course.
81.
by likortera 4y ago
A few years ago I worked for a company that used https://shortcut.com/ (at that point, it was named clubhouse I think). I loved it. I think that tool can do everything Jira does in a much better and saner way. It looks a lo
82.
by likortera 4y ago
I've been at several companies. The ones where things were the smoothest were using App Engine, other was using Tsuru, and the other was using heroku. Zero problems. The companies where we suffered the most, had to fight a lot to get a
83.
by likortera 4y ago
/remind 20 years check Elixir again.
84.
by likortera 4y ago
This is the worst of all of the solutions in my experience. For example, say you have a "card" or a "dropdown" component, now you need to maintain two implementations of it, one for the django templates and another for t
85.
by likortera 4y ago
Cons: missing community, a lot less well maintained libraries, needs more wheel reinvention, impossible to hire experienced developers, far worse tooling and editor support.
86.
by likortera 4y ago
It's funny to me to see how many people say Next is copying something about remix when the entire remix thing is a copy of Next. Heck, I've heard in a podcadt they're even working on a hosting platform copying vercel.
87.
by likortera 4y ago
> The commit will now contain 10000 non html structure changes to an html It's an acceptable trade off. Nothing is perfect. In exchange you're guaranteed those changes only affect this markup, and not some other li > ul >
88.
by likortera 4y ago
> It's basically the point of cascading style sheets The "cascading" part is what makes it incredibly complicated. Keeping the "cascade" in sync with the actual markup is not a trivial task in teams with many peo
89.
by likortera 4y ago
Because most people worry more about maintainability, ease of writing, modifying, performance, resulting bundle size, tooling, consistency, etc and very few about "how it looks". Everyone that complains about tailwind is because t
90.
by likortera 4y ago
Have you ever had to change the company's look and feel with anything else than tailwind? I had to do it with a BEM codebase, and I also had to do it with tailwind. The tailwind situation was by far the easiest one. And it was because

More ›