Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You might not need JavaScript

youmightnotneedjs.com

Post reply on HN
Print view View original

201–210 of 254 posts

Re: You might not need JavaScript

#201

Post by Semiapies »

kelseydh wrote: post #114
Semiapies wrote: post #54

You might not, but you probably do. 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…

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.

Re: You might not need JavaScript

#202

Post by Semiapies »

jasonlotito wrote: post #183
pmlnr wrote: post #66

Earlier quoted context omitted.

The form element type is perfectly enough for frontend validation. You should do the rest on the backend anyway.

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…

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".

Re: You might not need JavaScript

#203

Post by Semiapies »

Cub3 wrote: post #67

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.

The rationale of the site site is simple purism, not mere technical considerations like code complexity, accessibility, history pollution, etc.

Re: You might not need JavaScript

#204

Post by Graphon1 »

acconrad wrote: post #157
nfriedly wrote: post #143

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…

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.

"They were using React to make 1 AJAX request to Foursquare."

Did anyone get fired for that bit of programmer malpractice?

Re: You might not need JavaScript

#205

Post by dralexmv »

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.

Re: You might not need JavaScript

#206

Post by ep103 »

Graphon1 wrote: post #204
acconrad wrote: post #157

Earlier quoted context omitted.

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.

"They were using React to make 1 AJAX request to Foursquare." Did anyone get fired for that bit of programmer malpractice?

The parent comment is a freelancer. The code he corrected was almost certainly from another freelancer. And so the cycle of outsourced code continues.

Re: You might not need JavaScript

#208

Post by auxbuss »

DarkTree wrote: post #196
nfriedly wrote: post #143

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…

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…

There's a name for that: https://en.wikipedia.org/wiki/Wirth%27s_law

Re: You might not need JavaScript

#209

Post by matchagaucho »

G3E9 wrote: post #197
acconrad wrote: post #157

Earlier quoted context omitted.

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.

Or when a project includes jQuery for a single AJAX call - someone somewhere got paid for that ridiculous insight.

Given "fetch" is not yet a standard, jQuery $.ajax is actually a decent cross-browser polyfill.

Re: You might not need JavaScript

#210

Post by dasil003 »

noobermin wrote: post #180
nkassis wrote: post #172

Earlier quoted context omitted.

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 developer…

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.

Post reply on HN