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

131–140 of 190 posts

Re: Frameworkless JavaScript

#131

Post by Nitramp »

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.

Last I heard, browser vendors are waiting to be able to drop XSLT.

XSLT is a functional language with a very weird syntax, and a very domain specific default mode - transforming XML trees in streaming mode. XSLT was the translation of SGML's DSSSL [1] into an XML syntax, DSSSL is (was?) a subset of Scheme.

XSLT is actually a pretty good tool for streaming "push" templating - writing a stylesheet that generically specifies how to handle certain kinds of elements. It really sucks at "pull" templating, i.e. writing the result and indicating where data from the input should go, how most templating languages work.

It turns out "pull" templating matches the mental model of most people much better, is easier to understand, and is in particular useful for ye olde typical website. On top of that, it inherited XML with all its baggage, and is forever coupled to that one particular data model.

I'd still use XSLT if I had to format something like a book, or a massive manual. Put for formatting programmatic results in a web app, I never would.

[1] http://www.jclark.com/dsssl/

Re: Frameworkless JavaScript

#132

Post by ianstormtaylor »

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

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

Exactly. If this kind of thing seems like your cup of tea check out component[1].

[1]: https://github.com/component/component

Re: Frameworkless JavaScript

#133

Post by ntoshev »

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.

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.

Re: Frameworkless JavaScript

#135

Post by peterhunt »

bad_user wrote: post #130
kllrnohj wrote: post #125

Earlier quoted context omitted.

> "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 ba…

Code reuse or the lack thereof also affects the users, because there is more potential for bugs. Reinventing the wheel may be warranted, the end result may actually be more stable depending on who works on that wheel reinvention, but lets not kid ourselves - every line of code written increases the potential for bugs and there's nothing that affects the user experience more than a broken app. Besides, bytes count is…

+1

We ensure that React is advanced mode compatible and people routinely get pissed at me because I'm a stickler for bytes. But that's because React is a shared core library where it's our job to be small and fast.

When you're building an app, the trade-offs and priorities are different.

Re: Frameworkless JavaScript

#136

Post by pselbert »

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

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

Re: Frameworkless JavaScript

#137

Post by jamesbritt »

nostrademons wrote: post #124
mattmanser wrote: post #113

Earlier quoted context omitted.

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

The same applies to people who learned EJBs and J2EE in 2002 too, right? I remember doing Java web development circa 2006 and the new hotness in the Java world was JSF and Spring. And anyways, Java web development was dying then and all the cool kids were moving to RoR and Django. I remember arguing vociferously against the choice of JSF in my company and advocating for Rails; I finally quit in 2007, and the CEO call…

I think the lesson is that tech is a harsh industry to be in regardless of which tech you choose, and you should count on your skillset being obsolete in 3-5 years regardless.

Also key is to not let what you're told to do at work decide what you're going to learn. Even if your current company is using whatever is the latest and hottest framework you need to be learning other languages, other ways of doing things.

Here's an anecdote: I did some consulting work for an Indian-owned company in the US. I was helping out with some Rails stuff. It was a curious case of out-sourcing reversal. They had a hard time finding devs in India to do Rails because those developers felt that Java and EJB would be better for their resumes so that was the work they went for.

Re: Frameworkless JavaScript

#138

Post by scelerat »

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…

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.

Re: Frameworkless JavaScript

#139

Post by akamaka »

Amen, I agree 100% with this blog post.

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.

Re: Frameworkless JavaScript

#140

Post by jon_kuperman »

pauljonas wrote: post #38
jon_kuperman wrote: post #20

Really interesting post for sure. 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, no…

It's not just the download size and CDN utility in caching JS on the client side for reuse -- on older machines or devices with less than shiny new execute power, all that code make for a sluggish UX experience. Maybe not in seconds, but even a hundred milliseconds can make for a huge difference, even if it's not readily apparent.

If the code is already cached on the device, which I'm assuming it is in most cases. What is it that is slowing down the UX experience?
Post reply on HN