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

51–60 of 190 posts

Re: Frameworkless JavaScript

#51

Post by nailer »

nawitus wrote: post #39
nailer wrote: post #17

Earlier quoted context omitted.

I think the 'redundancy' here is more just unnecessary complexity. Eg, the primary value of Angular is binding DOM -> data. As a developer, I want to specify: - The template for the DOM - The data That's all. I don't care about $scope.$apply, a second module system (even if it's better) or anything else I have to read about. Ractive.JS (The Guardian's framework) does this. It's just mustache templates you bind to dat…

Ractive.JS doesn't need $scope.$apply because it uses it's own model system. AngularJS doesn't use it's own model system, the model is a plain old JavaScript object. The author of 'Frameworkless JavaScript' criticizes the Ember way of using a "complex model system". $scope.$apply exist because of limitations in JavaScript. Apparently this will be fixed in ES6, so ES6-version of AngularJS theoretically won't need $sco…

Ractive uses POJSOs. Each binding has a POJSO (ie, an Object, nothing magical, no new inheritance system or unrelated class-based OO system) and a template (in mustache format). That's all.

You can make the binding live specifying 'magic: true' which requires ES5 (a reasonable requirement for modern web apps).

Re: Frameworkless JavaScript

#52

Post by cdata »

As a JavaScript developer who spent much of his early career writing framework-less JavaScript (as many of us did in the not too distant past), the sentiment behind this post really rings true to the way I feel about programming for a client like the browser. Modern frameworks are all young and imperfect in their own ways, every byte counts and JavaScript is certainly powerful and expressive enough to get you by without a framework.

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. The reality I have experienced is this: as your project and team grow, not everyone you work with will hit the ground with the architectural ambition to contribute to or absorb a new paradigm. Many developers will come to the table with useful domain experience related to a specific framework, or a desire to learn a tool that will be useful to them in a future job.

Asking developers to learn your company's proprietary paradigm is asking them to invest time and effort developing a skill that they often can't even use in a side project if they wanted to; putting aside questions of commoditization of the profession, I think that this can be a potential enthusiasm killer for your team mates.

The ability to think beyond the framework and self-solve problems with code is a great skill to engender in a team. That said, the pursuit of that skill often must be balanced with the business need of crafting a product.

Re: Frameworkless JavaScript

#53

Post by SkyMarshal »

mattgreenrocks wrote: post #10
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.

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?

It doesn't commoditize the entire profession, only the 50% of it that is common to every web site or app you ever build. The other 50% is where the artistic license, craftsmanship, business sense, empiricism, and other value-adds of your team comes in.

Re: Frameworkless JavaScript

#54

Post by CmonDev »

Doesn't matter which kind of icing you put on a bad cake, but it can make it look a bit better. Does author suggest we just eat a very small bad cake with no icing on top? Also POJO historically stands for "Plain Old Java Object".

Re: Frameworkless JavaScript

#55

Post by codingdave »

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.

Every non-trivial app will add enough custom code to a framework that new developers have a learning curve.

Re: Frameworkless JavaScript

#56

Post by gavinlynch »

acdha wrote: post #42
sheetjs wrote: post #25

While I agree with the salient point in the article, I disagree with the emphasis on the size of the script. If using a framework reduces headaches and saves developer time, it will be significantly less expensive to use the framework than to roll and host your own solution. ALSO, there exist cheap/free CDNs that host many of these libraries: backbone -- http://cdnjs.com/libraries/backbone.js/ rainbow -- http://cdnjs…

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…

I find this specious: What modern web app isn't minifying/concatenating it's Javascript and CSS source? All of your concerns are easily remedied via a proper build procedure. And we're talking about, in relative terms, miniscule amounts of data for the web. 33 kb? C'mon now.

Re: Frameworkless JavaScript

#57

Post by js4all »

You are going a dangerous way. As long as your team and code base are small, a self-cocked solution has its advantages. But when you use one of the frameworks, your app gets a structure that other developers can easily understand, because they know the concept. They easily find points where to debug and where to breakpoint.

Using a proprietary framework has none of these advantages. Every new developer needs more time to find his way into the code and that time multiplies as your team grows. Just think about this before starting a new project.

Re: Frameworkless JavaScript

#58

Post by gedrap »

>> First, it's about the same size as Moot as a whole (91kb)

I am feeling a bit of a fool to ask that but... what's the obsession with the code size when it comes to client side JS?

Bandwidth? Well, unless you are running at Google's scale, some extra bandwith is much cheaper than the time spent on writing your own solutions to well known and solved problems (and some of the problems you were not aware of yet).

Performance, since more code - more stuff to execute - will take longer? It's good to have performance in mind and maybe benchmarks will tell you that it's X times faster but what will it be once translated to seconds?

Re: Frameworkless JavaScript

#59

Post by SkyMarshal »

Chris_Newton wrote: post #40
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.

Congratulations, you've just built your own ad hoc JS Framework. We used to call that part of software development “design”, and learning basic design skills and becoming familiar with the common strategies and techniques were prerequisites for being a useful developer. Perhaps losing that baseline is an unfortunate side effect of having readily available black box code to do many common jobs in the Internet age and…

In my experience, using a framework and learning design aren't mutually exclusive. Learning a framework often requires studying its source code and grokking how it works, there's simply no better documentation.

Granted that may not be quite at the level of designing your own complete framework from scratch, but imho it's the happiest middle ground between personal skill development and standing on the shoulders of giants that FOSS has enabled.

Re: Frameworkless JavaScript

#60

Post by coldtea »

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.

>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 application code too.

Why not just have them understand the application code only? Since it's tailored to your application it also omits needless features and workarounds for framework issues.

Post reply on HN