111–120 of 231 posts
I think Angular2/4 already goes into that direction. Afaik it optionally precompiles all templates, which means what ends up in the user-facing HTML/Javascript is not the source but optimized generated javascript from it.
Whilst I am in favour of the optimisation of resources (and use these sources) we are willingly moving the "View Source" model to for profit entities like github. In the way the internet has evolved we really should look hard it the elephant in the room: the DOM is for documents - not for interfaces. IMHO optimisation for javascript is just a short term fad (hopefully) and browsers will adopt a more open approach to…
That ship sailed when we 1) made JS too capable (ability to initiate requests, ability to handle requests instead of the browser, access to too many user actions) and 2) didn't improve the standard input and UI elements enough (sortable, searchable table should be built-in, for example)
"The trend started by minifiers like UglifyJS and continued by transpilers like Babel will only accelerate." Those were predated by Closure Compiler, which was started with Gmail, and Closure Compiler in some ways still doesn't have an equal. Besides being a fully optimizing compiler, it also has a module system for code splitting, and optimization passes designed to move code at the method/property level from initia…
A problem emerges. Some early, sharp thinkers create tools which attack the problem in a high level, abstract, powerful way... but also with the rough edges that come with being early. These tools get a few adopters, but not that many because it is difficult to see the value versus the obvious rough edges.
Then other sharp thinkers, put off by those rough edges, create N new waves of tools which attack the problem less effectively, but more accessibly.
Then eventually, some years later, common practice of the waves of tools will circle back around and start doing the things that that early rave started.
It's easy to criticize the "daily new JavaScript framework" phenomenon along these lines, but I don't think it is specific to JavaScript, nor specific to 2017, and not even specific to software development. It's just part of how we humans work.
Whilst I am in favour of the optimisation of resources (and use these sources) we are willingly moving the "View Source" model to for profit entities like github. In the way the internet has evolved we really should look hard it the elephant in the room: the DOM is for documents - not for interfaces. IMHO optimisation for javascript is just a short term fad (hopefully) and browsers will adopt a more open approach to…
Honest question: apart from nerds, what reason do we have for valuing 'View Source'? I mean, you can't 'View Source' anything of the computer the browser is running on, or the browser itself.
Check Svelte out ( https://svelte.technology/ ). From the docs: "... rather than interpreting your application code at run time, your app is converted into ideal JavaScript at build time. That means you don't pay the performance cost of the framework's abstractions, or incur a penalty when your app first loads."
* Pervasively typed with TypeScript, written in TypeScript, completely first-class. (It is very easy to consume TypeScript base code from JavaScript, but tacking types onto something written without them almost always yields a much lesser experience.)
* Output standards-compliant web components by default. (Perhaps with room to also output some other variation of component, if there is some API aspect where that helps.)
(Distraction for another day: I think the future of SPA development will be web components at the widget/component level, while application frameworks start evolving upward to provide more features around building applications - because there is less for them to do around building components.)
Earlier quoted context omitted.
Indeed, we no longer worry about food, safety and survival and instead our sadness is directed at irrelevant application binary file sizes.
It becomes relevant when one doesn't intentionally interpret it in the wrong level of Maslow's hierarchy.
I think Angular2/4 already goes into that direction. Afaik it optionally precompiles all templates, which means what ends up in the user-facing HTML/Javascript is not the source but optimized generated javascript from it.
Angular 4 does code splitting, but it's bundle size carries a pretty big baseline
Earlier quoted context omitted.
That's only true if you believe focusing things with " substantive effect on consumer response" is the right thing to do. It sounds like a good heuristic in theory, but the practice clearly shows that we ought to be able to do better than that. I mean, if only fraction of the effort that goes towards making things shiny and sexy went towards making them efficient and actually useful, the computing world would be bett…
> That's only true if you believe focusing things with " substantive effect on consumer response" is the right thing to do. I like eating. Which means I like getting paid. Which means the companies I work for have to focus on things like "substantive effect on consumer response" to keep getting money to pay me.
"The trend started by minifiers like UglifyJS and continued by transpilers like Babel will only accelerate." Those were predated by Closure Compiler, which was started with Gmail, and Closure Compiler in some ways still doesn't have an equal. Besides being a fully optimizing compiler, it also has a module system for code splitting, and optimization passes designed to move code at the method/property level from initia…
This seems to be something of a trend in the software library and tool world: A problem emerges. Some early, sharp thinkers create tools which attack the problem in a high level, abstract, powerful way... but also with the rough edges that come with being early. These tools get a few adopters, but not that many because it is difficult to see the value versus the obvious rough edges. Then other sharp thinkers, put off…
[1] http://discuss.joelonsoftware.com/default.asp?joel.3.219431....
elm is a good example.
That said though, since the Elm language is nicely constrained, it seems possible that a future version of the compiler could keep moving quite far in this direction.