Live data from Hacker News

Frameworkless JavaScript

moot.it

81–90 of 190 posts

Re: Frameworkless JavaScript

#81
post #58

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

Bandwidth concerns cut both ways. I typically worry less about my server being able to serve it, than I do about the client having to receive it.

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.

Re: Frameworkless JavaScript

#82

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?

I find the difference to be that each developer is now more productive and can add more function in less time. The profession isn't commoditized, the lower end of the profession gets better, and those with the skills move up a notch and do more and more challenging things. I used to build single-page javascript apps in pure javascript (pre-jQuery), and it was a pain. Once jQuery came along, things were easier. I actu…

I want to believe you, but I also see that a significant portion of the industry is still on CRUD, and people still get really excited about CRUD frameworks.

Re: Frameworkless JavaScript

#83

Earlier quoted context omitted.

This sentiment, expressed collectively and somewhat unsympathetically, portrays the entire profession as prioritizing job security over true excellence.

Indeed. But excellence should mean using the right design for a program, not the Good Enough one advocated by today's fashionable framework. I'm more concerned about collective effects (such as negating the need for analysis and design). This is yet another instance of Worse is Better.

What is worse? What is better? Often shipping something that is 'Good Enough' is better than getting the 'right' (perfect?) design for a program.

In the post, it is clear that moot has a set of concerns that a typical business software developer doesn't have.

So, pick the right tool for your business situation, which may include a framework, or not. But I have to say, as a developer, the times when I thought I had to start from scratch and been right were far fewer than the times I wanted to start from scratch and been wrong.

That may be a testament to my skill, the problems I work on, or both.

Re: Frameworkless JavaScript

#84

Earlier quoted context omitted.

I find the difference to be that each developer is now more productive and can add more function in less time. The profession isn't commoditized, the lower end of the profession gets better, and those with the skills move up a notch and do more and more challenging things. I used to build single-page javascript apps in pure javascript (pre-jQuery), and it was a pain. Once jQuery came along, things were easier. I actu…

I want to believe you, but I also see that a significant portion of the industry is still on CRUD, and people still get really excited about CRUD frameworks.

And yet I haven't seen a convincing web CRUD framework. Have you?

I never did desktop development so don't know about there, but some must have been good.

Re: Frameworkless JavaScript

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

Yes exactly! Modules like in Node.js or libraries as in PHP are a lot more flexible and IMHO better than frameworks.

I coded single page HTML5 apps in JS and Node.js/PHP and avoided any frameworks. A few helper functions are enough and I got a codebase that is easy to read, refactore and the overall code size is small and the execution is fast.

Re: Frameworkless JavaScript

#86
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…

What do you use for the models and routing?

I haven't decided yet. I'm looking at using just the necessary parts of Backbone. Spine was also promising, but seems abandoned.

Re: Frameworkless JavaScript

#87
post #58

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

They want small JS files so their designers can have a 2MB background image...

Re: Frameworkless JavaScript

#88
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…

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.

Re: Frameworkless JavaScript

#89
post #77

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!

Next year? Try right now:

https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework...

Re: Frameworkless JavaScript

#90
Every app has its own framework/DSL.

What a "framework" that isn't your app gives you is the ability to have a common language to describe and build your app's framework/DSL.

The larger the team, the more important a framework becomes. The smaller the team, the easier it is to have "less framework" that you aren't totally defining yourself.

That said, the real benefit in most frameworks is the solved problems. They might not solve them in the most optimal way, but is reinventing the wheel adding the most value in most cases? Nah, probably not.

Then again, sometimes reinventing the wheel is fun.

Post reply on HN