Hacker News new | past | comments | ask | show | jobs | submit login

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


My framework looks like this: https://github.com/serprex/openEtG/blob/master/dom.js

The code that uses it looks like this: https://github.com/serprex/openEtG/blob/master/views/MainMen...

The site looks like this: http://etg.dek.im

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


Seeing that code I would not hire you.


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.


How would you suggest breaking out of that silo?


Start from scratch/plain ol html. Add dependencies as you need them and for very specific purposes rather than have them "just because"


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


Stay curious. If you know only one framework, read its source and understand every bit of it (or which parts you can ignore and why).


Asking for a friend? ;)


Haha you know it :)


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.


As a developer, I find more pleasure in deleting code than writing it. It might have been hilarious, but I wasn't surprised to read that :)


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.


Exactly this, but hey at least I know what I'm doing and the client is happy!


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.


I've been out of the JS world for a few years, but for a single Ajax call, why wouldn't you use XMLHttpRequest?


jQuery ajax essentially is just a wrapper to XMLHttpRequest.

With some effort, the relevant jQuery methods that act as polyfills could be extracted.

However, a minified version of core jQuery is < 20Kb. A very low technical debt trade-off to support 99% of browsers.


Why would you care about IE8 - 9 or whatever other browser you might be thinking about that has probably an infinitesimal market share?


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.


More than hilarious, I find it a serious skill manifestation.


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.


I like the idea of "patch golf". If only people would at least do a diff before they commit to spot gratuitous reformatting or accidental changes :-(


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.

[1] also, git surgically precise patch mindset helped too.


A very proud moment for me recently was when someone ran git stats and it showed I'd deleted more code than I'd written. It was glorious.


Lazyness is a virtue for software engineers in my opinion.


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.



I've been a Frontend Dev for almost 5 years now. I feel a large part of performance is knowing when and where to remove unnecessary JS.


Of course: The important thing about a tool is not just to know how to use it, but also when and when not to.

Nice example.


I just sent an email to my "favourite customer", recommending that they hire you!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: