Hacker News Reader

Comment by blauditore | Hacker News Reader

> You can't write serious applications in vanilla JavaScript without hitting a complexity wall.

This somewhat annoys me. You can definitely do it.

Sure, it's easier, more comfortable, safer and quicker to use something like React. But you can still do some modularization that scales reasonably well without it.

I've been working on an app and spent a lot of time looking into frameworks to handle its complexity but ended up sticking to vanilla JS to keep more control, especially for detail optimizations.

View on HN

> I've been working on an app and spent a lot of time looking into frameworks to handle its complexity but ended up sticking to vanilla JS to keep more control.

On a recent hackathon, I wanted to implement instant search and ended up using mostly plain javascript for this reason. Not pretty, but worked: http://i.imgur.com/lLi3noX.gifv

I agree. Ten years ago, writing application in vanilla JS was hard because of the browser incompatibilities. Today, browser vendors really do an effort to avoid such issues. Furthermore, today the DOM API is very well documented and, over time, I find it getting easier to learn and use.

I agree that it's become feasible, but even for relatively 'light' scripting my experience is that already very soon something like jQuery becomes worth using despite the increase in payload size.

For example, I'm currently working on a project with mostly plain js, and I've already had to spend quite a bit of time adding code to make relatively basic things work across browsers (including mobile).

Even though it's much less work than it used to be, it's still extra time and code that others will now also have to understand. And who knows what other browser issues linger or will pop up as more features are added!

The worst part is that if I'd be allowed to lazy load some of the images and make a few small other optimizations, I would've shaved off enough Kb's to load multiple version of jQuery...

"The worst part is that if I'd be allowed to lazy load some of the images and make a few small other optimizations, I would've shaved off enough Kb's to load multiple version of jQuery..."

We really need to stop comparing the size of JS and images. Images do not block the app while JS often block it in many ways: download, parsing, slow executing at first (JIT), GC pauses.

It's truly apples and oranges.

Also, hard limits on download size seem silly to me. Either it's worth spending those couple kb for jQuery or it's not, but you shouldn't need to compensate for it by reducing payload in other places.

You can if everyone in the team is at least pretty good

'pretty good' sounds like a doable metric for a small team.

Yeah, and one of the trade-offs is that you need to stick to certain conventions that are somewhat enforced by frameworks.

Reply on news.ycombinator.com