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

71–80 of 190 posts

Re: Frameworkless JavaScript

#71

Post by pka »

So you're mixing view logic (rendering DOM elements, listening to events) with controller logic, and from my experience this is exactly the type of stuff that leads to an unmaintainable mess when your codebase grows.

For one, you can't test your controllers unless you mock the DOM (and nobody is ever gonna waste time doing that). And what happens when you decide to create a mobile version of your app with a new set of touch optimized views? Duplicate all controllers? Then you decide to split a view into two or more independent views. Rewrite that controller logic again. And so on...

This is exactly what MVC frameworks try to help you with, and with good reason. And I'm not even talking about the dozens of other well-tested and carefully designed features you'll probably end up duplicating. Taking everything into consideration, I really don't think smaller file sizes justify all that.

Re: Frameworkless JavaScript

#72

Post by scarecrowbob »

Zelphyr wrote: post #48
aaronem wrote: post #28

Earlier quoted context omitted.

Of course. But no one seems to be suggesting otherwise, that I can see, and for the relatively common case in which one needs quickly to prototype and roll out something which does "fit neatly into a predefined box", a framework is often just the thing.

You touch on the one things that frameworks are actually good for: prototyping. Unfortunately they're never just used for that purpose. The prototype and all the framework cruft is then called "the product" and used as such. And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how…

"And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together."

Is it possible that some of us have an idea about what we're doing, but have to do enough different projects that learning a common framework has enough of a benefit to outweigh writing bespoke code for everything?

I don't feel the need to write a whole language for every problem I need to solve, and I don't generally think of the language functions I don't use on a given project as "cruft".

Re: Frameworkless JavaScript

#73

Post by moron4hire »

Love HN. "I, not knowing your exact requirements and constraints, know better than you what is best for your project. You are a fool for having defied us. At last, my intellectual superiority is proven."

Re: Frameworkless JavaScript

#74

Post by Arnor »

ktusznio wrote: post #70
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…

This approach is fine for small projects but you'll run into organizational problems once your application's complexity grows. For example, how many event listeners are you going to pile into that $(document).ready callback before you decide to break things up? How do you organize your code if/when you separate your listeners. Another aspect your code doesn't address is fetching/posting data from/to the server, which…

In my current project I have 20 listeners in the ready function. I can see how it would get pretty nasty if I got up to the 100+ range. I think that would be settled by tacking on a listeners method to each of the models:

    ...
    $(document).ready(function () {
        n.Product.listeners();
        n.Cart.listeners();
    });
    ...
Ooo... I like that, maybe I'll implement that...

Regarding the fetching/posting data, I have an ajax method on the applicable model. Fortunately, I'm writing the server app as well so I got to make some decisions on that end that simplify the approach (e.g. everything goes through POST, all data comes back as JSON.) I suppose that makes the AJAX acronym imprecise... AJAJ?

Re: Frameworkless JavaScript

#75

Post by twerquie »

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

Re: Frameworkless JavaScript

#76

Post by vjeux »

mietek wrote: post #15

I've just gone through a similar process of reviewing and discarding a number of JavaScript frameworks. I've settled on React, and I can't recommend it enough! React handles mostly the V in MVC, and does an admirable job of it. It even provides a cross-platform event abstraction, which would've saved the author some trouble. http://facebook.github.io/react/ http://facebook.github.io/react/blog/2013/06/05/why-react.ht…

The biggest cause of bugs before we used React is the fact that the "state" of the app is leaking all over the place. Symptoms were things like looking for dom nodes that didn't exist, events that triggered on code that was no longer active, bugs due to the app being in a state extremely complex to reproduce with crazy conditions all over the place, race conditions...

React does many things to mitigate those problems and those classes of bugs nearly dropped to 0.

- The code you write is declarative: you say how you want the dom to look like. This means that you no longer have two pieces: creation and retrieval that need to be kept in sync.

- React manages the life cycle of the components. When the component is no longer being rendered, it is properly destroyed, all the listeners are destroyed ...

- The render function is pure. This means that it is easier to write and unit test.

- The code is organized into small, composable and unit testable modules. By having a lot of small components it makes writing complex bug-free code easier.

- Each component has a very well defined interface. It cannot use anything else without it being obvious. This prevents the creation of big chunks of interdependent modules that are impossible to separate.

- There is a single point for state update. This makes the high risk pieces of code stand out.

In the end, we found that React actually helped us write more reliable app compared to framework-less Javascript code.

Re: Frameworkless JavaScript

#77

Post by dougk16 »

What's interesting to note, for all those disparaging this approach, is that this is how all those other JS frameworks came into being in the first place...developer isn't satisfied with what's out there, rolls their own stuff, and lo and behold it can be generalized to other applications.

I wouldn't be surprised to see a Moot framework in the next year or so!

Re: Frameworkless JavaScript

#78

Post by mattgreenrocks »

al2o3cr wrote: post #67
mattgreenrocks wrote: post #10

Earlier quoted context omitted.

This sentiment, expressed collectively, commoditizes the entire profession. How can you expect to ask for raises if all devs are basically interchangeable? If we've eradicated all notions of design, and follow prescriptive rules of structuring and solving problems that anybody can Google and follow, then what avenues are left to express technical ability? What differentiates you?

"then what avenues are left to express technical ability" I dunno, maybe actually solving problems for clients instead of playing endless rounds of "my JS is smaller than yours"?

This is not about code golf, this is about the widespread automatic use of frameworks in lieu of an analysis/design/build-one-to-throw-away phase.

Re: Frameworkless JavaScript

#79

Post by RussianCow »

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…

How likely is this? Everyone says "highly likely", but it's unclear what that actually means. 20% chance? 80% chance?

I wonder if someone has looked at the number of websites using the same CDN and calculated this probability. I'd be very interested in the results.

Re: Frameworkless JavaScript

#80

Post by oesmith »

I wonder why Google's Closure Compiler hasn't taken off more in the open-source world. At the cost of some mandatory comments to help the compiler, it's able to analyze and remove unused library code from your application.
Post reply on HN