hopefully developers will start paying attention some day, if i see a webpage that renders blank with js off, i leave
I do the same for sentences starting in lower case and missing punctuation.
Building a robust frontend using progressive enhancement
111–120 of 168 posts
Re: Building a robust frontend using progressive enhancement
#112Earlier quoted context omitted.
> I can't win this battle You are fighting the wrong battle. You harp on the technology used rather than the specific functionality you desire. The bad way to do it: "You made a single page app with PHP and {other tech} and {database}! I hate those! Don't you read (reddit, twitter, hacker news)? Best practices say..." The good way to do it: "Our users often share links within the application with each other to naviga…
This is fairly basic advice, and it feels a bit insulting to assume I'm just hating on some tech. Obviously, if things were as easy as "here's the immediate and unambiguous problem with this approach", I would have gone that way. Things would be great if the risks were as simple as this. The actual problem is "six years later, the frontend is a ball of spaghetti code and it takes you two sprints to change a component…
Not enough. But they will scoff at other technologies old and new.
Re: Building a robust frontend using progressive enhancement
#113Earlier quoted context omitted.
Despise React's unnecessary complexity and non-standard-compliant non-separation-of-concerns squeeze-it-all-in-js approach as well. Svelte(kit) is still the most W3C compliant of the major frameworks out there. Also, it's not even a runtime-framework but a compiler, meaning you're left with nothing but the necessary HTML, JS & CSS just relevant for your page.
React in the hook's era has gotten overly complex. The cods is unreadable and hard to reason about. Check any longer/complicated component as an example riddled with hooks. Comparatively, Svelte has a much simpler mental model and at the end, leaves nothing but basic plain old javascript. But I tend to question these days that do we need this much Javascript?
Mostly for reactive rendering in response to incoming small data packets (or user supplied changes) mutating state.
I have not seen an example of how to do that using vanilla HTML and CSS without some JavaScript support. Maybe it exists and I haven't come across it.
Re: Building a robust frontend using progressive enhancement
#114> If you use a JavaScript framework you should: > > be able to justify with evidence, how using JavaScript would benefit users Steady on, guys.
Use? I look at all the time to keep it running.
Re: Building a robust frontend using progressive enhancement
#115A good rule of thumb is: if your app can/could run offline-first like a desktop app, it's ok to make it a single-page application. They can be snappier and better than a multi-page browser app. Examples would be stuff like Photopea, Google Docs/Sheets, tldraw, etc. This way, the biggest downsides (moving between pages & requiring an internet connection) are eliminated. But if your app requires an internet connection…
Snappier is an outdated concept. HTML has lots of tools in it now.
SPA's are one thing, the complexity to create it is another.
Re: Building a robust frontend using progressive enhancement
#116Earlier quoted context omitted.
> I can't win this battle You are fighting the wrong battle. You harp on the technology used rather than the specific functionality you desire. The bad way to do it: "You made a single page app with PHP and {other tech} and {database}! I hate those! Don't you read (reddit, twitter, hacker news)? Best practices say..." The good way to do it: "Our users often share links within the application with each other to naviga…
This is fairly basic advice, and it feels a bit insulting to assume I'm just hating on some tech. Obviously, if things were as easy as "here's the immediate and unambiguous problem with this approach", I would have gone that way. Things would be great if the risks were as simple as this. The actual problem is "six years later, the frontend is a ball of spaghetti code and it takes you two sprints to change a component…
> heed those warnings
It's not a warning. It's a functional requirement that you put into the ticket. The project isn't done if the rewritten page takes longer to load than the old one did. Don't ship it, don't pay bonuses based on shipping it.
Re: Building a robust frontend using progressive enhancement
#117Genuine question: Judging from the comments, seems like people like this approach. So why is the general trend more towards approaches that use javascript (sometimes unnecessarily) and frameworks like React?
1. Complexity. Devs like complexity like cats like catnip.
2. Tools. React+JavaScript is the industry monoculture. If they're all you know (and for a significant number of frontend devs this is unfortunately true) then you're invariably going to build something complex because its in the nature of your chosen tools.
3. Career anxiety. Building something simple using simple tools isn't sufficiently hardcore and braggable to get that juicy comp increase at the next performance review, never mind a promotion or hopping to that next job.
Re: Building a robust frontend using progressive enhancement
#118Genuine question: Judging from the comments, seems like people like this approach. So why is the general trend more towards approaches that use javascript (sometimes unnecessarily) and frameworks like React?
Because the ux and dx are better once you reach a certain amount of complexity. Companies know what is best for their business. There were will always be a group of devs that don’t like it because it isn’t the same web as in their heyday, and they all will eagerly pile on anything remotely JS-critical is posted on HN. There is a selection bias to the comments that does not accurately reflect the industry opinion.
> Companies know what is best for their business.
"Companies" don't really know anything. The decisions get made by people, with all the flaws that people have. I have seen many developers make decisions that are detrimental to the company.
I do agree that there is a section of HN that will pile on these kind of topics, and I have flagged dozens of low-effort swiped against JS over the years that add nothing.
But two things can be true at the same time:
1. there is an unpleasant section of HN that will rant about all things JS, and
2. SPAs (or our current approach to them) bring a lot of downsides and are often not worth it.
Are entirely compatible.
Re: Building a robust frontend using progressive enhancement
#119Earlier quoted context omitted.
for real, do you want swarms of developers to lose their jobs because software complexity collapsed?
If we want full employment, we should mandate people use spoons instead of shovels.
Re: Building a robust frontend using progressive enhancement
#120Earlier quoted context omitted.
This is fairly basic advice, and it feels a bit insulting to assume I'm just hating on some tech. Obviously, if things were as easy as "here's the immediate and unambiguous problem with this approach", I would have gone that way. Things would be great if the risks were as simple as this. The actual problem is "six years later, the frontend is a ball of spaghetti code and it takes you two sprints to change a component…
> heed those warnings It's not a warning. It's a functional requirement that you put into the ticket. The project isn't done if the rewritten page takes longer to load than the old one did. Don't ship it, don't pay bonuses based on shipping it.
Please read my comment more carefully, you're being patronizing. I can't put "I want feature development on this codebase to be faster than two sprints in six years" in the requirements.