171–180 of 328 posts
Earlier quoted context omitted.
Nothing pisses me off like getting a message that some website only supports Chrome in 2020
At work we're forced to use a service for exchanging files where uploading a file is only possible in Chrome, but downloading a file is sometimes only possible in Firefox. Pinnacle of UX.
1) Nobody has any idea what they're doing 2) If you think you know more than your manager – you are absolutely right 3) HN is 3 years ahead of mainstream, but 10 years behind the edge 4) React was made by an OCaml programmer 5) if you want to be that good, learn emerging languages (all of them) 5) don't optimize for money too soon, if you follow these instructions you will quadruple soon enough 6) Whatever your probl…
I like your list, but I’d suggest: 8) learn a statically typed language with a good type system Even if you end up preferring mainstream language X, learning a language that makes you think in expressions rather than operations, and a language that makes you think in contracts rather than knowing the runtime state in your head, is invaluable for learning how to design, structure and maintain a codebase
Earlier quoted context omitted.
Nothing pisses me off like getting a message that some website only supports Chrome in 2020
It's so sad that it became "acceptable" to not test in Firefox (as estimated by the number of sites I randomly encounter that don't work in FF but do in Chrome) right around the time that Firefox Quantum happened and Firefox became good again :(
I've used Firefox for 15+ years now and never had the problems that people talk about.
Earlier quoted context omitted.
It's so sad that it became "acceptable" to not test in Firefox (as estimated by the number of sites I randomly encounter that don't work in FF but do in Chrome) right around the time that Firefox Quantum happened and Firefox became good again :(
Firefox must have performed poorly on Windows / MacOS in the past, because Firefox on Linux was never actually that bad. I've used Firefox for 15+ years now and never had the problems that people talk about.
As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…
I get that most of the web and most of what web developers do these days are just regurgitations of the same basic website designs. But man there is some really powerful tech in JS and WASM just waiting for someone to make brilliant stuff from.
As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…
If I'm able to render things from the backend, I just have to query the data and slot it into the page. No need to design an API that's flexible enough for application use but still inflexible enough to prevent security holes.
Also, if I decide later to update how the data is represented (a common activity in early-stage projects), I only have to edit only one thing instead of two things.
As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…
Because they rarely know about it. And why would they? It's a very technical choice. Factoring in things like render speed is your job when picking the most appropriate solution for the problem at hand. When you're doing this you are placing your own comfort and ease above that of anyone using the site. Google already factors site speed into rankings and with all the Web Core Vitals stuff they've been pushing lately it's only going to be more important. You're failing your clients.
As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…
It’s also fundamentally impossible for any website/app based around more complex ideas. I get that most of the web and most of what web developers do these days are just regurgitations of the same basic website designs. But man there is some really powerful tech in JS and WASM just waiting for someone to make brilliant stuff from.
Earlier quoted context omitted.
Firefox must have performed poorly on Windows / MacOS in the past, because Firefox on Linux was never actually that bad. I've used Firefox for 15+ years now and never had the problems that people talk about.
I left Firefox in 2011 because it was unusably slow on my macbook. My recent experience has been that it is much faster and I am considering switching back.
> Browsers change. Relying on browser-specific behavior means you’re relying on that one browser at that one point in time. Code to the standard, and test everywhere. I wish this was listed at the top of the list, in the middle, and at the end. It’s super annoying when a site or application isn’t “supported” because it wasn’t tested in a separate browser (i.e. non-Chrome browsers). I know it’s not always easy with a…
> with the browser vendors working together to be compatible with each other The one with the greatest market share is incentivized to the contrary in order to cement their position.
My idea (when looking at the picture a tad narrowly, there's so many variables here) is really when it comes strictly to rendering content, all browsers should be the same. HTML/CSS/JS in one browser should produce identical displayed results/behavior in another. I'm all for the implementation being different, resulting in performance differences, differing external functionality and features, etc. But the core use, displaying content, should not be broken because you aren't using the browser the developer of the site/app was using.