22 ms·

> 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

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

boubiyeah 10y ago
You can if everyone in the team is at least pretty good
- bryanrasmussen 10y ago
  'pretty good' sounds like a doable metric for a small team.
- blauditore 10y ago
  Yeah, and one of the trade-offs is that you need to stick to certain conventions that are somewhat enforced by frameworks.
gildas 10y ago
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.
- mercer 10y ago
  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...
  - boubiyeah 10y ago
    "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.
    - blauditore 10y ago
      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.
mtrn 10y ago
> 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 http://i.imgur.com/lLi3noX.gifv

boubiyeah 10y ago

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

bryanrasmussen 10y ago
'pretty good' sounds like a doable metric for a small team.
blauditore 10y ago
Yeah, and one of the trade-offs is that you need to stick to certain conventions that are somewhat enforced by frameworks.

gildas 10y ago

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.

mercer 10y ago
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...
- boubiyeah 10y ago
  "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.
  - blauditore 10y ago
    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.

mtrn 10y ago

> 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 http://i.imgur.com/lLi3noX.gifv