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

161–170 of 190 posts

Re: Frameworkless JavaScript

#161

Post by peterhunt »

nostrademons wrote: post #149
bad_user wrote: post #130

Earlier quoted context omitted.

Code reuse or the lack thereof also affects the users, because there is more potential for bugs. Reinventing the wheel may be warranted, the end result may actually be more stable depending on who works on that wheel reinvention, but lets not kid ourselves - every line of code written increases the potential for bugs and there's nothing that affects the user experience more than a broken app. Besides, bytes count is…

Tree-shaking optimizations aren't a magic bullet. I argued for about a year and a half to get Google Search to use JQuery, but it turned out to be a complete non-starter because the way the JQuery library is constructed is not amenable to compilation or static analysis. JQuery often dynamically assigns methods to the JQuery object by building a base function and then customizing it with some data-driven properties, t…

I think lodash is doing this the right way: https://npmjs.org/browse/keyword/lodash-modularized

Re: Frameworkless JavaScript

#162

Post by super-serial »

jon_kuperman wrote: post #20

Really interesting post for sure. I'm not really seeing the size advantage here. All of the mentioned frameworks are cached on popular CDN's and I just don't think you're really getting much of a win out of creating your own, smaller files. Also, I'm always wary of companies that want to re-invent the wheel as opposed to using open-sourced, well-documented projects. If I start at your company and you use Backbone, no…

I think the author is getting flak for having his own "framework" while writing an article about being frameworkless.

But the "framework" riot.js has just one important function called "observable." It's 60 lines of code that sets up an event system. I have a similar custom event system in my projects and I do not use frameworks. It's not something people will need to Google or ask their coworkers much about. Backbone on the other hand... anyone unfamiliar with it will need to spend a significant amount of time learning it.

Re: Frameworkless JavaScript

#163

Post by spikels »

i_s wrote: post #146
jamesbritt wrote: post #122

Earlier quoted context omitted.

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. Well, at the time it was alta-vista not google we turned to. :)…

To back you up: Backbone and Rails are two examples of popular frameworks that grew out of in-house frameworks. So no, it is not far fetched at all to to think "that a small group of smart developers with business domain knowledge can build fast, lean, code".

Exactly right! Same with PHP (originally "Personal Home Page" scripts for an talented individual) and Djanjo (two talented hackers at small newspaper). Most of today's popular web framework had humble beginnings while many of those promoted by big tech companies have fallen by the wayside.

http://www.php.net/manual/en/history.php.php http://en.wikipedia.org/wiki/Django_(web_framework)#History

Re: Frameworkless JavaScript

#164

Post by vhiremath4 »

fogus wrote: post #115

This sounds like every project that I've ever been on. My co-workers could have written a series of these types of posts: * MVCless GWT * Makeless Builds * Eclipseless Java IDEs * Hibernateless ORMs * Freemarkerless Templating I've seen this story many many times. I'll give you one guess as to how many of these *less solutions were worth the effort put into them.

Is the answer 42?

Re: Frameworkless JavaScript

#165

Post by spikels »

The authors of the recent book "Single Page Web Applications", Mike Mikowski and Josh Powell, took a similar approach - avoiding frameworks and using jQuery and just a few JavaScript libraries. Mike gave good talks on their philosophy at a couple of the HTML5 Dev Confs (available on YouTube). Made a lot of sense to me.

Re: Frameworkless JavaScript

#166

Post by jamesbritt »

i_s wrote: post #146
jamesbritt wrote: post #122

Earlier quoted context omitted.

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. Well, at the time it was alta-vista not google we turned to. :)…

To back you up: Backbone and Rails are two examples of popular frameworks that grew out of in-house frameworks. So no, it is not far fetched at all to to think "that a small group of smart developers with business domain knowledge can build fast, lean, code".

Makes me wonder how many other good frameworks there are out there they just never get released for one reason or another.

I've had people tell me about in-house tools they use, and some sound quite good.

One reason some companies do not release their source is because part of their business is in the licensing of the code. If a client could just take it and have others work on it because it was fundamentally OSS they'd lose that.

Re: Frameworkless JavaScript

#168

Post by mVChr »

asattarmd wrote: post #118

tl;dr They are realtime. They don't want full blown Rest frameworks for just reactive views. So, no AngularJS or EmberJS. What about Knockout.js? It's just 16kb.

Exactly, I'm just waiting for a greenfield project where I can try Knockout + React.

Re: Frameworkless JavaScript

#170

Post by WiseWeasel »

Arnor wrote: post #36

I've used Backbone for a couple projects. Then I used Angular because I liked the two way binding and easy access to history. Still, I generally find that these frameworks get in the way for most of my projects. I tend to use the following structure: (function () { 'use strict' var n; $(document).ready(function () { // Event listeners here $('#some-id').on('click', n.Product.respond_to_some_click); } // Sometimes I o…

Why not have a hashchange listener going to a hash-parsing router function, and make #some-id an anchor to a hash link with slash-separated parameters, or just use Backbone's router to handle your request? Then you don't need to keep track of a bunch of element id references.
Post reply on HN