211–220 of 456 posts
I have a theory. In the old days web development was looked down upon by "real" programmers. But then the WWW really took off and people started moving over from the C/Java world into the world of JavaScript. These are the people that insanely complicated web development when they tried to make it as complicated as the development world they came out of.
Earlier quoted context omitted.
> developing became more and more inefficient Anecdotally I find the opposite to be true. I've been writing frontend code for over a decade, but I've never moved faster and wrote less buggy code than now. Is that because I've become a better developer? Sure, a little bit. But by and large, I don't believe that ultimately is the reason. I think it's the maturity in the technology. My growth as a programmer is hardly l…
> These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti. I think this is one area where front end tooling can be painful for the average dev. The bar to writing idiomatic JS for a given framework can get pretty high quickly, especially when you look at some of the really popular tools out there (i.e. redux). Front end work has become so much harder to grok because t…
I have a theory. In the old days web development was looked down upon by "real" programmers. But then the WWW really took off and people started moving over from the C/Java world into the world of JavaScript. These are the people that insanely complicated web development when they tried to make it as complicated as the development world they came out of.
Do you have evidence? Vue and Svelte, IIRC, were authored by designers. Not C or Java programmers. Perhaps React has a different history.
IMO, TurboLinks + service workers are the way to go. Not many people know this, but a service worker (previously called "local server") allows you to run a little web server in the user's browser that intercepts requests to your own web site. (There's no open IP port.) The service-worker web server can proxy requests to the remote server, and even build/store entire pages on the client side, enabling offline support.…
Earlier quoted context omitted.
> These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti. I think this is one area where front end tooling can be painful for the average dev. The bar to writing idiomatic JS for a given framework can get pretty high quickly, especially when you look at some of the really popular tools out there (i.e. redux). Front end work has become so much harder to grok because t…
Redux is not idiomatic JavaScript though. It’s trying to make JavaScript immutable and have adt which it doesn’t. If you use elm, reasonml, rescript, etc this pattern is a lot easier to implement than with JavaScript.
I'm building an app with a TALL stack now (Tailwind, Alpine.js, Laravel, and Livewire) and I am incredibly productive. Very little build step required (to compile Tailwind to reduce the size based on which classes are used in .blade.php files). CRUD, Image uploads etc are so easily done I am such a fan. I was skeptical at first, but now I love this way of building web apps. No idea how well it scales, but for a simpl…
For all the speed bumps PHP 7 delivered Laravel typically scores lower than Django and Rails on Techempower benchmarks. This and the reality that PHP roles typically pay 20% less than Ruby, Python or Node has led me to ignore Laravel.
If you can do server side great: do it. The difficulty is accurately predicting how much JavaScript you'll end up writing. If your client-side JavaScript is comparable in complexity to your SSR you'll eventually end up with the worst of both worlds.
Earlier quoted context omitted.
Also never underestimate the power of a single bare-metal server. Today everyone seems to be in the clouds (pun intended) and has seemingly accepted the performance of terrible, underprovisioned VMs as the new normal.
Stackoverflow -- the website that every developer uses probably all the time -- is an example of a site running on a very small number of machines efficiently. I'd rather have their architecture than 100's of VMs.
For those who are discouraged by the massive complexity of Kubernetes/Terraform and various daunting system design examples of big sites, remember you can scale to a ridiculous levels (barring video or heavy processing apps) with just vertical scaling.
Before you need fancy Instagram scale frameworks, you’ll have other things to worry about like appearing in front of congress for a testimony :-)
My argument for SPAs rests on the completely subjective yet I feel incredibly powerful impact of latency. When anything takes more than 50ms to react, it becomes mentally jarring to the user. Whether it is typing in an SSH session, clicking a menu with a mouse, auto-completing a box, etc - all these things generate a completely different human response and relationship with the application if they get below that thre…
That's not possible for SPAs outside localhost. Every single SPA i know is clunky, including gmail which is probably one of the most barebones. The lack of visual indication that something is happening or downloading alone is infuriating with SPAs. Most of them reinvent the browser in a very poor substitute that invariably fails to both be practical , and to mimic a native mobile app (i think the latter is the reason…
Earlier quoted context omitted.
> Frontend tooling has never been better than it is today. What's the library or design pattern to consume a REST API in React or any of the mainstream front-end frameworks? The only thing I'm aware of is Ember Data but Ember is apparently not cool anymore, and I couldn't find a suitable replacement. I'm asking because in all the projects I've been involved with, consuming the backend API always felt like a mess with…
> I'm asking because in all the projects I've been involved with, consuming the backend API always felt like a mess with lots of reinventing the wheel (poorly) and duplication of code. I can't believe in 2020 there's not some kind of library I can call that will give me my backend resources as JSON and transparently handle all the caching, pagination, error handling (translate error responses to exceptions), etc and…
You have the concept of data adapters which would be clients for your API (you can make a custom one if extending the existing ones isn't an option) and the rest of the application just interacts with the equivalent of database models without ever having to worry about fetching the data. You could swap the data adapter without having to change the rest of the code.
We seem to have lost this with the move to React though, and even the hodgepodge of libraries doesn't provide a comparable replacement.