Comment by throwanem | Hacker News Reader

Comment by throwanem | Hacker News Reader

I've done exactly what this author advises - that is, build a complex, real-world single-page app using nothing but jQuery and some plugins.

I didn't do this because I wanted to make some kind of point about architecture or overengineering. I did it because, at that time, front-end frameworks weren't a thing, and the phrase "single-page application" hadn't yet been invented. I didn't even know that was what I was building, because it hadn't been formalized as a concept. I just knew I had a problem to solve, a deadline to meet, and a contract to save.

Which I did. And it was terrible.

There's a point to be made about overengineering. If your app takes five seconds to rebuild after a single-line change, maybe there's a problem. But treating that as cause to throw the baby out with the bathwater amazes me in its foolishness. It makes exactly as much sense as saying that, because airplanes very occasionally fall out of the sky, they're not worth having at all.

I've been seeing a lot of this weird nostalgia lately, this technological-romanticist attitude that there was a better time before web frameworks because everything was so much simpler then. Well, I was there, and it was not. The problems were just as complex; the only real difference was that the tooling sucked. Now it doesn't. We no longer have to build complex applications from jQuery and bearskins. Speaking as one who has done so, that is not something to regret, and neither is a situation in which the major complaint we now have about our tools is that they do too much. As far as problems go, that's a really nice one to have!

> If your app takes five seconds to rebuild after a single-line change, maybe there's a problem.

I don't see it as a problem with the app, I see it as a problem with the whole Babel -> Browser compile chain using lots of tiny files and imports.

My Python app which is 10x the size of the javascript one has a startup of 2 seconds. The JS app, is less than 5k lines and has a start up of 10 seconds to compile via Webpack serverside, or 18 seconds if we're doing it inline via JSPM, and compiling client-side.

I can't wait till browsers have native imports, and support all of ES2016. If even one does so, I'll switch to that for development and only compile for production.

> and has a start up of 10 seconds to compile via Webpack serverside, or 18 seconds if we're doing it inline via JSPM, and compiling client-sid

That's crazy, you should check you're not running more stuff through babel than necessary. (Edit: also why are you compiling via Webpack serverside at all, that sounds like a bad idea)?

> I can't wait till browsers have native imports, and support all of ES2016 ...

Same except once we have native imports, I'd happily stop with what Chrome has now/then, give up the rest of ES2016 for not having to have a build step for local dev.

> why are you compiling via Webpack serverside at all, that sounds like a bad idea?

Because it turned out to be faster to handle the compile serverside, then use hot-reloading.

Why are we using Webpack? Well because we use ES2016 for everything. I tried cutting down on the # of Babel transforms used, but some Babel plugins rely on the transform output of others (e.g. decorators/static members relies on ES2015 class transform), and so I ended up having to use 80% of all the 'standard' plugins anyways, plus everything up to stage 0.

The alternative was to go down to 3-4 second compile times, by eschewing everything that isn't implemented natively in Chrome. I rejected it as workable because our codebase was already pretty heavily leveraging decorators, but it's something to think about for other projects.

If you only use Chrome implemented features of ES2015, then all you need to make a build is a linker like Webpack/JSPM.

> That's crazy, you should check you're not running more stuff through babel than necessary.

Ah, I think you're saying this because of my 5k line of code figure for the JS project. I'm not counting dependencies... and some of those dependencies are really heavy, made worse because they load incompatible versions of things (e.g. Fbjs 0.13 vs fbjs 0.15).

The same is true for the Python project though, but Python is simply faster at linking pre-compiled files than Babel is. JSPM-client side is worse because it has to load each file individually in the browser and then check to compile it. Loading Babel itself in the browser via JSPM takes like 2 seconds.

> I'm not counting dependencies... and some of those dependencies are really heavy, made worse because they load incompatible versions of things (e.g. Fbjs 0.13 vs fbjs 0.15).

I think you misunderstood. You aren't supposed to run your dependencies through Babel.

I had the same experience building a SPA with jQuery. Updating the view and keeping it in sync was atrocious.

I also made the mistake of making a non SPA recently, using jQuery on the front end. It's a nightmare. I did this so a friend could collaborate and learn, but I really dread writing code for the front end anymore.

Coming back to the old ways from Angular, Backbone, etc feels like a HUGE step backwards in terms of the amount of time. Like if for some reason I decided to ride a horse instead of drive a car.

I've got through the same pain. There's a reason why all these frameworks arose in the first place: frontend programming without them absolutely sucks.

JS dev is a shitshow because of npm, because of how fast things are moving, because of how many different frameworks and build tools exist. And most of all because of all the hipsterism, using new things because it's cool.

Reply on news.ycombinator.com