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

91–100 of 190 posts

Re: Frameworkless JavaScript

#91

Post by camus2 »

nailer wrote: post #17
onion2k wrote: post #4

Suggesting that frameworks are too complicated because they "add tens of redundant methods, adding complexity for the end user" is ridiculous. The number of methods in something doesn't always add to the complexity - in a lot of cases a framework vastly reduces the difficulty of using something by abstracting away the hard stuff so the user doesn't need to worry about it. That's pretty much the point of a framework.…

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…

+1 for ractive. If all one needs is data binding , Ractive is enough. Angular is too complexe and too heavy in my opinion(though i like its expression language).

Re: Frameworkless JavaScript

#92

Post by mjackson »

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.

Re: Frameworkless JavaScript

#94

Post by owenversteeg »

It seems that a large motivation to not use JS frameworks is their large size. Of course, the same can be said for CSS - the frameworks are quite large. Unfortunately, since most developers don't interact with CSS as much, people typically ignore the fact that Bootstrap and Foundation are 130kb and 150kb respectively - at the same time they complain about a 24kb JS library's size.

This inspired me to create Min, a 995 byte CSS framework: http://minfwk.com

Re: Frameworkless JavaScript

#95

Post by dodyg »

nailer wrote: post #17
onion2k wrote: post #4

Suggesting that frameworks are too complicated because they "add tens of redundant methods, adding complexity for the end user" is ridiculous. The number of methods in something doesn't always add to the complexity - in a lot of cases a framework vastly reduces the difficulty of using something by abstracting away the hard stuff so the user doesn't need to worry about it. That's pretty much the point of a framework.…

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…

+1 Damn right. I love Ractive.js. I could train my developers by pointing them to the interactive tutorial and they can pick it up in two hours or so. There's very few concepts to learn.

We use it with jQuery, PubSub and TypeScript.

Re: Frameworkless JavaScript

#96

Post by dodyg »

nawitus wrote: post #62
nailer wrote: post #51

Earlier quoted context omitted.

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

I stand corrected. I thought you needed ES6 for that, but apparently ES5 is nearly enough. I didn't read about Ractive.js's magic mode. It's not automatic data-binding either, according to the docs[1]: 'Magic mode only works with properties that Ractive already knows about.' 1. http://docs.ractivejs.org/latest/magic-mode AngularJS works with properties that it doesn't know about, if you use $apply.$scope.

The thing is it's better set things manually so the boundary between your DOM data and other parts of the application become clear. There's no chance of mistaking this.set('keypath', data) with something else.

Re: Frameworkless JavaScript

#97

Post by jdewald »

coldtea wrote: post #60
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 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 developers then have to learn your new "lightweight templating language", "lightweight database mapper", "lightweight MVC layer", and what have you (which now you have to support even though it's not core to what your application does, but is just a support layer).

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.

Re: Frameworkless JavaScript

#98

Post by collyw »

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…

Prototypes always end up in production, framework or not.

Re: Frameworkless JavaScript

#99

Post by jamesbritt »

cdata wrote: post #52

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 with…

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, and was fun to work with. URLs mapped to classes and methods; example.com/foo/bar basically located and loaded the Foo class and invoked the bar method. Domains were used to select "skins": XSLT files transformed the output. Internally it was URLs and XML all-around, making it easy to grab and verify data.

(I realize that describing an application framework using the words "Java", "XML", and "XSLT" might cause some to flinch. Believe it or not this was a really, really sweet tool. I was lucky to work with some very smart people who wrote very good code. We took some liberties with how XML was handled for some interesting parsing advantages. Not a fan of XSLT, but I learned some useful coding techniques.)

Teaching this to bright and motivated developers was not hard. It ran on relatively low-powered commodity hardware and customers loved it. Everyone was happy.

Then the company was acquired, and the new bosses decided that they didn't want to have to train new devs on some hand-rolled framework. J2EE and EJB become the new frontier.

Yes, it was easier to find devs who already knew about EJBs, WAR files, and so on. Was it worth it? No. In this case they would have been better served keeping the old framework. It was just better.

If your company is using custom tools and you are concerned that this will make it harder to bring on new developers consider how your tools tack up against what's publicly available. Maybe the better choice would be to open-source what your're using, or just take the hit of training people when they get hired.

If you make things too easy for run-of-the-mill developers you may end up with run-of-the-mill developers.

Re: Frameworkless JavaScript

#100

Post by d4nt »

SkyMarshal wrote: post #66
cdata wrote: post #52

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 with…

The other big benefit of popular frameworks to businesses is that they're more likely to reach maturity faster with more people using, fixing, and contributing to them. With frameworks, bugs, security holes, and performance issues - especially the hard-to-find edge cases and gremlins - once solved are solved forever (more or less), whereas every time you start your own new framework you have to deal with that again.…

This is very true. I once went to work at a .NET company which had built their own ORM and web UI binding framework. It was very nice back in the .NET 1.1 days but ASP.NET MVC, Entity Framework, the .NET base class library and the javascript community gradually overtook us. After a while it became more of a liability than a benefit. We'd never really documented it very well. New people ended up duplicating features and some of the quirkier bugs just never got fixed. Recruiting and retaining staff got hard and we ended up in a local minimum where each new screen was quicker to do in the in-house framework, but overall we were always falling behind.

It helped us to begin with, but my view is you have to factor in what the abandonment cost might be when the industry standard starts pulling ahead of you, and that could be big. As soon as it looks like the industry is settling on a standard way of doing something, start skating to where that puck will be.

Post reply on HN