Live data from Hacker News

You might not need JavaScript

youmightnotneedjs.com

191–200 of 254 posts

Re: You might not need JavaScript

#191
post #185

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.

Re: You might not need JavaScript

#192

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.

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

Re: You might not need JavaScript

#193
post #35

Earlier quoted context omitted.

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?

Why would syntax highlighting need JavaScript?

The browser doesn't natively support syntax highlighting (they aren't features of HTML or CSS).

Re: You might not need JavaScript

#194

Earlier quoted context omitted.

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…

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

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.

Re: You might not need JavaScript

#195

Earlier quoted context omitted.

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. My point was hijacked and contorted here.

What everyone's trying to tell you is that your point is beside the point.

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.

Re: You might not need JavaScript

#196

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

Re: You might not need JavaScript

#197

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.

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

Re: You might not need JavaScript

#199
post #105

Earlier quoted context omitted.

You should experiment with these. They are different on different browsers on the same platforms.

Sure, but (unless their GUI is implemented with web technologies for some reason) they generally use native widgets, at least.

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.

Re: You might not need JavaScript

#200

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.

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.

You're talking website 101 stuff. That doesn't pertain to the client-side validation issue, as you should be doing it in every case, anyway.
Post reply on HN