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.
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.
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.
It's probably best for a business, if you want to give your employees experience architecting a framework instead of just using one, to standardize on something like Angular.js/Ember/React/etc and then encourage/incentivize your employees to become contributors to it. Almost best of both worlds - benefit from using the framework, and employees get valuable experience, resume builders, and connections. Only thing they miss in that scenario is architecting a framework from scratch, which is something only your early employees would have gotten to do anyway.
Indeed. Having seen JS job listings that include rhetoric like "work with our hand-rolled pseudo-framework! it's sort of like Backbone but with a special socket layer baked in specifically for our app!" I can't run away fast enough.
In my experience writing web apps for many years (frontend and backend), you either (1) start off with an existing framework, (2) write your own, or (3) end up with a mess.
You really shouldn't be doing (2) unless you've had several go-arounds with (1). (3) is, of course, undesirable.
The problem with frameworks is that you can't do dead-code elimination with them. The solution to this is to use a *-JavaScript compiler of some kind. This lets you use bits and pieces from all sorts of different places without paying the heavy price of including all the dead code.
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. Abstraction is an important part of what we do as SW engineers. This post describes a particularly leaky abstraction, which is easily fixed.
"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). 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. The lesson to be learned here is that if add a single image you've pretty much blown away any JS savings you would have had.
Another thing: usually multiple server round-trips matter more than bytes down the wire.
"Full control" -- this is a legit reason. Some of the bullet points are indicative of the state of client-side JS tooling though which are fixable.
"Special needs" -- moot's engineering challenges were not unique, they just didn't like the trendy frameworks. This is totally OK, but not a good reason to tell everyone that code reuse is bad.
"Technology lock-in" -- somewhat of a legit reason, but more of a commentary on monolithic architectures than anything else.
>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.
> "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
I would disagree with this within reason. Code reuse affects YOU the developer. Byte size, however, affects your USERS. Things that impact your users are far more important than things that affect your development zen. Obviously the two are not entirely independent and a balance must be reached, but the user is the important person here, not the developer.
Comparing images and javascript in terms of payload size is apples and oranges. Images do not block the rendering of a page, are trivial to decode and display, and do not have long execution paths for the duration of their life.
"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."
Boom Baby!
Sorry, I just love how you picked up on that. Yeah, lets complain about size of our code, but hey look at my pretty high-res image!
"The lady doth protest too much, me thinks".
Anyway, at the end of the day its about creating an experience that gets the job done (and ultimately get more $$$ in your pocket). Many of the problems I see (here and in the office) are debates on which framework is the best for this and that. Though those are good debates to have, one shouldn't sacrifice the end goal for the "proper" software solution.
I recently built a little library for generating slopegraphs in SVG. I could have used d3 and maybe saved a little bit of code but for something straight forward and purposeful like this I think the no dependencies thing works well.
I have also worked on projects that tried to build a framework for everything on their own. Good learning experience but not the best for code stability or predictable dev cycles.
"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
Code reuse and security depend on developer's skill. You can have both in a home-brew microframework or have neither while using something more popular. Code size, on the other hand, is something you cannot get rid of, once you commit to a certain solution.
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.
This wouldn't be true if he had more JavaScript in his app. The argument doesn't make any sense.
I sense zero respect for people on slow internet connections from you. Yes, it is a real problem. Yes, modern framework-rich development makes the problem worse.
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.
I think it's important to distinguish frameworks from libraries. With libraries, your code is the caller; you can compose things as you like, including with your own code for cases not covered by the library. But with frameworks, your code tends to be the callee; you must conform to (and are thus limited by) the assumptions the calling code has baked-in by the framework authors. My sense is that the pain from this inverted directionality is what drives these bespoke frameworks.
Of course. Not using any framework (external or built in-house) would mean that the team didn't find any useful abstractions that could be layered on the raw JavaScript. Very unlikely.
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.
Now, how about CSS? So far, I've reluctantly chosen Bourbon + Neat + Bitters, which are nice, but not ideal. I appreciate the Sass and semanticism (semanticness, semanticitivity) of it all — no more Bootstrap-like class names in my HTML! However, there aren't enough examples of real pages built with these tools.
Thoughtbot, if you're listening, why not publish at least the Sass sources of these webpages?
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 being able to get moderately good results just by joining up those boxes. I don’t think this is a good thing, though. The idea that learning to find your way around a design when you start working on a new project might be considered difficult and not just something everyone routinely does is not a happy one.
>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.
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?
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().
I don't use any 3rd party code for my current work as of now. So yes I have built my own "toolkit". Maybe a vector rendering library wil be required at some point, but I started off on bare bones to see how far you get.
It's not that I am generally against 3rd party code, JavaScript is just a bit special in that case. The quality of JavaScript libraries is just so outright bad that I don't have any use for most of them. I have a personal policy to only include code that satisfies my personal quality standards, if a codebase makes me cringe I will not use it but rather write my own.
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 omit the n variable and just pollute the global namespace because I'm BA like that.
n = {
Product: {
respond_to_some_click: function() {
// Do some stuff
}
},
Cart: {
},
Whatever: {
}
}
}());
This structure keeps things pretty well organized without a real need for a framework. So far this has been a really comfortable alternative to a heavy framework. I can't wait to get it ripped to shreds and see how I can improve :)
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. Further though, using an established framework improves things through the "many eyes" principle - if tens of thousands of people have used a piece of code, chances are it's going to be pretty damn bulletproof and it'll have a swathe of documentation backing it up (as official docs, blog posts, StackOverflow questions, etc). No startup can even dream of competing with that.
Specifically in the case of moot.it, perhaps as a thing that's dropped into a website to provide a discussion forum having tight code is a bonus, but if you're writing something for other people to extend then using a well known framework as a starting point is a very, very obvious choice.
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 data, and when the data changes, the relevant parts of the DOM do.
The 'how to' fits in a tweet, it's backed by a major media company and the lib is 32 kilobytes.
> if you're writing something for other people to extend then using a well known framework as a starting point is a very, very obvious choice.
This is precisely why we chose to build on top of Backbone.js. It has huge market saturation and easily understandable principles, but could benefit a lot from some of the killer features of Angular and Ember.
Rarely does a framework do everything you need. In the eventuality that you create another app you'll want a custom platform to build off of. It simply makes sense to base that custom platform on top of something stable and vetted by the community.
I work on a popular web application that's built on AngularJS, and these are the exact same conclusions that I've come to.
* Code size is a huge issue for us. When something goes wrong, it's terrible to have to dig deep into mountains of code.
* I haven't yet interviewed a developer who truly has a deep knowledge of AngularJS out of the box. There are lots of people who have shipped little projects with it, but at the end of the day, we hire smart guys and train them. Framework knowledge doesn't really matter.
* I might be "hubris" to write your own framework for a small throwaway client project, but when you are heavily invested in your own product, every option is on the table. We borrowed time at the beginning by using Angular, and we are slowly paying it back, one frustrating problem at a time.
It is refreshing to see this post. As someone who has tried, and not really taken to, all three of those frameworks I sympathize.
Stick with what works for you. Shipping code on your own terms is the end goal. The customer viewing the page does not care one iota what framework you are using.
Moot's customers are not the people viewing the discussions; their customer is the developer integrating their code into a website. A framework might be important to them.
If their argument was "We didn't like any of the frameworks so we built moot without one" that'd be great, but they're making the case that all developers would be better off without, and that's pretty damn dubious.
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:
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.
How disappointing, the article is called "Frameworkless JavaScript", but the author uses jQuery for the application. Yeah, I get it, jQuery a library...
File size seems like the biggest concern, but really, how important is that on a dynamic page that needs to load exactly once? And using a CDN it might already be cached anyway.
That being said, I also like clean, minimal JS code.
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, not only is there a good chance I can come in with a good understanding of your code -- but I can easily check on Google for any questions I have. If I start at a company that has built their own, closed-source, custom JS framework -- I'll have to ask internally every time I have trouble figuring something out.
It may be necessary for your product, but to me it always raises a flag when people create their own proprietary version of something that already has been done.
The author points out that they just want two-way databinding, and don't want the entire overhead of Angular. Most of the Angular overhead is directives that you probably would use /anyways/, and are actually just written in Angular.
Ostensibly, you could fork Angular, take out all the custom directives, and end up with a much smaller starting codebase.
But then you'd end up re-implementing a lot of the default Angular directives (like ng-loop), and likely have a buggier application for it.
Great post, needs to be said sometimes that custom code is always going to be smaller and do just enough.
I'm also working on a real-time socket.io app and find that I can keep most of the data model logic on the server, and the front-end is focused on user interactions & rendering data. I do use Backbone but only the Views, but the overall architecture of the front end is clean, simple, and minimal.
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!
>> 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?
As I said here (https://news.ycombinator.com/item?id=7032169) it's usually because of front-end performance. Users are very concerned with performance, and loading a 150kb library doesn't help.
The extra kilobytes translate into seconds at an alarming rate if you're not on Google Fiber, and I've found that in rural NH Bootstrap usually takes 3 seconds to load vs. Min takes 300ms to load. Min (http://minfwk.com) is a 995 byte CSS framework I made to deal with the slow loading times of other CSS frameworks.
it all comes down to load times. because users will leave if a page takes a long time to load, the less code you have to transfer over the wire, the better. it is different from server side code because it must be transferred and executed by the user.
also, this applies heavily to mobile. not everyone has high-speed internet connections or wifi on their phones, so the less data transfer you have, the faster your page will load, and the less likely your user will leave before it's done loading.
[+] [-] cdata|12 years ago|reply
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.
[+] [-] jamesbritt|12 years ago|reply
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.
[+] [-] SkyMarshal|12 years ago|reply
It's probably best for a business, if you want to give your employees experience architecting a framework instead of just using one, to standardize on something like Angular.js/Ember/React/etc and then encourage/incentivize your employees to become contributors to it. Almost best of both worlds - benefit from using the framework, and employees get valuable experience, resume builders, and connections. Only thing they miss in that scenario is architecting a framework from scratch, which is something only your early employees would have gotten to do anyway.
[+] [-] tdumitrescu|12 years ago|reply
[+] [-] scelerat|12 years ago|reply
You really shouldn't be doing (2) unless you've had several go-arounds with (1). (3) is, of course, undesirable.
[+] [-] chongli|12 years ago|reply
[+] [-] peterhunt|12 years ago|reply
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. Abstraction is an important part of what we do as SW engineers. This post describes a particularly leaky abstraction, which is easily fixed.
"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). 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. The lesson to be learned here is that if add a single image you've pretty much blown away any JS savings you would have had.
Another thing: usually multiple server round-trips matter more than bytes down the wire.
"Full control" -- this is a legit reason. Some of the bullet points are indicative of the state of client-side JS tooling though which are fixable.
"Special needs" -- moot's engineering challenges were not unique, they just didn't like the trendy frameworks. This is totally OK, but not a good reason to tell everyone that code reuse is bad.
"Technology lock-in" -- somewhat of a legit reason, but more of a commentary on monolithic architectures than anything else.
[+] [-] coldtea|12 years ago|reply
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.
[+] [-] kllrnohj|12 years ago|reply
I would disagree with this within reason. Code reuse affects YOU the developer. Byte size, however, affects your USERS. Things that impact your users are far more important than things that affect your development zen. Obviously the two are not entirely independent and a balance must be reached, but the user is the important person here, not the developer.
[+] [-] twerquie|12 years ago|reply
[+] [-] sreyaNotfilc|12 years ago|reply
Boom Baby!
Sorry, I just love how you picked up on that. Yeah, lets complain about size of our code, but hey look at my pretty high-res image!
"The lady doth protest too much, me thinks".
Anyway, at the end of the day its about creating an experience that gets the job done (and ultimately get more $$$ in your pocket). Many of the problems I see (here and in the office) are debates on which framework is the best for this and that. Though those are good debates to have, one shouldn't sacrifice the end goal for the "proper" software solution.
Jobs said it best here... http://www.youtube.com/watch?v=FF-tKLISfPE
[+] [-] bchjam|12 years ago|reply
I have also worked on projects that tried to build a framework for everything on their own. Good learning experience but not the best for code stability or predictable dev cycles.
[+] [-] gambler|12 years ago|reply
Code reuse and security depend on developer's skill. You can have both in a home-brew microframework or have neither while using something more popular. Code size, on the other hand, is something you cannot get rid of, once you commit to a certain solution.
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.
This wouldn't be true if he had more JavaScript in his app. The argument doesn't make any sense.
I sense zero respect for people on slow internet connections from you. Yes, it is a real problem. Yes, modern framework-rich development makes the problem worse.
[+] [-] ddebernardy|12 years ago|reply
[+] [-] mjackson|12 years ago|reply
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.
[+] [-] ataggart|12 years ago|reply
[+] [-] felxh|12 years ago|reply
https://news.ycombinator.com/item?id=6653024
A complaint I remember was that "there isn't much to see here except jQuery"
[+] [-] ntoshev|12 years ago|reply
[+] [-] evolve2k|12 years ago|reply
[+] [-] badman_ting|12 years ago|reply
[+] [-] mietek|12 years ago|reply
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...
http://facebook.github.io/react/blog/2013/11/05/thinking-in-...
Now, how about CSS? So far, I've reluctantly chosen Bourbon + Neat + Bitters, which are nice, but not ideal. I appreciate the Sass and semanticism (semanticness, semanticitivity) of it all — no more Bootstrap-like class names in my HTML! However, there aren't enough examples of real pages built with these tools.
Thoughtbot, if you're listening, why not publish at least the Sass sources of these webpages?
http://bourbon.io
http://neat.bourbon.io
http://bitters.bourbon.io
[+] [-] sync|12 years ago|reply
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.
[+] [-] Chris_Newton|12 years ago|reply
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 being able to get moderately good results just by joining up those boxes. I don’t think this is a good thing, though. The idea that learning to find your way around a design when you start working on a new project might be considered difficult and not just something everyone routinely does is not a happy one.
[+] [-] coldtea|12 years ago|reply
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.
[+] [-] mattgreenrocks|12 years ago|reply
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?
[+] [-] twerquie|12 years ago|reply
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().
[+] [-] mrottenkolber|12 years ago|reply
It's not that I am generally against 3rd party code, JavaScript is just a bit special in that case. The quality of JavaScript libraries is just so outright bad that I don't have any use for most of them. I have a personal policy to only include code that satisfies my personal quality standards, if a codebase makes me cringe I will not use it but rather write my own.
[+] [-] Arnor|12 years ago|reply
[+] [-] onion2k|12 years ago|reply
Specifically in the case of moot.it, perhaps as a thing that's dropped into a website to provide a discussion forum having tight code is a bonus, but if you're writing something for other people to extend then using a well known framework as a starting point is a very, very obvious choice.
[+] [-] nailer|12 years ago|reply
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 data, and when the data changes, the relevant parts of the DOM do.
The 'how to' fits in a tweet, it's backed by a major media company and the lib is 32 kilobytes.
[+] [-] pselbert|12 years ago|reply
This is precisely why we chose to build on top of Backbone.js. It has huge market saturation and easily understandable principles, but could benefit a lot from some of the killer features of Angular and Ember.
Rarely does a framework do everything you need. In the eventuality that you create another app you'll want a custom platform to build off of. It simply makes sense to base that custom platform on top of something stable and vetted by the community.
[+] [-] akamaka|12 years ago|reply
I work on a popular web application that's built on AngularJS, and these are the exact same conclusions that I've come to.
* Code size is a huge issue for us. When something goes wrong, it's terrible to have to dig deep into mountains of code.
* I haven't yet interviewed a developer who truly has a deep knowledge of AngularJS out of the box. There are lots of people who have shipped little projects with it, but at the end of the day, we hire smart guys and train them. Framework knowledge doesn't really matter.
* I might be "hubris" to write your own framework for a small throwaway client project, but when you are heavily invested in your own product, every option is on the table. We borrowed time at the beginning by using Angular, and we are slowly paying it back, one frustrating problem at a time.
[+] [-] jbrooksuk|12 years ago|reply
A massive discussion between Backbone.js developer and the developer of Riot.js kicked off. It's an interesting read that's for sure.
You can find the library here https://github.com/moot/riotjs
[+] [-] binarymax|12 years ago|reply
Stick with what works for you. Shipping code on your own terms is the end goal. The customer viewing the page does not care one iota what framework you are using.
[+] [-] onion2k|12 years ago|reply
If their argument was "We didn't like any of the frameworks so we built moot without one" that'd be great, but they're making the case that all developers would be better off without, and that's pretty damn dubious.
[+] [-] sheetjs|12 years ago|reply
backbone -- http://cdnjs.com/libraries/backbone.js/
rainbow -- http://cdnjs.com/libraries/rainbow/
socket.io -- http://cdnjs.com/libraries/socket.io/
[+] [-] crabasa|12 years ago|reply
[+] [-] js4all|12 years ago|reply
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.
[+] [-] nkuttler|12 years ago|reply
File size seems like the biggest concern, but really, how important is that on a dynamic page that needs to load exactly once? And using a CDN it might already be cached anyway.
That being said, I also like clean, minimal JS code.
[+] [-] manuletroll|12 years ago|reply
[+] [-] jon_kuperman|12 years ago|reply
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, not only is there a good chance I can come in with a good understanding of your code -- but I can easily check on Google for any questions I have. If I start at a company that has built their own, closed-source, custom JS framework -- I'll have to ask internally every time I have trouble figuring something out.
It may be necessary for your product, but to me it always raises a flag when people create their own proprietary version of something that already has been done.
Anyway, a great read for sure!
[+] [-] warfangle|12 years ago|reply
The author points out that they just want two-way databinding, and don't want the entire overhead of Angular. Most of the Angular overhead is directives that you probably would use /anyways/, and are actually just written in Angular.
Ostensibly, you could fork Angular, take out all the custom directives, and end up with a much smaller starting codebase.
But then you'd end up re-implementing a lot of the default Angular directives (like ng-loop), and likely have a buggier application for it.
[+] [-] fogus|12 years ago|reply
* 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.
[+] [-] splatcollision|12 years ago|reply
I'm also working on a real-time socket.io app and find that I can keep most of the data model logic on the server, and the front-end is focused on user interactions & rendering data. I do use Backbone but only the Views, but the overall architecture of the front end is clean, simple, and minimal.
[+] [-] dougk16|12 years ago|reply
I wouldn't be surprised to see a Moot framework in the next year or so!
[+] [-] gedrap|12 years ago|reply
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?
[+] [-] owenversteeg|12 years ago|reply
The extra kilobytes translate into seconds at an alarming rate if you're not on Google Fiber, and I've found that in rural NH Bootstrap usually takes 3 seconds to load vs. Min takes 300ms to load. Min (http://minfwk.com) is a 995 byte CSS framework I made to deal with the slow loading times of other CSS frameworks.
[+] [-] ultimatedelman|12 years ago|reply
also, this applies heavily to mobile. not everyone has high-speed internet connections or wifi on their phones, so the less data transfer you have, the faster your page will load, and the less likely your user will leave before it's done loading.
[+] [-] robmcm|12 years ago|reply
[+] [-] adamcw|12 years ago|reply
For desktop users it's less of an issue, but site size matters a great deal to mobile users.
At least that's where I tend to worry about it, not sure if this is the common reason.