141–150 of 190 posts
That's why a simple thing like http://aurajs.com/ is so good and beautiful.
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…
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?
This sentiment, expressed collectively and somewhat unsympathetically, portrays the entire profession as prioritizing job security over true excellence.
Automation is desirable because it increases efficiency and lowers costs.
Automation is undesirable because it eliminates jobs and automatons are not consumers.
Earlier quoted context omitted.
Calmly, Chicken Little, calmly! Perhaps the sky is not falling after all...
Nope, it isn't. But clinging to frameworks in lieu of actual program design can hamper your ability to design something that doesn't fit neatly into a predefined box.
Earlier quoted context omitted.
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.
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…
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. Well, at the time it was alta-vista not google we turned to. :)…
if(frameworkLess == MadeYourOwnFramework){ this.author = aHipster } On second thoughts, the message seems more like "Go frameworkless, with our new framework."
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…
The biggest cause of bugs before we used React is the fact that the "state" of the app is leaking all over the place. Symptoms were things like looking for dom nodes that didn't exist, events that triggered on code that was no longer active, bugs due to the app being in a state extremely complex to reproduce with crazy conditions all over the place, race conditions... React does many things to mitigate those problems…
I think many programmers don't respect how much complexity is reduced when state isn't leaking all over the place.
Of course there will always be times when you need state, but many times its worth jumping through a few hoops to make things work without state.
EDIT: If programmers learn C so they can think lower level, they should learn Haskell so they can think in terms of side effects, composability, and the advantages of pure functions. Just a reminder, pure functions can be created in any language though some (Clojure, Haskell) enforce purity.
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…
It's a really cool programming technique that unfortunately kills the possibility of statically analyzing the library.
The other interesting thing is that this technique actually makes the JQuery codebase significantly smaller than defining separate methods for each function that appears in the API. So it optimizes for byte-size of apps that use all JQuery functionality, at the cost of apps that use only a little bit of JQuery functionality. And I think this trade-off is why people continue to like no-framework approaches: it is possible for the application author to know what functionality from a library they will need and write code accordingly, but it is not possible for a library author to know what functionality a particular application will need and optimize for that. When you make your library more amenable to tree-shaking compilers, you increase the byte-size of it in the absence of those compilers (through reduced code-sharing or dynamism in your own codebase), which makes you look worse in head-to-head comparisons. When you build your library to be small and clever but assume it'll all be used as one unit, you impose a tax on people who just want some of the functionality and not all of it. And when you use no library at all, then you often end up reinventing parts of the functionality of a JS library poorly, in a less optimized form, and as your app grows it becomes both slower and less productive than if you'd just used one of the leading frameworks.
Earlier quoted context omitted.
CDNs are not magic and there's a lot more than bandwidth to consider: you still have the overhead of doing DNS lookups, additional server connections and response latency before bandwidth enters the picture and the client overhead of decompressing, parsing and processing the response, where CSS will block rendering until it transfers and JavaScript will not only block rendering but also further loads until it finishe…
I find this specious: What modern web app isn't minifying/concatenating it's Javascript and CSS source? All of your concerns are easily remedied via a proper build procedure. And we're talking about, in relative terms, miniscule amounts of data for the web. 33 kb? C'mon now.
In that case, you should learn more about web performance: minification is a useful tool but it's not magic. If you add code to a bundle, you're almost certainly transferring too much data for the initial request — which increases the time before anything can run — and making caching less efficient because any change to your JavaScript invalidates the entire cached object; if you serve it separately, caching works better but you'll incur the latency cost multiple times. Every site has to balance these factors against user capabilities and the site performance targets.
To illustrate why you're being entirely too cavalier, consider Ilya Grigorik's excellent Velocity 2013 presentation detailing exactly what it takes to reliably deliver a rendered webpage in 1 second on mobile:
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...
Note that his performance target is roughly 14KB transfer to deal with the way 3G performs in the real world. If you were thinking about including jQuery, you just blew that budget twice over: a fully compressed, gzipped copy of jQuery 2.0.2 is 29KB. If you concatenated everything, you not only blew your transfer budget but you ensured that none of your JavaScript, even the parts which are entirely self-contained, executes within that performance target.
The point isn't that CDNs aren't useful (they're great), asset packaging isn't good (it's a key tool), or even that jQuery is bloated, but rather that good engineers make decisions based on their performance goals and actual measured user performance rather than flippantly saying “We use a CDN so the site will be fast!” (contra: healthcare.gov) or “everything is minified, so it'll be fast”.