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

101–110 of 190 posts

Re: Frameworkless JavaScript

#101

Post by owenversteeg »

gedrap wrote: 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…

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.

Re: Frameworkless JavaScript

#102

Post by nawitus »

dodyg wrote: post #96
nawitus wrote: post #62

Earlier quoted context omitted.

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.

I don't think the model should care about the view. It should be possible to change the model without caring about view, or even knowing if a view exists. A view should be able to use the model, but the model shouldn't care.

Re: Frameworkless JavaScript

#103

Post by peterhunt »

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.

Re: Frameworkless JavaScript

#104

Post by ultimatedelman »

gedrap wrote: 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…

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.

Re: Frameworkless JavaScript

#105

Post by rfnslyr »

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.

It's SO much effort to spend a weekend studying a code base and playing with it. Get over yourself.

Re: Frameworkless JavaScript

#106

Post by andyl »

I've built apps with Backbone, Marionette, Angular, and React. All very interesting and innovative. But for me none of them beats the productivity of a 'component' system built from simple jQuery plugins.

Re: Frameworkless JavaScript

#107

Post by twerquie »

peterhunt wrote: post #103

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…

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.

Re: Frameworkless JavaScript

#108

Post by Zelphyr »

scarecrowbob wrote: post #72
Zelphyr wrote: post #48

Earlier quoted context omitted.

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

Who said anything about writing a whole language? Just know the language you're writing in well enough that you can build something better without a framework than you can with.

Re: Frameworkless JavaScript

#109

Post by gavinpc »

jamesbritt wrote: post #99
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, an…

XSLT gets a bad rap, I guess because it is verbose and rather special-purpose. I do wish that version 2 were more widely deployed.

But hey, XSLT 1.0 runs in like, every browser in the world, and is practically designed for emitting DOM. I wonder why it's not used more often.

Re: Frameworkless JavaScript

#110

Post by jonny_eh »

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.

On top of that, their new knowledge of said framework is not transferrable to their next job.

If someone works on a popular framework, it makes it easier to get the next job.

Post reply on HN