If it triggers an action with consequences, or even navigates users to a single-purpose page where they can select options or confirm the action-- e.g. 'cancel subscription now' or similar-- then it probably should look like a button.
Maybe if you're doing like a painting app or something you don't need to.
Yes. I think all web programmers need to know HTML and CSS. CSS is still just as relevant no matter how you build websites. People should also spend time learning HTML. Like, learn how to make content using raw HTML. Read the HTML of some of your favorite sites. This will improve everything you do with react and friends.
> Are there a lot of people who learn only web frameworks?
Yes.
Web programming probably has more programming beginners than any other area of software development. Its easy to learn - there are no C pointers in sight and no manual memory management. Websites work everywhere. And everyone needs a website - so there's lots of demand for web programmers. The debugging tools are also great (and you already have them if you have chrome installed). And frontend engineering is visual and obvious - so when you mess it up, you can usually tell.
So, yes. There's lots of people who learn just enough to scrape by and start making websites. Its great and terrible. I'm glad web programming is such an on-ramp for beginners. But npm is a disaster, and lots of websites are insecure, slow, amateurish messes.
Yes, because many people learn web development through bootcamps or other such courses (modern web dev is not usually taught in college, in my experience) which rush you to "job readiness" thus incentivizing using React over vanilla JS since most web dev jobs use React nowadays.
People look down on bootcampers, but it always feels to me that 99% of what is taught in university programs is similarly only useful in specialized situations. The actual good thing is having had to sit down and write a lot of code before anyone lets you touch anything.
What does such a program look like for Web?
If you go to a code bootcamp, you are learning react. A lot of new developers come from these places. Not a bad thing, but they could spend more time on fundamentals
That said, I'd argue that the selected framework should be one that doesn't completely obscure all the underlying HTML/CSS/JS (I'd avoid TypeScript at first) from them so it's easy to learn that when needed, plus it makes debugging using browser dev tools easier and means they'll have transferable skills for learning a second framework.
GWT (RIP, thank goodness) would be the extreme negative example, but React is on that side of the spectrum as well.
Vue, Svelte, Lit, and Angular seem to be the most popular frameworks on the "closer to HTML/CSS/JS" side of the spectrum, though I only have experience with the last two. Lit's great; Angular's not my favorite.
I don't think it's worth beginners learning the road rules and safety protocols, because of the "time to being responsible for a heavy, fast motor-vehicle sharing a road with other people" problem.
https://motherfuckingwebsite.com/
Really. At this point this is what websites should strive to be. Text on the screen.
Everything about HTML can be learned from the MDN documentation:
https://developer.mozilla.org/en-US/docs/Web/HTML
It can be written by hand but that's way too verbose. Pug is a great solution to that problem: it's just HTML but much less verbose. I integrated it with GitHub Pages so pug sources get compiled to HTML and published when commits are pushed. Great experience.
After this, the next step is to learn CSS so you can make it look a little nicer.
https://developer.mozilla.org/en-US/docs/Web/CSS
Javascript should only be necessary if you want to do something like this:
I think at the bare minimum you should strive to be readable, and you can do that with surprisingly few extra lines of CSS and very basic web design principles (avoid using full black or full white backgrounds). CSS is uhh... a choice, but you don't need to know too much in the very beginning to start building up some motivation of making stuff that looks easy on the eyes.
If you can't read it, there's probably a wild CSS messing things up on your end.
> W3C's Web Content Accessibility Guidelines set the minimum contrast between text and its background so that it can be read by people with moderately low vision (which is quite common).
If you follow that link to W3C, you'll see that the minimum contrast for text to be considered legible is 3:1, though that's for people with standard vision (it's the lowest rating). To be truly accessible, the minimum we should strive for is 7:1. Anything above that has a AAA rating.
Somebody needs to be the adult in the room and stop the children from running the daycare. As developers we should already know how to write code, or know how to figure it out, and that shouldn't be open to discussion. The discussion must only be upon defining the goals and stepping backwards one step at a time. This is called planning and proper planning will ensure the necessary automated checks are in place. Then "how to write the code" becomes straight forward as it either conforms to the automated checks or becomes a matter for discussion.
Now, for proper web principles and design methodologies, I'd love for some tips there.
But that web isn’t the one we’re dealing with anymore. We’ve moved from documents to applications. Like tabindex, I’m sure browsers or frameworks will gradually find ways to make any element behave link-like in every way. Which isn’t really a bad thing, it’s just development of the core idea of the web.
This is a hill I'm always willing to die on. Few things bother me more. Maybe fucking with my browser history...
Whenever I push for things that are technically correct I'm ignored and/or not treated well it seems.
Same people will also claim "we don't need a frontend dev or a UX designer".
Now ofc I wouldn't give any executives that idea. Don't mess with expected user functionality, that's like UX 101. if I see my navigation tampered with, I flag that site as spam.
Happy to report that our production site has more links that look like buttons than it does buttons that act like links. It’s almost a meme on my team that Swiz will get you if you use onClick for navigation.
The other hill I enjoy defending is that we should use more browser built-in components instead of trying to design our own.
I jest, but I am at least 5 years older than everyone else on the team. And have the unfun background of getting into professional webdev before jQuery.
Ugh. Let me know if you have any tips. All the art-school “UX designers” have to have custom date pickers and stupid knockoffs of iOS switches and custom drop-downs when there are actual, better, and automatically-accessible, versions of all those. How do you fight against this vanity design without making an enemy of the whole design team?
Yet there seems to be a free pass where a "web designer" is allowed to dictate how a site should work and look without knowing the basics of HTML, CSS and JS.
Even then, it would almost be forgivable if going back to list view (via their button or the browser button) were instant and seamless, but…
It never is! Going back means waiting for all the content to reload again and losing my position.
Why do you designers keep allowing this?
Thankfully this behaviour can be blocked with uBlock Origin by adding these rules:
www.reddit.com##+js(aeld, mousedown, isSelectionOutOfRange)
www.reddit.com##+js(aeld, mouseup, shouldShowButton)I had no idea that this worked. I don't "get" intentionally dragging if there's any alternative.
I feel like one of those people who tells people that frowning takes more muscles than smiling, but: dragging seems like it requires so many more muscles to be engaged than the keyboard shortcuts for copy/newtab/paste and then enter.
Usually when I'm reading something, my hands are off the keyboard and I use one hand to scroll with the mouse. In this scenario, it's so much easier to double-click to select a word and drag it to a new tab instead of reaching for the keyboard.
Imgur does the same, but that at least can be remedied by stripping the Referer header. I wonder how long this will last.
I predict Sec-Fetch-* will be abused for the same purpose. It may be already.
I miss Apollo. The friction with Reddit’s awful design and coding choices makes me use their site a lot less. I think that might be a good thing in the long run. It leaves me hungry for something better.
As a web user, this sort of "design" has made me focus as a practical matter more on HTTP (requests) instead of HTML (links). It's easy for me to make the links myself once I know where the requests need to go.
It's easy to take JSON and make own HTML. No Javascript needed.
There is a documentation platform called archbee (its even funded by YC) where if you run a search you cant open the search results in new tabs, you have to open one result in the current tab, and if its not what you want, you have to go back, search again and open the next result. This is incredibly infuriating.
You can see this behaviour here for example: https://docs.sparklayer.io/
There's no such thing as this.
FWIW if you hover over the parent link it is indeed populated with a different URL.
https://news.ycombinator.com/item?id=37013396 (shortened to 13396)
my comment you replied to
https://news.ycombinator.com/item?id=37020429 (shortened to 20429)
and your comment here is
https://news.ycombinator.com/item?id=37020517 (shortened to 20517)
I think the issue depends on whether you are on a a comment URL (e.g. clicking on the timestamp of a comment), or if you are on the post. If I'm scoped into 20517, the "parent" option is indeed a link to 20429. It will hard load to scope into 20429.
But if I'm on the actual 13396 post and click parent on your comment, I am instead 'loading' 13396#20429. Which of course isn't reloading the page but scrolling to a specific header.
I never personally liked the decision where replying or loading a comment took me to a whole new webpage instead of rending a formbox within 13396 and/or loading 13396#[comment ID], but I imagine there were historical and/or technical reasons for the decision. It generally doesn't bother me as I tend to mostly browse comments and only occasionally respond.
I am instead 'loading' 13396#20429. Which of course isn't reloading
the page but scrolling to a specific header.
For instance if a user ctr + cliks a button, have the navigation happen in a tab window even if the URL change is pushed by a JS module down the line.
You need a href for the browser to know where to navigate to.
Just use RouterLink.
It uses a native anchor tag. If you click (without Ctrl/cmd) it prevents default and does the navigation without reload.
I'm not making any argument here, just explaining. Also makeitdouble's idea would apply even to non-SPAs or to pages without javascript. For example, I might want to submit a form but in a new tab.
I still wish they should merge 90% if not 100% of HTMX into official HTML 5 spec.
When I joined my team, all links were buttons, random elements, or <a> with onClick. Nobody complained, but that meant ctrl click was useless, right click did not give you the options you wanted.
This is the only thing I'm a dictator about. There is zero room for negotiation when it comes to links.