Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Frameworkless JavaScript

moot.it

Post reply on HN
Print view View original

151–160 of 190 posts

Re: Frameworkless JavaScript

#151

Post by acdha »

antihero wrote: post #69
acdha wrote: post #42

Earlier quoted context omitted.

CDNs are not magic and there's a lot more than bandwidth to consider: you still have the overhead of doing DNS lookups, additional server connections and response latency before bandwidth enters the picture and the client overhead of decompressing, parsing and processing the response, where CSS will block rendering until it transfers and JavaScript will not only block rendering but also further loads until it finishe…

The magic of CDNs is caching. So, if you are using, for instance, the URL "//code.jquery.com/jquery-2.0.3.min.js" on your site, and the user has already visited a bunch of sites which are using that URL for their jQuery (highly likely), it means that there is no re-download because the browser already has the DNS and JS cached. Perhaps one extra hit to check for a 302 (and sometimes not even), so the thing about CDNs…

> So, if you are using, for instance, the URL "//code.jquery.com/jquery-2.0.3.min.js" on your site, and the user has already visited a bunch of sites which are using that URL for their jQuery (highly likely), it means that there is no re-download because the browser already has the DNS and JS cached.

Have you actually measured this? I've found that the results are lot murkier because not every site uses the same CDN or the same version of jQuery, so a user might have a bunch of different copies cached and still need to load the version you use, and many browsers – particularly on mobile – still have very small cache size limits so the fact that they downloaded jQuery yesterday doesn't mean it's still cached when they visit your site again today. This becomes increasingly dubious for any library less popular than jQuery.

This also doesn't help as much as you think for latency: by the time the browser is requesting that copy of jQuery, it already has your site's DNS resolved and almost certainly has at least one connection already established to your webserver. Restarting those processes for another server adds a non-trivial amount of latency – more so for HTTPS — which is acceptable if you're going to be making many requests but might take longer than simply transferring something like jQuery over an existing connection, particularly for wireless users or anyone using SPDY. This is fine for something which doesn't block rendering or which can stream but for something like CSS/JS in the critical path you really need real world monitoring to see how well your CDN is actually performing.

Re: Frameworkless JavaScript

#152

Post by evolve2k »

mjackson wrote: post #92

The very next post on this blog is all about ... drum roll ... a custom framework that the moot team built, after deciding to not use any frameworks. https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework... Sadly, this behavior is very common among those who have a hard time adopting existing libraries/frameworks. In the end, they almost always re-invent their own obscure wheel that does the same job.

Obligatory XKCD http://xkcd.com/927/

Re: Frameworkless JavaScript

#153

Post by coldtea »

jdewald wrote: post #97
coldtea wrote: post #60

Earlier quoted context omitted.

> Not using a JS Framework? Congratulations, you've just built your own ad hoc JS Framework. Suddenly, anyone who joins moot will have to invest tons of effort in your custom framework instead of being able to hit the ground running. That's the framework party line. Not necesarilly true. For one, somebody not familiar with, say, Angular would still have to get to know Angular (a huge task in itself) and then your app…

I've never seen a non-trivial application that is "application code only". Most frameworks weren't built out of thin air, but because of real application needs. Sure they have more than is necessary, but it is often the case in any non-trivial application that you end up writing a bunch of custom common "framework" code which duplicates the work that readily available frameworks (that you avoided using) had. Any new…

>Sure they have more than is necessary, but it is often the case in any non-trivial application that you end up writing a bunch of custom common "framework" code which duplicates the work that readily available frameworks (that you avoided using) had.

There are trivial apps (no need of framework, small enough), medium apps (can use a framework maybe) and serious non-trivial large apps, apps you bet your company on.

The latter are often better to NOT base into a framework. If they do anything novel, and they want to do, they'd hit framework limits. The framework will impose its logic upon your code, whether it fits or not, and you'll have all the baggage of assorted layers it offers you'll feel obliged to use.

>Any new developers then have to learn your new "lightweight templating language", "lightweight database mapper", "lightweight MVC layer", and what have you

That's totally orthogonal. That you don't use a framework, doesn't mean you can handpick any of the popular template language libs, database mapper libs etc. Instead of being constrained by the set the framework authors chose.

That is: libs, instead of frameworks.

>Though I guess the best part is most of these frameworks being discussed came about because an internal team wasn't happy with what was available and decided to roll their own, which eventually became big enough to release as a standalone unit.

That's not ironic in the slightest though. It reinforces what I said: since those teams evaluated whats available and they didn't fit their needs and rolled their one to solve their particular problems they way they want to solve them, what makes third companies think those "hand-rolled" frameworks are a good fit for THEIR needs?

