When I was hired on the Watson team, the first thing they asked me to do was help improve performance of their AngularJS-based website. It was all-around slow, especially for the initial page view. I stripped out AngularJS and most of the other JavaScript, and published a website that was almost pure static HTML. It loaded very quickly. My manager thought it was hilarious - his "JavaScript expert" came in and deleted all of the JavaScript.
I've had interview candidates for frontend developer positions who only know how to build web pages using frameworks like Angular and React. They don't seem to understand how those frameworks work but essentially patch together a bunch of example online to get something going. It's truly unfortunate that many beginner web development tutorial introduce these technologies first in my view. Without giving new developers understanding basics of the web platform they get siloed into only knowing one way to do things and it results in using the wrong tools for the job as this example shows.
> only know how to build web pages using frameworks like Angular and React
I've never been able to fathom how anybody can do that without understanding the foundation that it's built on. At the bare minimum, how the heck do these people troubleshoot errors? If you have so much as a typo in your code, Angular is going to give you a completely cryptic jQuery error message.
This is why I came to really dislike angular pretty quickly. Maybe it's just evidence that I suck at javascript, but I found it devilishly difficult to debug even seemingly simple issues. But the errors were not in jquery, they were in the maze of the digest cycle. But I agree, I have no idea how beginners manage when things fall off the happy path.
Here's another perspective. I started learning JS in reverse and ended up just creating my own framework because it was less verbose. But you would hire me over your patch-and-patch fellows?
Perhaps the right answer is to code know the basics but also have a handle on the popular frameworks too.
Depends what you're being hired for, but I tend to believe hiring managers are overly biased towards CV bullet points on the highest common library/framework in the stack. This is after all the most precise information you can put in a job description that is actionable by a recruiter/HR-person.
But in my view, building your own framework first and then learning a standard equivalent gives you a much better understanding of the tech of the new framework which will pay dividends. For instance, I built my own PHP framework in 2001, and subsequently played around with Drupal/Django/other homegrown frameworks. When Rails dropped in 2004 I was immediately ready to jump on board because I had been through the same mental process as DHH had when he started building Basecamp in Ruby after having been frustrated by PHP. Whereas a lot of people complained about Rails' magic and lack of transparency, to me it was very easy to dive into the source code and understand the reasoning that led to its architecture.
Of course these things calcify over time, and you don't need to necessarily go very deep into every layer of the stack, but you have to at least be competent in a few layers or you'll be helpless the minute you hit a problem with a leaky abstraction. But in the case of JS, yes I think any time spent learning core JS is well-spent, and knowing only React/Angular is a real liability as a front-end engineer, especially because those frameworks are designed to solve heavy SPA problems which are only a tiny subset of the type of interactive web pages one might want to create.
"Here's another perspective. I started learning JS in reverse and ended up just creating my own framework because it was less verbose. But you would hire me over your patch-and-patch fellows?"
Yes more likely. In fact I would find informative to see the framework that you have built as an example of understanding web development.
To expand a bit I think learning the framework is easier once you have an understanding of the web platform's basic. For non web stuff I value more problem solving ability, general CS knowledge over specific technology knowledge. I usually don't set a language requirements in interviews and look more to someone being able to explain how the code they wrote works and why it's a better solution than say some inefficient brute force method. Which in my example when applied to web stuff would translate to why is implementing something this way in angular better than an alternative, what advantages did you gain from angular. Etc...
I recently worked on a site at my job where I was able to implement it with JS + C#/OWIN, all static html, only uses toastr/jquery. Was nice they let me break away from the illusion that the choice is only between WebForms or MVC
If you ask me to compare this to Angular, I'd have to say I've never used Angular so I don't know
Any specific reason? Not trying to be accusatory, but your comment appears not genuine and I don't see anything instantly unhirable about his code after a short peruse.
I'd hire you but I'd still make you use a framework.
Convention makes code readable and maintainable. A framework is essentially shared convention that you don't have to maintain. Making your own framework shows that you understand the value of convention.
A framework means that spaghetti code can only get so bad. A bad ad-hoc implementation of a web platform is an order of magnitude worse than bad code written on top of a popular web platform.
When I look at ugly React code, I know how to extract logic, where to push it, how to identify poorly-named concepts. When I look at ugly vanilla JS, I don't know what to make of anything.
Right, start with something simple, say a form and add client side validation to it. Move to making a small widget that updates with data obtained async using plain XHR. Add some styling with out preprocessors (so you know why they make life easier). Understand events and how they propagate etc. Learn a bit about the DOM and how to query it with built in apis. Etc...
Consult MDN (Mozilla developer network) and read their articles
I think it's partially an artifact of JavaScript's historical arc. Piecing together examples was maybe not best practice, but it was pretty damn good practice in the days when Jquery was best practice and in those days Jquery was best practice because browsers varied. I mean the alternative to using black boxes was to recreate Jquery.
It's also partially an artifact of JavaScript's lack of namespaces and scoping rules and prototypical inheritance because these make it easy to make a class of errors that are conceptually difficult to understand without holding a complex mental model in my head...and that's after standardization of browsers reduced the number of arbitrary rules that could cause bugs.
I did just that same thing for a client. They were using React to make 1 AJAX request to Foursquare. The thousands of lines of code turned into 22 lines of vanilla Javascript. I was shocked.
Market share might be a ridiculously small percentage overall, but it's never appropriate to dismiss compatibility outright.
Reasons to include inefficient code for compatibility reasons might include applications where maximum reach is valuable, or where the scale is so large that the "infinitesimal market share" percentage plays out into thousands of end users.
Because market share is only meaningful if you target consumers. If you write (internal or niche) web applications for e.g. schools, large companies, non-profits etc. legacy browsers can easily be > 30% of your targets.
I would say that is what makes you truly a "JavaScript expert". Knowing when to use it and when not to but most importantly knowing how to implement alternative solutions when needed.
It would be cool to see the before (with AngularJS) & after (pure HTML) of this.
A large percentage of the "very skilled" developers I know will much sooner brag about how much code they deleted or didn't write than how much code they wrote.
That is already well known quality[1]. I find Parent work even deeper, he pivoted the whole thing to make his main skill a second class citizen because that's what it was to be in this context.
[1] I regularly nerdgasm at LibreOffice releases reading how many thousands LoC they removed from the code base.
ps: beside code golf, I think there should be a patch golf thing. Try the smallest changeset that fixes or add a feature.
That's the exact reason I thought of it [1]. With "large" code base, every character impacts the project, patch size becomes a skill. That said, it's so tempting to fix multiple almost related things in one go.
Generally when I hear people talk about having imposter syndrome in software development, I feel like they're missing this key insight. The fastest code, and the easiest to maintain is the code that's never written. I've been trying to formulate how to express this idea to people who don't have it ie paraphrasing YAGNI:
"Strive to optimize for less code, and the minimum level of abstraction."
"Strive to optimize for less code, and the minimum level of abstraction."
That should be the appropriate level of abstraction. The appropriate level of abstraction being that which requires the least code to implement and least effort to reason about.
I think "appropriate" is highly subjective. The problem is developers seeking to impress their peers with over abstraction of trivial things. I personally think "minimal" is more "enforcable" ie easier to convey in a code review comment for example. Again, imo.
Every time I read about the original "hackers" of the modern computer era, it seems many were much more focused on refining their code, or "bumming" lines of code, into the smallest form possible due to the technological limitations of the time. It's not super surprising many developers aren't as conscientious about bloating software because computers have gotten fast enough to mask a lot of performance issues. Still, I think those who strive for less code show maturity as a developer. For one, you can't remove lots of code if you don't truly know how the code works, and furthermore, that process is a good way to learn how it does.
So let's show off what you can do without JavaScript...but also include SCSS as a dependency when the opening paragraph complains about a JavaScript dependency? Madness...but I digress.
Some of these are cool examples. Others, like the modal, won't scale very well because now you can trigger modals by tabbing (breaks keyboard navigation) or most of the form examples as you'll likely hit many endpoints that require JSON (which yeah I know "you're making a web app why can't your endpoints accept a form?" but as we all know it's never that simple and you might want to provide different behaviors for, say, showing a progress bar or disabling certain features during the submissions or a THOUSAND other things).
I get axing dependencies. I really do. I wrote msngr.js entirely in ECMAScript 5 using zero dependencies so I'd have the most flexibility possible. But at the same time overcomplicating your code to the point where it's breaking standard practices or making it un-maintainable simply to axe a dependency is the wrong way to go.
But by all means keep making cool stuff that shows off how versatile CSS is! Just don't expect to use all the CSS tricks you learn in a production environment.
I agree, but I think you're putting the emphasis in the wrong place. A SCSS dependency isn't that bad because the client will never see it.
What is bad is code that's hard to maintain. When I did a stint of front end development recently, I went in with the mindset that "JavaScript is evil for the user and therefore should not be used when avoidable". I discovered after a while that although you can replace JavaScript with CSS sometimes, the resulting code is often much more difficult to understand and modify than the original JavaScript would have been. It's no longer in my interest to avoid JavaScript at all costs, as was the case before.
You touch on this with your "overcomplicating" sentence, but I feel like it didn't get the spotlight it deserved in your comment!
Javascript is not evil, evil is when it's used unnecessarily, and when your page displaying 4-5 pages of text starts out 2mb without images and becomes 15mb as I scroll to bottom because you're pinging various third parties for analytics and whatnot, and when I can't view you pages where the essence is a couple paragraphs of text but you wanted to render it via Javascript and I have it blocked and you not whitelisted, and when I hesitate to use my schools web services for important things that may affect my academic career but god knows what's gonna break when on that halfe-arsed website, and especially when you mess with my history (my pet peeve).
These "you"s are rhetorical BTW, I'm not addressing kqr directly.
We-e-ell, it's not a good language. But it's what we have.
I agree, though, that it can be used well and does have a place in writing good web pages and sites, but that when it is used to create horrible 'web apps' it is being used for evil.
The first two were actually making a good point. This website (yours, presumably) is just jumping on the bandwagon and sticking an affiliate link in it. I'm not against affiliate links, but this site lacks substance.
Honestly, I can't stand websites that decide to waste 70% of screen estate. I can see the first site almost without scrolling. It is 2 to 3 pages on the other iterations.
The only things I may agree with is https and zipping.
"Fits on all your shitty screens" Does mean that it FITS ON ALL YOUR SHITTY SCREENS. Mine is a 1920x1080 (which is the minimal nowadays) and the 2nd and third iterations DO NOT FIT IT.
That thing around the web page, it is called a fucking window. It resizes. I'll do that if I want your fucking column-format.
The second one is the only one that puts any effort into actual legibility. There's a nice comfortable amount of space between the lines! The text doesn't render right at the edge of the page! There are MARGINS and WHITESPACE.
If you just take your browser's defaults for all the typographical stuff like that, everything looks like trash.
I remember one of my dev friends showed me this when jQuery was taking off. The site has changed over the years because back in the day when I first saw it, he was railing against using too much javascript - specifically jQuery.
None of these requires SCSS at all. You may verify by grabbing the SCSS they provide in the codepen and pasting it into http://www.sassmeister.com/
Most examples are equally compact in plain old CSS. In fact, many of them are just plain CSS displayed in a window labeled "SCSS".
The places using SCSS seem like they're simply being more sane in allowing a user to change numbers trivially. Instead of saying "just change all the 400px throughout to 500px", one can change the `$slide-width` definition in one place (usually at the top).
There's also the style preference of nesting to group. But neither of those make it a strict dependency.
---------
EDIT: I'm not saying that I disagree with your assertion that CSS is a bad place to layer logic from a maintainability standpoint; I'm more pointing out that blaming it on SCSS makes no sense in this context.
> I'm not saying that I disagree with your assertion that CSS is a bad place to layer logic from a maintainability standpoint; I'm more pointing out that blaming it on SCSS makes no sense in this context
I don't see where I blamed anything on SCSS just found it amusing the page purports to axe dependencies (JavaScript) but uses SCSS. The rest of my post is far more on topic and interesting. Everyone is focusing on my SCSS poke though, heh.
I certainly agree that the rest of the post makes sense and is more on topic! It's why I felt the need to add the statement at the end of my own stating that I agree with it, immediately after I posted it ;)
Re: requirement - there I was referring to your opening:
> So let's show off what you can do without JavaScript...but also include SCSS as a dependency when the opening paragraph complains about a JavaScript dependency? Madness...
And explaining that although they used SCSS, it certainly isn't a requirement, nor even much simpler than the plain CSS.
I'd guess that most of the responses probably focussed on it because leading statements are often read louder than what follows them. They set the mood/tone in a way.
You could go the other way just as easily, and eliminate the css requirement. Doesn't mean it's the best way to do a given thing.
Also, the examples don't support a lot of use cases... the accordian and tab examples, while interesting will submit goofy information if they're containing multi-part forms.
The image changer will break other bits of navigation, or similar changers by abusing the target. Similarly, the lightbox example doesn't have a slideshow support, and even if so, would probably be as/more complex than just using JS.
Also, how many of these examples work in IE11? This browser will be around a while for public facing sites, and has some really broken implementations of newer css features like calc (which doesn't work in several scenarios).
Amen. If you are really good at CSS, you might play to that strength. Or, you might play to different strengths. There's probably more than one way to do it in many cases that doesn't hurt the project.
Of course they're different but the article mentions JavaScript as a dependency. SCSS would also be a dependency it just comes into the stack at a different place but it's there nonetheless.
SCSS is not a dependency for the user, this gets rid of the requirement of having JS and having it enabled and any page that works without JS is a better page than one that requires it.
I never did conflate them. I've worked in this industry for 12 years now. I really don't get the disconnect here. I called it a dependency because it is and everyone is trying to tell me it's a different type of dependency. Well no shit but that was never my point to begin with.
The dependency thing was a minor quip at the start, it was never the point...the other 70% of the text was the point and unrelated to my dependency comment. I don't see anyone trying to say that, these comments seem as if my quip was the entire point of my post.
Talk about a tangent over a tiny, unremarkable comment that was meant to be light hearted.
I'm cautious about using CSS to do things that feel like actual behaviours.
For example, the modal that appears when you click on the button actually doesn't do things on "clicking" but focusing. This means if you tab over the button it'll load the modal, then tabbing away means the modal is gone. I can't tab into the content in the modal at all. How does that work with accessibility?
Though I generally dislike the idea of saying content isn't there by making it present in the document but invisible.
Edit - Some of the default behaviours are also a bit pants. In chrome, the form validation on a pattern starts working after I hit submit, then angrily shakes at me for every keypress until it's valid. Then, it ignores invalid input as I type more! Please never use this for phone numbers or credit card numbers. Stop requiring an exact format when what people type varies, and stop telling me I'm putting in something wrong when you ask for a phone number and I give you something that'll connect to me if you type into a phone.
Maxlength is not a validation it's just ignores any more letters you type. Quietly ignoring your users input is probably not what you want.
The "Would you prefer a banana or a cherry?" just shouts "Please match the requested format" if I type "a cherry". I know chrome has nothing else to go on other than "the regex wasn't matched" but it's a bad end user experience.
The tabs example is something I need to tab onto then use left and right, I assume because it's a radio box underneath, not a series of links. Are tabs really radio buttons?
The same for the accordion. Which I've found if I add any tabbable content inside them then I'm focused on a hidden item. Great. Tab onto "tab 1", hit tab, focus has disappeared and I'm now potentially going to click on random items I can't see. This is because although you want to pretend the content isn't there just because it's not visible, it's still there! It's in your document.
Sure, you might not need javascript. But maybe you should still use it.
> The "Would you prefer a banana or a cherry?" just shouts "Please match the requested format" if I type "a cherry". I know chrome has nothing else to go on other than "the regex wasn't matched" but it's a bad end user experience.
Localized custom validation messages for the provided pattern should be added as part of HTML spec. Someone should follow up on that, because it'll probably be too much of a waste of time for me.
<input type="text" id="username" required placeholder="Enter Name"
oninvalid="this.setCustomValidity('Enter User Name Here')"
oninput="setCustomValidity('')" />
where setCustomValidity could provide any text, even localized text from some other source like a DB, potentially, since it's JS. Requires a modern browser, though.
> Sure, you might not need javascript. But maybe you should still use it.
Someone should put together a site that, given a set of browser restrictions the user provides, gives examples of each of these to show the most accessible and standards-compliant version of the code to use, minimizing external libraries required, with and without localization, because not everyone has the resources to provide localized content, unless localization could be provided by a built-in library in the browser or OS, which would be another great project.
Yes, there are sites that provide a matrix of supported browsers, but I don't think that would be as simple to use; developers like copy-and-paste examples, for better or worse, e.g. StackOverflow.
> Someone should put together a site that, given a set of browser restrictions the user provides, gives examples of each of these to show the most accessible and standards-compliant version of the code to use, minimizing external libraries required, with and without localization, because not everyone has the resources to provide localized content, unless localization could be provided by a built-in library in the browser or OS, which would be another great project.
This is something I'd like to see, because apart from a few things I know to look for (tabbing, for example), I don't know how well various devices and settings do with different content. Consistent approaches also help people working on things like screenreaders.
Do any of the examples use Javascript? Or are you saying the site shouldn't use JS for syntax highlighting or whatever, even though that's not the sort of thing it claims JS isn't needed for?
It depends what you mean by "support". There are two things a JavaScript syntax highlighter is doing:
1. Classify each token (whether this is building up an AST or doing something more fuzzy/clever is immaterial for this discussion);
2. Construct a DOM tree (HTML) that is styled (CSS).
Step 1 does not have to happen client-side at all. Step 2 doesn't require JavaScript at all.
I was reading it with javascript disabled and very confused - are there only code snippets and no visualization of the examples? After reading your comment, I went back and enabled javascript and now can see the examples.
The validation examples and input types are a case in point. Even on browsers where they work, the alerts can't be styled and the behaviors can't be controlled.
I think a more important point is that you should design your website to still be functional even if Javascript is disabled.
Why? Because some users, such as those who use Tor, may have legitimate reasons to disable Javascript execution while browsing. Another reason is that Javascript-generated content can screw up your website's SEO when crawlers visit your site.
Using Javascript for your form validation is okay if your form will still work with Javascript disabled. Yes, the user will lose some functionality of not seeing pretty validations, but it's okay if they can still use your site. [1]
Where JS becomes a problem is when it's used in ways where disabling it completely breaks the page... Single page web apps: I'm looking at you.
-----
[1] One way to improve the experience of form input validations for Tor users could be to have both a JS runtime validation and server side validation of your form inputs, and then put the validation messages that both would generate in the same place so that they stay in sync.
I'd argue that single-page apps are a completely new emerging paradigm- the "web-page-as-application" rather than "web-page-as-interface-to-application" (or "webpage-as-hypertext-document", before that.) This isn't to say the previous two paradigms are bad, just that they're solving different problems. In light of that, here are a few responses to your points:
> Where JS becomes a problem is when it's used in ways where disabling it completely breaks the page... Single page web apps: I'm looking at you.
Here's my point: if you disable Javascript and navigate to a URL where a single-page app is hosted, the page isn't broken, your execution environment is. If I make a React app, then ipso facto I'm making an explicit choice to exclude folks that don't want to enable Javascript.
HOWEVER
> I think a more important point is that you should design your website to still be functional even if Javascript is disabled.
There's absolutely room on the Web for all three models: document, interface, and application. And despite my disagreement with this point when it comes to client-side applications, I definitely agree when it comes to Web documents and Web interfaces to server-side applications. (Rails muddied the water something fierce on that last one, which has been the source of uncountable headaches for me.)
I agree with what you're saying, but many, and I mean many, single page web applications get used for things that are essentially Web documents.
If you're building a game or something interactive, I get it. But many SPA's are used to give database-backed forms a pretty skin. It's the overuse of Javascript in this way, and the lack of graceful degradation for forms like this when Javascript is disabled, that I think is beginning to create concern.
you should design your website to still be functional even if Javascript is disabled
True, but irrelevant to the issue of "can you do X on the client side without Javascript?". I can imagine a Javascript form validator that somehow makes the form unusable with Javascript turned off, but I've sure never seen one.
And server-side validation is website 101 stuff that you should always be doing regardless of the front-end technology, not a counter to the many good uses of front-end validation.
I agree. Though sadly keeping your JS validation messages in sync with the ones your server produces can still be a surprisingly high amount of work and headache. Many people can think of the time it takes to build functionality like this as gold plating.
> the alerts can't be styled and the behaviors can't be controlled
It's not clear to me whether that's a problem. Isn't consistent UI a good thing? Isn't it faster to fill the forms correctly if alerts always appear in the same way?
Not really. The errors on Firefox at least, just say "Please match the requested format", which doesn't tell the user where they went wrong for potentially complex requirements.
I've actually spent many hours trying to make them work. You should at least invest a little research time before making proclamations about how you imagine they work.
I now see that we're not really talking about alerts in the 'alert()' sense, but rather about the popups - which are not native widgets (which are better off non-modifiable, in my opinion).
My bad.
Do you know of any good reading material concerning these form validation popups?
From reading on MDN [0], they seem to be browser specific - like the Chrome connection tab [1] - but somewhat customisable via JS.
When submitting a form with an incorrect pattern in Firefox, the validation behavior highlights the relevant textbox in red for a second, and removes its contents. This default behavior gives a very poor user experience.
And if we spent half the time we collectively spend making JavaScript validation programs on making the Firefox validation behaviour better, it'd not be this way.
Perfect enough? Hardly. Errors aren't shown until you submit, giving you no opportunity to fix the mistake while you are there. It also only shows one error at a time. So if you have multiple errors, you fix one, everything is fine, and you don't see an error until you submit again.
> You should do the rest on the backend anyway
Well yes, you should validate on the backend, but you shouldn't wait to only validate on the backend.
This works well enough for getting things done quickly, but it's hardly a good UX, and a far cry from "perfect enough," whatever that means.
Yeah, from the responses, I'm definitely seeing a gulf between "people who've read some random stuff on HN about web design" and "people who actually do web design".
Or you can just respond with a "Bad Input" static HTML page.
Your Back End should be validating the Front End. As it is possible for people to make their own HTTP Post messages to your Back End. This is actually fairly trivial to do if you can use wireshark+curl/hippie/wget.
The you don't need jQuery website had a concrete use case - you need not include an entire library into your website for some simple tasks which makes your website faster.
Though, this site is cool in showing the power of CSS, I am not sure if there is any specific advantage of using CSS over JS to design tabs, sliders, etc. Just use the best tool for the job!
There's definitely some merit to not requiring users to download and run arbitrary and untrusted Turing-complete code. Whether abusing a stylesheet language to achieve that is worth said merit is certainly debatable, but I for one applaud the effort.
It's sad that this site uses SCSS for displaying the rules, I'm using it in production and fully understand it, but it's needlessly abstracting the rules for the sake of a few extra words in each declaration.
That aside, these are some pretty cool examples. Are there ways of doing this with CSS which doesn't screw with my browser back button?
I half agree with you, but one of the real benefits that SASS gives you here is making dependencies more obvious. A named variable like `$slider-height` is much clearer than a random number like `50px`. Yeah, you could put a comment next to every constant in the CSS, but I don't think that's clearer than the SASS alternative.
SCSS variables also make things FAR more maintainable. To change a color, you shouldn't have to change every single line where that color is used.
You update the value where your color variable is defined, and then each style declaration that uses the color variable receives the new value automatically.
There's a "view compiled" button that turns up if you hover the SCSS in codepen. I got through half the doc before discovering it though. I was very surprised to see the ampersand, since I was pretty sure CSS didn't have anything like that.
I absolutely agree! While we can discuss about why SCSS is better, it is more like comparing Volvo with Mercedes. In the end, CSS is the standard, not SCSS. And CSS is evolving and getting better and better.
Some of these are ok, but others are just misusing features for their intended purpose. An input gaining focus is not the same as a click event. Using the :checked peudoselector to keep client-side state is not an alternative to using JS.
Using HTML/CSS hackery where you should be using JS instead creates an anti-SEO, non-semantic mess that causes headaches for others to work on and nightmares for anybody needing to extend or modify functionality.
Don't get me wrong, I love pure CSS solutions and try to use them as much as possible where it makes sense. But sometimes, it definitely doesn't make sense. JS isn't something users or developers should be scared of anymore, it's much better supported and much less intrusive than it used to be.
There is some useful stuff to learn from here, undeniably, but many of these are a bit useless when you compare them with what you would actually typically need on a real site. Yes, the "image slider" is vaguely functional, but really most of the time you will want a lot more control than just the CSS animations allow; similarly, yes, the form validation is a starting point, but normally you would want to customise the error messages and generally fiddle around with it a lot more; I'm not really sure the modal is fit for purpose beyond the most basic use case... etc.
It's fun to see what you can partially achieve without JavaScript, but there is no shame in using JavaScript sensibly to enhance the usefulness of a web site.
What bothers me is that I saw many of these things implemented in CSS only in ~2004. Of course, it required much more code then, including shims for IE 6 and careful slicing of GIFs, but things like tabs, accordion or lightbox were being implemented. Makes me wonder where the last decade went. At least there was a good reason to avoid JS back then: it was slow and often looked worse than CSS hacks.
So, we're all familiar with the fact that imgur requires JavaScript in order to display more than the first few images in a gallery (the 'view more' link executes JavaScript; there's no way to page forward). That's highly annoying, since HTML supports exactly this use case.
It's understandable, though, because we are not imgur's customers: its customers are advertisers, and if we have JavaScript disabled then imgur's customers have less ability to violate our privacy. Thus, it's in imgur's best interest to encourage us to reduce our privacy & security, so that its customers may have their way with our browsers. I can't see that the imgur programmers would care about the fact that they can do amazing things with CSS.
But recently I've discovered that Target's website simply refuses to display products without JavaScript. This is insane: Target are, presumably, in the business of selling things. They ought to want to display a picture of their item and provide me a link to buy it; that's in their best interest. Building that sort of website is easier than building the sort of ecommerce site which cannot even display an image and a link without JavaScript. It should be in Target's best interest to do the right thing.
But it doesn't. Its programmers ought to be interested in a site like youmightnotneedjs.com, but are they? If they didn't bother to build their website properly before, is this likely to encourage them now?
Am surprised no one has pointed out how bad these examples are for accessibility, no pause/play on the slider, hidden content that won't be read by screen readers etc.
I like the idea of using CSS over Javascript where it makes sense but in a lot of these examples it feels hacky.
Safari is the new IE6, stop supporting it and let it die. It will not get any better anyway. If most of your users are on iOS, then make an app for them, it's what Apple also want you to do...
I'm not the only one who think Safari is a joke compared to the competition. While IE6 was much much worse than what Safari is today, I feel like history is repeating itself again. And ES6 support is irrelevant when the main goal is to make sure websites renders and behave correctly, which is more painful for Safari than the other browsers.
I switched from Chrome to Safari 5 months ago. The memory usage in Safari is far more superior than Chrome / Firefox on OS X. Also the CPU usage is relatively low, which means more time on battery for me.
I still use Chrome for development, though.
Safari, is not as bad as IE6 was and anyway no professional front-end developer would make a website that is not working properly on iOS Safari, so it's kinda obvious it will stay supported for a long, long time.
So I would consider what the OP is doing with the CSS, something that might also work on Safari, but with some polyfills.
Oh please. Safari 10 (both desktop & iOS versions) is the only browser with 100% ES6 compatibility. All browsers have some issues (e.g. Chrome still does not support 'sticky' position, Safari hasn't implemented Service Workers, etc), that's part of the multi-vendor / open-standard game.
Safari does have longer release cycle than e.g. Chrome, because Apple provides very uniform / polished support for wide range of devices (Macs, iOS devices, including very old ones such as iPhone 4S).
"Safari is the new IE6, stop supporting it and let it die."
I can only assume you never went through the pain that IE6 delivered... It has been some years now but I still get nightmares about it. It literally made me question at one time if I didn't made the wrong choice to focus on web development.
Apple may be dragging its feet when adapting new api stuff, but the situation is by no means comparable as what the situation was with IE6. Not by a million miles.
IE6 wasn't so bad. It could do everything in 2001 that practically every site needs today, and pretty intuitively if you didn't also support other browsers. But dealing with emerging "standards compliant" browser bugs alongside "the de facto standard" IE6 bugs in the same code, and eschewing table layout before CSS was up to the task, that was a nightmare.
Websites and browsing it self look and feel smoother in Safari compared to Google Chrome. Font rendering in Safari feel like font rendering in the rest of macOS. Not always but sometimes the same website has proper fonts in Safari but looks awkward in Chrome for some reason, I dunno why. Safari has proper GUI (especially settings) that feels at home in macOS instead of some weird web-based settings. Safari uses so much less power for the same usage compared to Chrome.
It's just my anecdotal view, but I believe that Chrome might be better for developers, but websites are made for the users, not the developers, and Safari is far superior on that front.
Chrome/Google has terrible/no support of many browser layout & interaction features, such as CSS Regions & scroll snap points.
Also, Safari is just a much better browser than Chrome. We need to make sure people stop using Chrome and move to the default browser in their environment - Safari & Edge.
If you support the default browser, then you're going to be fine.
The biggest pain point with using :target is that location.hash, which powers it, is a single global state variable - which means you can't nest tabs inside tabs, for example.
The slider has the problem that it cannot dynamically size with the container width, and the amount of slider elements has to be known at compiletime (width: n * 100%).
File upload has the nastiness that you can not really independently style the inputbox with the filename and the button. Chrome has input[type="file"]::-webkit-file-upload-button, but I am not aware of a Firefox/IE solution. Also, you cannot combine the input[type="file"]::-webkit-file-upload-button with a general button selector in the same CSS rule, because Firefox doesn't know the ::-webkit-file-upload-button and discards the whole rule as invalid - you have to double declarate your button styles if you want uniform button look in Chrome. And, even on Chrome, you cannot visually separate the inputbox from the button (e.g. I have a 2-col layout, 320px/col and 16px margin, and I only can mess around with width, padding and margin instead of a clean separation).
To the people who whine about SASS: you can ALWAYS write the resulting CSS by hand, it just takes a boatload of manual typing.
Wow even the Android browser implements it. IE and Safari are lagging again...
I was surprised to see some Linux-style color picker pop up. It looks a lot like the one GIMP uses. Wonder if Firefox implemented that or they depend on something that does, and in the latter case, what's that dependency?
Yuck. I'd take a simple well crafted and maintainable JS solution over an opinionated CSS preprocessor any day of the week.
Preprocessors do nothing but splinter the CSS scene by layering odd syntax over an already creaking/complex CSS spec. Got nothing against compiling CSS in general - postprocessing features related to current and future CSS specs with PostCSS is a great idea. But dividing the community's attention between multiple competing preprocessors while it should have been concentrating on the spec is the worst thing to have ever happened to CSS.
Great things happened to JS when people got behind tools that pushed the language forward while keeping the current and future spec in mind (ES6/Babel). Shame CSS took an alternative approach imo.
Funny that I had to activate javascript in order to see the previews, so, although you don't need JS in real life, you need it to convince people to stop using it.
Kinda like when Dante wrote in Latin about the utility of the Italian language.
A few days ago a saw a talk about CSS animations with RxJS [0] and the gist about CSS only stuff was something like: "Yes, you can do much with CSS only, but it gets ugly fast."
Often you're better of to do a mix of both, because some things that are very complicated in CSS are two-liners in JavaScript.
CSS is great, and by all means use it, while also being aware that you can build so many functional UI components without the additional dependancy.
Maybe you can include a few lines of utility code, or a mixin, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with.
This site is fully copied from youmightnotneedcss.com, an excellent resource for vanilla CSS created by @somebody and @somebodyelse. But this time, we take a look at the power of modern native HTML and g as well as some of the syntactic sugar of DuJour. Because, you might not need scripts for that task at all! (Note: these methods can all be accessible, but the demos may not be. Please take a moment to test these before using in production)
You can add AJAX to your application without writing any javascript code, and you'll get to use REST (with real, honest to God HATEOAS) without even thinking about it:
What are the performance implications of using CSS animations versus Javascript? Say, if you were trying to make an application where page animations need to be extremely fast, like under 2ms for an experiment or test.
CSS for behaviour = un-scalable non-x-platform big ball of crap
I understand why people try so hard to do without JS, but if you want to implement certain UI features, you're SOL. Either give up on them, or embrace the pain.
Note the absurd metric (lines and spaces) to justify how the blown-up version is considered to be smaller. Also note that the article consequently talks about "Node code" even though they are talking about client-side JavaScript.
From the article:
#gulp {
color : #0000ff;
padding : 10px;
}
This CSS takes up 4 lines, and at least 13 spaces. [...]
document.getElementById(‘gulp’).style.color=‘#00f’;
document.getElementById(‘gulp’).style.padding=‘10px’;
This Node code takes up only 2 lines and there are 0 spaces.
Essentially, we are saving lines, spaces, and files (delete
your .css documents!).
One thing I have taken issue with a lot of these different CSS "component" implementations, is the lack of examples on how one would write a good testing suite for these. My first reaction looking at these is not "wow", but more "how can I test this?"
I would honestly be interested in hearing from some people here about how you would go about writing a proper test for these examples. And if the answer is "webdriver screenshotting", I might just shake my head a bit.
It's powerful, flexible, supports classical and functional paradigms and can handle input validation and transformation better than most languages with less code.
It's the only reasonable cross platform client/server language which is well supported.
I can say this for (nearly) any dynamic language like python or ruby. Your second statement is plain wrong however. Take clojure for example which compiles to java bytecode and javascript (cljs) seamlessly. You seem to be a victim of the Blub paradox.
The problem with using CSS for animations is that if the UX designers make a minor change to the spec, you might be forced to rip out the whole thing and redo it in JavaScript.
If you learn JavaScript, you would be learning an imperative language that shares many features with other languages, and you would be, as a resource, more flexible than if you just use CSS for everything.
JavaScript is overused today, even for stupidest things. If needs to be done in JS, you'll see God knows how many frameworks included. This idea reminded me of: youmightnotneedjquery.com
The keyword in all of these sites is the "YOU MIGHT NOT NEED" not "YOU DON'T NEED".. One could theoretically create youmightnotneeda.website and convey that maybe for what you're doing, a website isn't actually needed at all... Doesn't mean it's gospel and everyone should follow it.
I would like to see more sites that use an uppercase title making it so via CSS so I can copy/paste that without having to copy from the source <title> or be lazy and rewrite.
Also, some of them have major accessibility and usability issues.
The image slider for example can't be paused. There's the CSS property "animation-play-state" which could have been used to do this, but that literally freezes the animation, whereas you typically don't care about the animation but don't want the slider to move on to the next image (i.e. finish the transition, then pause).
And of course depending on which browsers you're targetting, many of these are horrendously broken for most of your users.
Yeah, the slider could have an overlay label that toggles a checkbox, where the slider animated is depending upon a checked property, but then the issue is which image is active... that would get fairly complicated with css only.
These examples are all good but I doubt whether you can really avoid javascript. In reality it's more like you can't avoid javascript if you wanted too.
Best of luck making this work across browsers. And even more luck to anybody who uses this, and then has to come back 6 months later to change something.
You might nod near internet, heck, you many not need staying alive, but here we are.
Seriously, after some minimum complexity the ability to create functions and loops its extremely important. As in you don't need a spoon and a knife to feed yourself, but it sure fucking helps.
I remember a time when the coolest thing you could do with JS was mouse trailing bouncy balls. Since then, a lot changed; one of these is that people see JS as salvation from a special hell that doesn't even exist.
That giant ball JS that is included in most sites is absolute nonsense and is not needed in 99% of the cases. We include complete libraries where is should only be a portion.
I'm aware that this is changing, by "compiled" JS - putting together only the required elements - but usually those still have massive overheads.
In my opinion, you should use the tools for what they are the best for. Provide a static, readable HTML first from a backend code - that will run on anything, anywhere; it's accessible, and you've served the main purpose: serving content^1. If you need, add the styling and the animation with CSS. Only after that add the JS layer, which, in my opinion, should mostly be used for data exchange and change triggering.
^1 There are exceptions, there always are; application within the browser, where the main purpose differs from the content delivery. In certain numbers, such as domains, these are the minority; in actual use, it's a different story.
( Imagine a world where the data exchange is not tied together with JS and that we could but other UIs in front of the backends of webapps.. )
A lot of "you don't need Javascript" articles show a bunch of CSS tricks that look flashy and cool but in reality are brittle, limited, and hard to maintain. There's a fair bit of that here, but props for also pointing out some of the new HTML5 features that may have slipped under people's radars. I was aware of the form validation and I think it's a godsend, but I had no idea there's a native color picker now too.
At the start of the article they do state that you might need javascript. The point was to show off things you can do without javascript, not say that you never need it.
Of course it doesn't undermine it's own credibility. If you turn off JS you'll see that the site still works. It's progressively enhanced using JS to give you examples of what is shown here.
