171–180 of 190 posts
That's sort of the big lesson I've learned over the years working with Rails, where too many projects become "Rails apps" rather than apps that use by Rails.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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?
I really like how this demoscene-like mentality of being efficient with our computing power by only applying the minimal, needed complexity has started to get a more mainstream following. The traditional approach of piling on more complexity in the form of abstractions and other things is simply not sustainable. "The fastest way to do something is to not do it at all."
Earlier quoted context omitted.
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 spec…
And for that I found I was happier using a streaming parser and writing event handlers to grab data as it went by and formatting as needed in my handler code.
XSLT might be a good fit if your logic depends on whole-document handling. For example, you need to know how many foo elements there are in order to generate a TOC. Or something where you're explicitly working of irregularities and optional data so you need to have the whole XML doc at hand and apply your transformations "all at once" so to speak.
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…
Code reuse and security depend on developer's skill. You can have both in a home-brew microframework or have neither while using something more popular. Code size, on the other hand, is something you cannot get rid of, once you commit to a certain solution.
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.
This wouldn't be true if he had more JavaScript in his app. The argument doesn't make any sense.
I sense zero respect for people on slow internet connections from you. Yes, it is a real problem. Yes, modern framework-rich development makes the problem worse.
Unless I'm targeting users with bad connections, what's the problem?
Earlier quoted context omitted.
This sentiment, expressed collectively and somewhat unsympathetically, portrays the entire profession as prioritizing job security over true excellence.
Or one could say that it reveals the fatal flaw in our current system of capitalism: Automation is desirable because it increases efficiency and lowers costs. Automation is undesirable because it eliminates jobs and automatons are not consumers.
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…
When I'm working on a deadline it's super easy to just grab x, y & z framework and use the bits I need from each. And in the end, I've added what... 150kb of scripts? Unless I'm targeting users with bad connections, what's the problem?
I highlight this particular pair of sentences because I believe it is very important... I've had too many discussions over why code is 'bad' when what people mean is "doesn't precisely fit this particular idea of how to implement a particular paradigm". What they really mean is that they have a philosophical objection.
This effect has even poisoned programming languages... look at static class in C# - really thats a hack around having omitted free standing variables and functions with no associated object - something completely against the spirit of OO but ultimately necessary, practical and /better/ than shoehorning it into an object (singleton).