441–450 of 629 posts
These are the tools that promote the idea of keeping app state on server and client/server talking HTML, not JSON. If you're not yet familiar with the concept, you'll love reading Essays here: https://htmx.org/talk/ (scroll down and look to the right side).
I'm on both sides with this one. I feel like someone could have written the same 10 years ago. "But why do we need something so inefficient as Python, we have C that does the job and is much faster". "GUIs? Such a waste of resources, CLIs do the job just fine and you go faster with it!" At the same time, I'm also personally quite bored with the sheer amount of complexity we seem to put in everything those days. Layer…
Getting a job straight out of a bootcamp is hard. Getting a front-end job out of a bootcamp without knowing the most popular technologies is even harder. Bootcamp's interest will always be to increase their students odds to be hired rather than foundational knowledge
Bootcamps follow what the market requires. My main point was more about the market we have created for ourselves :).
Earlier quoted context omitted.
it is an interesting point though. Like I've tried to think of elegant solutions where we can get the customer's browser to preprocess work for us so we can reduce our total lambda/ec2 time. for example one could have their browser generate the thumbnails for an uploaded photo instead of just uploading the single image upload. After all, 1000s to millions of browsers can make short work of something that might be hea…
Reminds me how in one online multiplayer game developers decided to offload the decision of "who's the winner of the match" to client machines. Because there were some problems on server side and they couldn't do it reliably there. Developers said this voting system worked surprisingly well. Theoretically if there were >50 percent of malicious game clients they could all vote for a wrong player but this was hard to a…
Standalone PHP templating is torture.
Earlier quoted context omitted.
While I can get behind the idea that lowering barriers to entry is a good idea, I don't think that's the same thing as tolerating ludicrously slow garbage tools just because everyone insist on either developing like a baby or only hiring babies. As an industry, we should be deeply ashamed at how much of the world's time and resources are wasted running poor software so a company can save a few bucks.
> As an industry, we should be deeply ashamed at how much of the world's time and resources are wasted running poor software so a company can save a few bucks. This seems like you are saying everyone should write in assembly or c language for ever task possible, since that's the only way to avoid "wasting the worlds resources running poor software". At some point the trade offs are not solely "so that a company can s…
I feel comfortable with asserting that the author has never worked on a complex web application. This web-dev hate borders on pathological: this is a guy that seems to specialize in Unix/Linux tooling, doesn't have a single tutorial on web app development [1], and yet has an intense hatred towards a space that he barely understands. These types of arguments are incredibly embarrassing to read, not only because they b…
> it still is a templating language at the very core, yet it is apparently not good enough. Standalone PHP templating is torture.
Earlier quoted context omitted.
I work on a massive CMS and he’s correct. There is an insane groupthink going on in webdev. Another team in my org has spent a year reinventing our client side js so that our templates are now mixed with the svelte runtime. All to render/update cards on the page that can update when an api pings the page. So 6 months later they’re still building the svelte integration and have only shipped 2 pages to users. This is a…
I know the feeling, specially bad now with the headless CMS fashion.
The key thing behind the "headless CMS" fashion is that most people severely overestimate the amount of cost reduction and underestimate the impact of something breaking down in the backend side as well as the engineering cost.
"They constantly crash..." Putting aside the downsides and reasons not to use Electron, this statement is just false. They are not "constantly crashing." I currently use at least Figma, Insomnia, Slack, Spotify, and VS Code and these apps rarely crash, if ever.
I've experienced multiple copies of Spotify on different machines getting forever stuck just showing a blank screen when opened. Although that's probably more Spotifys fault rather than the tools used to build it.
The author is fighting a strawman. Rather than engage with the specific problems these solutions were built to solve they dismissively regard them as just flavor of the week trends purely for the sake of chasing newness. This is true of the entire post, but I'll tackle just one since it's emblematic of my issues with all the rest: The argument for Electron and React Native isn't "it's modern", it's "it's much cheaper…
What is it about building "web-related technology" that makes it so cheap? Is it actually that much cheaper? And if so, why? Why isn't there a platform for making apps that compares?
Mainly a huge existing (and ongoing) investment from Google.
> Why isn't there a platform for making apps that compares?
Not enough money in it for a company that would make something properly polished, and the open-source stuff works well enough for its own developers and gets bikeshedded to death whenever anyone tries to add good defaults and provide an easy onramp (if anyone even cares enough to try). Like, in theory you could glue together something with Python, Qt, PySide and Freeze where someone can write two lines of Python, push a button, and get GUI executables for all major platforms. But good luck getting anyone to accept your patches or commit to not breaking compatibility with what you're doing.