211–220 of 433 posts
From my experience, the horrors of javascript come from letting the client handle too much stuff. Frontends tend to run a ton of logic that should be handed off to the proper tool for the job: SQL. The time and complexity you save on the backend is simply not put to good use these days. I like to program SPAs like a reactive thin client and let the backend be more SQL or ORM heavy.
Earlier quoted context omitted.
I agree with everything you say, but I'm in the camp that thinks that front-end is stabilizing. I feel many web projects can go a long way with something like NextJS, a few classic libs (eg, lodash/underscore/ramda), maybe a few libraries for handling data if you really need them. The design frameworks (MaterialUI, Tailwind, etc.) are also fairly stable. Perhaps that's one dependency too many for some?
Next.js is really bad, IMO and perpetuates more bad practices. Both Target.com and Walmart.com are Next.js apps. Both utilize SSR to render the pages (view the markup in the network tab). Both then STILL send the full data model to the UI (check the `__NEXT_DATA__` on Walmart.com and `__TGT_DATA__` on Target.com) because Next.js doesn't quite offer the right amount of control over what to send back (compare this to A…
I'll just add that I'm not familiar with either of those sites, because I'm sitting in Spain and neither operate here, but on first inspection the UX has felt brilliant to me - particularly Walmart's. Everything loads very fast, the search is great, etc. I cannot say if their code or eng practices are a tire fire but the product looks good to me.
Earlier quoted context omitted.
I agree with everything you say, but I'm in the camp that thinks that front-end is stabilizing. I feel many web projects can go a long way with something like NextJS, a few classic libs (eg, lodash/underscore/ramda), maybe a few libraries for handling data if you really need them. The design frameworks (MaterialUI, Tailwind, etc.) are also fairly stable. Perhaps that's one dependency too many for some?
I find it funny that the library that you think is helping to stabilize the front-end is called "NextJS".
And even some of the up and coming libs, like SolidJS, feel stable compared to the 2010's - they add incremental improvements but keep things that some people really like, like JSX. In the early to mid 2010's everyone was reinventing the wheel constantly.
The biggest problem facing the front-end space today isn't so much of complexity of a particular library, rendering technique, or view/model architecture, but rather lots of bad ideas glued together, creating nightmare scenarios for companies trying to maintain products. A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea. Using un-opinionated "librar…
I like to go back to the basics. It irks me that folks don’t think HTML/CSS/JavaScript are good enough as-is—but nowadays the default browser capabilities are incredible compared to a decade ago. We basically have a full programming environment and add WASM to the mix! Back in the day the frameworks were first-and-foremost a platform compatibility solution. People often have it ingrained in their psyche that reinvent…
I work at a place that is mostly like this, I can tell you that using html/css/javascript raw, with a bit of bootstrap is a nightmare with a SPA.
Menus are constantly broken, back button is a game of roulette, caching is constantly a problem showing stale data, xss and other vulnerabilities are ubiquitous.
There are modern affordances in many of these frameworks others take for granted.
This is nice but it is from 2016. I wonder if that system is still working and maintained.
Seems like a half-baked agency-built version of htmx[1], no? I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke ro…
>I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, What's old is new again. There's an entire generation of developers now who have no concept of the old world. They started with React/Angular/Vue and have no idea that SSR was the standard default for decades. And now it's a "new idea" that is held up against JS development with no…
Earlier quoted context omitted.
I don’t see the difference. Isn’t backend code code you have to maintain too?
You need a backend anyways. Shifting to a server-side codebase is eliminating duplication, and arguably server languages have better DX so win win.
That reason alone is why I prefer having the server doing the bulk of the heavy lifting. It reduces variables in the most functional parts of the app and reduces my need to try to herd users into using particular browsers.
The biggest problem facing the front-end space today isn't so much of complexity of a particular library, rendering technique, or view/model architecture, but rather lots of bad ideas glued together, creating nightmare scenarios for companies trying to maintain products. A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea. Using un-opinionated "librar…
I noticed this in gaming as well as software... engineers always build for the best hardware. Despite everyone knowing that extremes (in the wild) are a minority.
I believe tech needs to focus on building better 4-cylinders rather than expanding cubic inches.