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

111–120 of 190 posts

Re: Frameworkless JavaScript

#111

Post by felxh »

mjackson wrote: post #92

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.

The irony doesn't escape me, but for what it's worth, here is a previous HN discussion about their framework you mentioned:

https://news.ycombinator.com/item?id=6653024

A complaint I remember was that "there isn't much to see here except jQuery"

Re: Frameworkless JavaScript

#112

Post by taeric »

gavinpc wrote: post #109
jamesbritt wrote: post #99

Earlier quoted context omitted.

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.

I've had that question myself more than a few times. If you find any good reads on that question, I'd love to see them!

Re: Frameworkless JavaScript

#113

Post by mattmanser »

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…

I worked somewhere with a similar brilliant framework. It was so much easier, etc., etc. Similar sort of genius auto-loading thing. XML/XSLT. Could slap stuff together fast.

I could make those XSLTs sing man. I made a pivot table out of XSLT, no shit. It was amazingly fast compared to the IE7 javascript engine. Orders of magnitude on masses of data, it actually was amazing.

Know how many times Ive used my crazy mad XSLT skills since?

Never.

In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways.

And because every problem was novel and usually caused by some restriction in the framework you learnt solutions and patterns that you never, ever used again.

And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. They had effectively learnt a completely useless programming language.

Re: Frameworkless JavaScript

#114

Post by bchjam »

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…

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.

Re: Frameworkless JavaScript

#115

Post by fogus »

This sounds like every project that I've ever been on. My co-workers could have written a series of these types of posts:

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

Re: Frameworkless JavaScript

#116

Post by tomkin »

twerquie wrote: post #107
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.

If your argument is "byte size", images matter. There's no getting away from that.

This Marco Polo, Columbus-esc view of "rediscovering the basics" is on ego, not efficiency. You're not discovering new territory by rebuilding the wheel, passing it off as "efficiency".

Bandwidth costs would be the only point I could possibly side with - but as mentioned, you add a JPG or any resource for that matter, and the benefits are gone.

If you are going to go about the busy work of rebuilding the wheel, ask yourself, is there a single user's life you are improving? If you have sacrificed the user experience at all - to save 10kb - then you've disserviced them, while patting yourself on the back needlessly. 10k barely changed my experience on a 14.4-33.6kb modem, so I am unsure of how to make the argument today.

Re: Frameworkless JavaScript

#117

Post by waltsu »

Arnor wrote: post #74
ktusznio wrote: post #70

Earlier quoted context omitted.

This approach is fine for small projects but you'll run into organizational problems once your application's complexity grows. For example, how many event listeners are you going to pile into that $(document).ready callback before you decide to break things up? How do you organize your code if/when you separate your listeners. Another aspect your code doesn't address is fetching/posting data from/to the server, which…

In my current project I have 20 listeners in the ready function. I can see how it would get pretty nasty if I got up to the 100+ range. I think that would be settled by tacking on a listeners method to each of the models: ... $(document).ready(function () { n.Product.listeners(); n.Cart.listeners(); }); ... Ooo... I like that, maybe I'll implement that... Regarding the fetching/posting data, I have an ajax method on…

I hope that you realize that when you've divided your listeners to Product and Cart objects, you've created a "lightweight" Model representation. Next thing you probably need is to fetch those Products and Carts from the server, and you add fetch()-function to them. Soon you'll realize that you've rewritten for example Backbone's Model class. With the exception that your solution has probably more bugs.

Re: Frameworkless JavaScript

#119

Post by badman_ting »

mjackson wrote: post #92

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.

Boooooo.

Re: Frameworkless JavaScript

#120

Post by twerquie »

tomkin wrote: post #116
twerquie wrote: post #107

Earlier quoted context omitted.

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.

If your argument is "byte size", images matter. There's no getting away from that. This Marco Polo, Columbus-esc view of "rediscovering the basics" is on ego, not efficiency. You're not discovering new territory by rebuilding the wheel, passing it off as "efficiency". Bandwidth costs would be the only point I could possibly side with - but as mentioned, you add a JPG or any resource for that matter, and the benefits…

I think you completely missed my point. "Byte size" in javascript is an analogue for slow app execution (page rendering and code paths), not slow downloading or bandwidth costs.

Also, I'm not suggesting we "re-invent the wheel" or code everything from scratch. I'm an advocate for composing your app from small modules. Modern js is incredibly good at this.

Post reply on HN