The message to take away, when a company rolls her own framework is not "frameworks are good, I should use theirs", but "they saw it fit to roll their own stuff. Perhaps I should too".

After all, if you're a startup your competitive advantage is your code. You shouldn't constrain it to fit anything external.

Now, if you are a consultant or web designer delivering cookie cutter projects for a company, or an enterprise developer doing some CRUD, by all means use a framework. Especially if you aren't doing anything very creative or original in the first place.

Re: Frameworkless JavaScript

#155

Post by coldtea »

mattmanser wrote: post #113
jamesbritt wrote: post #99

Earlier quoted context omitted.

On the other hand, now that I have had the experience of leading teams of JavaScript developers, I know first hand the value of building a project on top of a common base that is readily familiar, well documented and easy to pick up by outsiders. Yes, but choose wisely. :) Back in the late '90s I worked for a company that had their own home-grown Java Web application framework. It was conceptually clean, ran fast, an…

I worked somewhere with a similar brilliant framework. It was so much easier, etc., etc. Similar sort of genius auto-loading thing. XML/XSLT. Could slap stuff together fast. I could make those XSLTs sing man. I made a pivot table out of XSLT, no shit. It was amazingly fast compared to the IE7 javascript engine. Orders of magnitude on masses of data, it actually was amazing. Know how many times Ive used my crazy mad X…

>In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways.

No, that's like your experience man. Mine has been different, and I've worked with stuff from Portlets, Struts and Webwork (remember those?) to Django and Express.js

Re: Frameworkless JavaScript

#156

Post by coldtea »

peterhunt wrote: post #103

These types of posts are popping up more and more these days. I like to call them "JavaScript luddite" posts: posts that worship single-digit kb apps with zero dependencies as universally good ideas. This type of thinking is going to hold back frontend web development as a whole unless we address it. Disclaimer: I am on the React team. "API first" -- just layer your API on top of whatever you're using to implement it…

>These types of posts are popping up more and more these days. I like to call them "JavaScript luddite" posts: posts that worship single-digit kb apps with zero dependencies as universally good ideas.

So something like "the UNIX way". And that's wrong because?

>Abstraction is an important part of what we do as SW engineers.

Which is why we should be able to handle it and craft it properly, and not outsource it to some ready-made one-size-fits-all framework.

There are other outlets for code reuse, and they are called libraries.

>"Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it (security, dev speed, support etc).

Code reuse? Ever heard of libraries?

In fact adopting a framework makes pretty sure that it will be hard to reuse both best-of-breed third party libraries (because frameworks favor their built-in stuff) and it also makes it pretty sure that your code will not be reusable outside of it, e.g when you move to a better framework. E.g. all those Ember objects will be tied to Embder, and the logic will be tied to Ember logic of doing things.

>By the way, the Retina image on the blog post was 46kb over the wire which is bigger than all the JS in his app.

Beside the point, for one his app is not his blog, and second, a one-page style app can function while some image is loading, but not while the main JS files are.

>"Special needs" -- moot's engineering challenges were not unique, they just didn't like the trendy frameworks.

Moots might not have been, but your startups better be, else you're doing commodity work churning out stuff. In which case, yes, use a framework.

Re: Frameworkless JavaScript

#158

Post by super-serial »

ulisesrmzroche wrote: post #154

On the other hand, if you're on a budget and don't have the money to implement your own solution to single-page web apps, you've gotta make some compromises. And that's where a framework comes in.

I've always thought the opposite while working on my own projects with limited budget...

I don't have enough time to learn all these js framework idiosyncrasies, and learn the way a framework wants me to do things. I know how to separate data from the application code, and use events to communicate between parts of my app. That seems much simpler to me than trying to learn a framework.

Re: Frameworkless JavaScript

#159

Post by ben_mcmahen »

twerquie wrote: post #75
sync wrote: post #3

Not using a JS Framework? Congratulations, you've just built your own ad hoc JS Framework. Suddenly, anyone who joins moot will have to invest tons of effort in your custom framework instead of being able to hit the ground running.

What if, instead of needing a framework, we just wrote tiny modules of functionality and composed them into an application? This is how the nodejs guys are doing this via npm and I must say, it's staggering. The core node "framework" has a tiny API, and the heart of it is simply require() .

This, entirely. You can effectively construct your own framework by combining other pre-established routers, models, and views (plus whatever other modules you might want). You still get many of the benefits of using frameworks (testing, docs), but it's much more flexible and has the potential to be leaner. You still need to establish best practices and a relatively consistent application design, but these are things you'd want to do anyway... even if using Backbone, or whatevs.
Post reply on HN