22 ms·

Web frameworks are transforming from runtime libraries into optimizing compilers

436 points by p4bl0 9y ago

cryptos 9y ago
I would rather suggest the opposite: the compilers will be moved out of frameworks, because they will become more and more powerful and general purpose, so that there is no need to handle framework specific things. When we have web assembly and compilers like the Kotlin compiler that can translate a high-level language to web assembly, there is little need for framework specific compilation.
bdcravens 9y ago
Isn't the title backwards? (Still seems so after reading the article)
- OJFord 9y ago
  Yes, I agree it's awkward, I think it's meant as: > The new web development frameworks are compilers
cromwellian 9y ago
"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 initially loaded code into deferred loaded code if it is detected to only be used later. You can see this in action with photos.google.com which splits up every UI component, model, and controller into a dependency tree of modules, which are aggressively optimized. When an action needs to fire, only the transitive dependency of reachable code needed to handle it is loaded. The closest external version of this is Malte Ubl's"Splittables" for Closure Compiler (https://medium.com/@cramforce/introducing-splittable-1c882babca7e https://medium.com/@cramforce/introducing-splittable-1c882ba...)
- kolme 9y ago
  Those features are supported in Webpack and other bundlers. Code splitting: https://webpack.js.org/guides/code-splitting/ https://webpack.js.org/guides/code-splitting/ Tree shaking: https://webpack.js.org/guides/tree-shaking/ https://webpack.js.org/guides/tree-shaking/
  - cromwellian 9y ago
    It's not quite the same. It has some aspects of Google's module system in terms of de-duping (our internal version automatically splits up all code referenced in more than one place into a tree of synthetic modules) But Closure's optimizations go far beyond the "tree shaking" described here, which is really about pruning unused module dependencies. Closure does pruning of methods, properties, etc at a fine grained level, moves code at a per-method level between modules, it computes whether functions have side effects and elides unused side-effect-free code, it does type-based optimizations (https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming https://github.com/google/closure-compiler/wiki/Type-Based-P...), the list goes on and on. It's really like having GCC or LLVM for Javascript code. That's one reason why it's slow, because it does far more than the transpilers and minimizers out there. (As many in another, GWT does many of the same things, being a fully optimizing true compiler)
    - lennelpennel 9y ago
      I want to add that you can easily write your own compile pass for the closure compiler as well. All the optimisations described above are just compile passes.
  - coldtea 9y ago
    Only in a very primitive way.
  - pas 9y ago
    https://github.com/webpack/webpack/issues/2867 https://github.com/webpack/webpack/issues/2867 - "Tree shaking completely broken?" It turns out that it basically supported "skip loading of unnecessary ES6 modules", so kind of like a "warn: unused import", but turned into a silence and no-op. Now with Uglify getting the "pure" annotation, and libraries sprinkling that onto their code, it'll help a bit.
TekMol 9y ago
I don't think so. Browsers will catch up with what developers want. We have seen that with ActiveX, Flash, Java applets, jQuery etc. Every time tech was needed because "The browser alone is not good enough" the browser became better and made the additional tech obsolete.
- adamnemecek 9y ago
  Yeah, webassembly is kinda changing this.
- FooBarWidget 9y ago
  Yeah, except it took browsers a decade to get better enough, and the road towards getting better is mired by compatibility problems, requiring tons of expertise to deal with that sort of stuff. But developers want to build useful stuff yesterday, and users demand good experiences the day before yesterday.
  - TekMol 9y ago
    I did build useful stuff yesterday. And I'm happy I never used any of the "additional tech". Because now that stuff still runs today and pays my bills.
- amelius 9y ago
  > Browsers will catch up with what developers want. Developers want everything from JavaScript to C++, Python and Haskell. There's no way a browser can specifically address all what developers want. Therefore browsers should become better virtual machines. Edit: yup, WASM is a good start.
  - giancarlostoro 9y ago
    Sounds like you need to read up just a little bit on Web Assembly which is compiled from anything including C, C++, Rust and just about any language. Including Python and others. Web Assembly will make syntax irrelevant for web scripting and JavaScript entirely optional depending on how much WebASM is allowed to access.
nathell 9y ago
> a small 40MB iOS app What a sad, sad world we find ourselves to live in.
- albertgoeswoof 9y ago
  Indeed, we no longer worry about food, safety and survival and instead our sadness is directed at irrelevant application binary file sizes.
  - vim_wannabe 9y ago
    Drop every other issue right now! /s
  - astrobe_ 9y ago
    It becomes relevant when one doesn't intentionally interpret it in the wrong level of Maslow's hierarchy.
    - wiz21c 9y ago
      Maslow ? You mean the guy behind the obsolete stuff ? Or the guy who let another one torture monkeys ? http://journals.sagepub.com/doi/abs/10.1177/135050849743004 http://journals.sagepub.com/doi/abs/10.1177/135050849743004 https://en.wikipedia.org/wiki/Harry_Harlow https://en.wikipedia.org/wiki/Harry_Harlow
      - deleted 9y ago
        [deleted]
  - ehnto 9y ago
    We can be sad at more than one thing at a time. I am not overly sad about binary file sizes myself, but I wouldn't say they are irrelevant just because other issues exist, and the original comment is just using a turn of phrase. I doubt they really think this is cause for great concern.
    - 9y ago
harwoodleon 9y ago
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 interface building. This should lead to "View source" on an open standard for interface building - which I think React comes close to. I know there are projects around that attempt this, but I am not aware of any real successes - at least in the same way React has grown. The elegance of HTML has been superseded now, because interfaces are rich and packed with features. The DOM design is lacking and slow because of legacy support. If the whole community effort was spent creating a better UI/UX standard (a standard web front end) - compilers would have no business case and i'm not sure they ever should.
- hectorlorenzo 9y ago
  > If the whole community effort was spent creating a better UI/UX standard (a standard web front end) What do you mean by standard? HTML already has a UX/UI standard (technically standard and with some deviations in terms of design implementation depending on the browser). A <button /> is always a button and looks like a button in any browser. The problem is that it looks awful if you are not Stallman. Both Android and iOS have been improving and refining (visually!) their UI elements, but this has not been done in the web, basically because there isn't a huge company calling the shots behind it. If you want to improve that, we are heading in that direction with Web Components, but at the end of the day it's just an abstraction layer over the DOM elements. And I'm not sure I want Google leading the way (with Polymer). EDIT: Some grammar.
  - harwoodleon 9y ago
    HTML has a UX/UI standard for iterating documents. Applications however, are not explicitly catered for. HTML standards for web application development are a bit like putting F1 wheels on a bus. For example : a dashboard is a common interface pattern, but this would (and should) probably never enter the Document Object space.
devveppev 9y ago
> When it comes to eking performance out of hand-authored JavaScript and accompanying runtime libraries, we’ve reached the point of diminishing returns. Are you saying that web developers are writing the best code that they can? That future gains are going to come from more advanced js preprocessors instead of more informed developers? I strongly disagree that we have reached any sort of diminishing returns when it comes to the quality of hand written code. > Between WebAssembly, SharedArrayBuffer and Atomics, and maybe even threads in JavaScript, the building blocks for the next generation of web applications are falling into place. Read the specs for one of these. Read the specs for any of these. Read the specs for js functions you call every day, and image what the native implementation looks like. The web will never approach native performance because w3 has been sabotaging it for a decade. > time to learn how compilers work. I think the author would benefit from learning about how web frameworks work, or perhaps how web specs mandate that your browser works.
- inian 9y ago
  > I think the author would benefit from learning about how web frameworks work, or perhaps how web specs mandate that your browser works. Haha, he is the creator of Ember.js. I think he knows a thing or two about web frameworks ;)
  - sven78 9y ago
    There are a lot of people who create things and learn the hard way what they didn't know at the beginning. Creating Ember and then talking about going back to Flash, says all that needs to be said about his credibility.
  - devveppev 9y ago
    And he has come to the conclusion that he is making an optimizing compiler. Perhaps the reason he thinks web frameworks will help us 'approach native performance' is because he doesn't know what native performance is? Could you really understand web performance if you don't understand native performance?
- vorg 9y ago
kuon 9y ago
elm is a good example.
- kylecordes 9y ago
  Elm is a very good example of a compiler, but (as I recall, unfortunately without information in front of me) it's not that great of an example of doing maximal work at compile time to minimize the size of a runtime support library. I don't remember the kilobytes but they are significant. 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.
  - zachrose 9y ago
    The latest thought on this from the Elm community is that dead code elimination should be done after compilation[1] and that this should be easy[2]. I don't think the OP's main point was about file size optimization though. Elm's killer "optimization" is to remove the mutable parts of JavaScript and add a strong type system that can prevent practically all runtime errors. To achieve that goal the source language is significantly different than the target language. [1]https://github.com/elm-lang/elm-compiler/issues/1453#issuecomment-236917961 https://github.com/elm-lang/elm-compiler/issues/1453#issueco... [2] https://github.com/elm-lang/elm-make/issues/91#issuecomment-205984891 https://github.com/elm-lang/elm-make/issues/91#issuecomment-...
andy_ppp 9y ago
Domain specific languages I suppose are the next cool aid. Or languages with a comprehensive macro system (like Elixir) can bridge the gap between these ways of thinking. This feels very frontend focused though - I'm wondering if there is a more holistic approach. I have an idea for a framework/project, that over web sockets, views the browser as a thin client for a server side representation; commands would be sent from the browser but defined on the server. I haven't decided how this would work yet fully but it would be interesting to do the DOM diff-ing on the server and have the thin client only transfer the changes. This would hopefully make the initial payload extremely small and the changes being transferred minimal as well. Are there any projects that do anything like this currently?
- johanobergman 9y ago
  I made a proof of concept for such a framework. There are some really cool benefits (like automatic server side rendering, really small js bundle, all code on the backend etc.) but falls short for things that require immediate response, such as drag/drop, or text input.
- tim333 9y ago
  Meteor is a little that way although it doesn't DOM diff on the server. It kind of diffs the Mongo database on the server and then updates mini Mongos in the clients where appropriate. Js in the clients then update the DOMs.
- jules 9y ago
  Seaside from Smalltalk. To some extent the original ASP. There is also a PHP framework that does that, but I forgot it's name.
- Bogdanp 9y ago
  Not exactly the same but you might want to check out Ur/Web, Eliom and the standard Racket web server lib.
- randomstudent 9y ago
  Yes. This Elixir library aims to have a virtual DOM on the server and send minimal diffs to the client: https://github.com/grych/drab https://github.com/grych/drab It can already do this for some kinds of diffs, but it doesn't have a full VDOM yet. It basically allows you to build interactive pages without writing any javascript.
TazeTSchnitzel 9y ago
OT, but this jumped out to me: > In the same way that a compiled Android binary bears little resemblance to the original Java source code From what I recall, Java binaries actually look a lot like their source code. They're not human-readable of course, but you can decompile them very easily and get fairly good code back out. This made Minecraft an easy game to mod: just decompile a class, change a line or two, recompile, insert back into the JAR and you're done. Is Android different?
- hn_throwaway_99 9y ago
  Not really. The bytecode format (.dex) is different, but it's straightforward to convert dex files back to jar files, and then decompile the jar and get readable Java source.
  - pjmlp 9y ago
    But it won't be "the original Java source code", specially with ProGuard and more advanced Java constructs, or even if another JVM language is being used.
- pjmlp 9y ago
  That is only true on a naive compilation, that doesn't make much use of language features introduced since Java 7. Many companies make use of bytecode obfuscators to make it harder to translate back. In Adroid not only is obfuscation part of the build process (ProGuard), there is the additional step of converting from Java bytecodes into DalvikVM bytecodes. So if you only have DalvikVM bytecodes, you might translate to something back that looks like Java, but it won't be the original code.
- izacus 9y ago
  Android code goes through ProGuard on release usually, which is an optimizer (and obfuscator if enabled). It usually makes a lot of optimizations on bytecode level which makes decompiled code noticably harder to read.
  - 9y ago
Matthias247 9y ago
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.
- bpicolo 9y ago
  Angular 4 does code splitting, but it's bundle size carries a pretty big baseline
  - kylecordes 9y ago
    Beyond code splitting, I wonder if a future Angular version may do more aggressive compilation as the linked article and much of this discussion describes, to reduce that baseline. I have written quite a lot of Angular code, and I don't think there is really all that much from and application point of view that absolutely requires a large baseline run time. Much of the same experience and application code base (perhaps with some API adjustments now and then, with semver taken very seriously...) could likely be preserved while making Angular work more and more like an optimizing compiler with a small runtime.
    - bpicolo 9y ago
      They're definitely aiming to make use of the closure compiler (which is why they went with Typescript as a default) https://github.com/angular/tsickle https://github.com/angular/tsickle
cohort 9y ago
Check Svelte out (https://svelte.technology/ 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."
- kylecordes 9y ago
  Svelte is quite appealing, especially for the "reusable widget" layer web development. But there are two areas where there's probably room for something else to swoop in: * 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.)
  - rich_harris 9y ago
    Svelte does now offer an option to compile directly to web components, though it's experimental at this time. You could give StencilJS a go - it's web components through and through, and uses Typescript.
  - yesimahuman 9y ago
    This is how we're approaching it with Stencil: https://stenciljs.com/ https://stenciljs.com/
matt42 9y ago
That's funny because all the deep-learning frameworks also did the same move: the API is now just functions building an AST that is then translated by a compiler into parallel cpu or gpu code...
grondilu 9y ago
The author mentions WebAssembly, yet writes at the end : " and a security model that allows us to forget that we run thousands and thousands of untrusted scripts every day." WebAssembly is designed to run in a sandbox. I suppose that does not by itself make it completely safe, but it can not be much worse than the current situation, can it?
- chii 9y ago
  but isn't wasm something that is supposed to be compiled into native binary? Which means if there's a way to trick the compiler to compile something that looks innocuous, but when run (or somehow exploited) that it does something it's not supposed to? In chrome, the process sandboxing is supposed to protect you - it doesn't matter if it's wasm or not. Does other impl. of wasm does similar security-wise?
  - grondilu 9y ago
    > but isn't wasm something that is supposed to be compiled into native binary? No, it compiles into a binary code of its own. That gives it near-native speed, but it's no "hardware-binary" code.
    - chii 9y ago
      ahh, i thought that the binary format is effectively something you (the runtime) translated into actual assembly (to be then executed).
- atonse 9y ago
  I think WebAssembly has a huge expectations problem: What many people think it is: I can compile my JS frameworks as assembly and ship binaries to the browser, that'll run near-native and be more compact. What WebAssembly actually is: a way to compile libraries from other languages in a manner that you can run them in a JS runtime, but with no access to the DOM, etc. (Think of things like shipping a JS based OCR library or a JS based audio-engine that runs at near-native speeds)
lewisjoe 9y ago
Svelte(https://svelte.technology/ https://svelte.technology/) is one similar idea. It’s a framework that compiles down to plain JS before being shipped out to browsers. There’s a couple of concerns though: #1 How are we going to manage browser inconsistencies? We are very much better than what we were when jQuery came out. Yet we aren’t 100% there either. Browser inconsistencies, still do exist and runtime frameworks try to deal with it. #2 I’ll take Svelte as an example. Say, a component written in Svelte is 2 lines long. The compiled JS file of that component is around 200 lines long (verified). Out of these 200 lines of code, almost a hundred lines are repeating units that occur in every component file. By the time my app reaches a hundred components, this extra 100 lines gets multiplied by 100 times. This bloat is exactly what we want to avoid with runtime frameworks. So, let’s think of the simplest solution. Why not ship these repeating units of code as one module/set/block of code, that gets reused in different places? But wait, isn’t that block of code is what we call “Runtime Frameworks” ? I still think compile-time frameworks are the best bet we’ve got. Would be helpful if somebody can throw light on these aspects though.
- rich_harris 9y ago
  Svelte author here. If you're using a bundler integration like rollup-plugin-svelte or svelte-loader (for webpack), those repeating lines of code are deduplicated across components. There's a bare minimum of repetition, and we're in the process of reducing it further. You'd be surprised at just how well it scales! Browser inconsistencies are much less of an issue than they used to be. There are only a couple of places (e.g. listening for both 'input' and 'change' events on <input type='range'>, to satisfy IE and everyone else) where we need to accommodate differences.
  - fron 9y ago
    Just wanted to say that I've been using svelte a bit at work to create widgets that our clients can embed on their websites, and I absolutely love it. Creating svelte components is super easy and consuming them is even easier. Thank you for having the vision, thank you for making it, and thank you for continuing to improve it.
- 9y ago
osteele 9y ago
In 2002, the Laszlo Presentation Server compiled XML with embedded JavaScript to swf (Flash) byte code. [A later version also compiled to HTML. Performant cross-browser dynamic HTML was daunting in 2002.] We considered HTML's “View Source” feature important, so we emulated this by causing the compiler to place a formatted source file in the output asset directory, and to embed a “View Source” popup menu. You could turn this off, and probably would for a deployed app, but the nudge was there.
pdimitar 9y ago
> Native code tends to have the luxury of not really caring about file size—a small 40MB iOS app would get you laughed out of the room on the web. Sure. And then your investor comes knocking on the door, sits down, looks at you judgingly, inhales smoke from his $200 cigar and says that he wants more returns from your startup. And you have no choice and have to put 10+ spy... - errr, advertisement, I meant advertisement! - scripts, and your web app consumes those 40MB easily. Don't act like web development is some small elitist circle where things are done extremely well, are optimized, and are with attention to technical detail. They are not. JS is a shit-show still. Compilers help, I agree. You can't go anywhere without reusable code though. Also known as "runtime frameworks".
curveship 9y ago
Just throwing my side project, Surplus, out there as another example of this strategy (https://github.com/adamhaile/surplus https://github.com/adamhaile/surplus). Surplus compiles JSX into optimized code that produces real DOM elements. The combination of an ahead-of-time compiler plus no virtual DOM layer means that the runtime code only has to do the minimal, truly dynamic work. As a result, Surplus is the fastest framework in Stefan Krauss's latest js-framework-benchmark (http://www.stefankrause.net/wp/?p=431 http://www.stefankrause.net/wp/?p=431). DSLs are powerful, compiler support can make them fast.
holri 9y ago
Is there a compiler for server side code? Producing DDL sql-code, views, templates etc from a more abstracted meta model?
supermdguy 9y ago
I think things are changing. Angular 4 was definitely "compiling" their code, instead of just running it. However, with VueJS growing in popularity, lightweight apps are on the rise again. People are tired of 5-10mb web apps.
noshbrinken 9y ago
> The trend started by minifiers like UglifyJS and continued by transpilers like Babel will only accelerate. Not to be pedantic, but are UglifyJS and Babel "frameworks"? Not a Ember user, so maybe Ember has some sort of built-in source code transformer and that's what the author is referring to? I think the basic idea that JavaScript developers, especially those working in a browser environment, will increasingly write source code that compiles to JavaScript "bytecode" is not a recent idea. A much more nuanced reflection on that idea can be found here: http://composition.al/blog/2017/07/30/what-do-people-mean-when-they-say-transpiler/ http://composition.al/blog/2017/07/30/what-do-people-mean-wh.... With all the hand-wringing about "JavaScript fatigue", it's a little bit sad that prominent JavaScript developers use titles like "Compilers are the New Frameworks". The tone of this title is the tone of a bell ringing for the next round of JavaScript fad musical chairs.
- evilduck 9y ago
  > Not to be pedantic, but are UglifyJS and Babel "frameworks"? The article doesn't make that claim, which kinda invalidates the "pedantry strawman" the rest of your comment is based on.
  - noshbrinken 9y ago
    >...what we call web frameworks are transforming from runtime libraries into optimizing compilers. I took that to mean that the frameworks are doing the optimization. But the article doesn't give examples of the frameworks. The only examples of code transforming optimizations are Uglify and Babel. So I thought maybe these were the things the author has in mind and not actual frameworks. I was genuinely confused and prefaced with the aside about pedantry because questioning these kinds of semantics can come across as pedantic. The second half of my comment stands regardless.
zeveb 9y ago
> Our job now is figuring out how to adapt the ideas of high-performance native code while preserving what makes the web great: URLs, instant loading, and a security model that allows us to forget that we run thousands and thousands of untrusted scripts every day. URLs are indeed part of what makes the web great. So, too, is being able to read a document on any device imaginable, from a desktop with multiple monitors to a VT100 to a Plan 9 terminal window to a laptop to a watch to a phone to the custom OS I'm building in my free time. Non-progressively-enhancing JavaScript kills that entirely. Also, I don't think the security model of the web allows or enables us to forget that we're running thousands (hundreds of thousands?) of untrusted scripts; I think it just encourages us to. Really, we shouldn't forget it at all. The web security model — while nothing to sneer at — has enabled wholesale violations of privacy and the reduction of human beings to marketing data.
z3t4 9y ago
Isn't the JavaScript engine itself doing a good enough job of optimizing the JavaScript code !?
z3t4 9y ago
If you want to make a pure web app without server side "rendering", you should forget about HTML/XML and only use JavaScript and CSS. Managing GUI state in JavaScript sure is boring at first, but the trick is to use functions and abstractions, event listeners/observers, and plugin patterns. Then it becomes fun again, the performance is good, the source code is small, and it's easy to debug. Stop using < and > in your web app code!
floatboth 9y ago
> The trend started by minifiers like UglifyJS and continued by transpilers like Babel will only accelerate. No, the Babel trend is decelerating thanks to ES6 being supported practically everywhere. Minifiers (based on Babel :D) are still used but they're not that necessary thanks to HTTP compression. We have a component model with Custom Elements, encapsulation with Shadow DOM, variables (custom properties) in CSS, JavaScript with classes and modules, and HTTP/2 push to deliver these modules without extra roundtrips. The future is more platform, less tooling.
nickbauman 9y ago
The thing you have to always remember is there is no specific language that is JavaScript.
yorik 9y ago
> Ember has always been driven by the idea that web apps are becoming more and more like native apps over time. Well, this is what people keep telling again and again, as if it was enough to repeat it to make it real, but I still have to see one web application that I would prefer to use over a desktop one. Sure, we have hugely complex webapps, but the browser is a really a shitty environment to think of it as a "platform" to do anything else than to read documents.
- dasil003 9y ago
  > but I still have to see one web application that I would prefer to use over a desktop one. Sure you have, I would make a huge bet you've used a website that you were unwilling to install the app for. On-demand, truly cross-platform app deployment is a huge feature, not to be underestimated.
  - j_s 9y ago
    > I would make a huge bet you've used a website that you were unwilling to install the app for HN!
- aarpmcgee 9y ago
  I think that the Ember community beats this drum because they have no real answer to React Native.
j_s 9y ago
Just let me know which open source web framework has the best batteries-included (as part of the main framework) data grid and I'll be happy.
Animats 9y ago
Yet all this is doing so little. It's not like many people are using WebGL and canvases to do interesting graphical things. Mostly they're just messing with scrolling, popping things up, and fading things in and out. All this machinery is way overkill for what it's used for. (Especially messing with scrolling, badly.)
- cachvico 9y ago
  You'd be surprised how often WebGL comes into play, take those silky smooth animations for example... or, you know, Google Maps.
- chickenfries 9y ago
  Flipboard built their mobile web app in canvas: http://engineering.flipboard.com/2015/02/mobile-web http://engineering.flipboard.com/2015/02/mobile-web
JoshMnem 9y ago
It seems like the less code users have access to, the less control they will have over their computers. Example: it might become harder to block tracking and ads, turning the open WWW into something more like mobile phone apps (which are terrible for the freedom of end users).
- cosinetau 9y ago
  I think that's the very thesis to the free & open source software movement.
- deleted 9y ago
  [deleted]
martin_drapeau 9y ago
Its funny that companies like Google work so hard to make Javascript interpretation so fast. Yet people write in an abstracted dialect that needs to get compiled down to Javascript because of productivity, convenience, sexiness, or whatever else. So many layers... A developer spends a lot of time debugging. Its so fun to write Jasvacript in the console. Yet we need source maps to solve the above problem in order to debug the code we wrote. Some times I feel the amount of engineering we do in defining new frameworks, dialects, transpilers, etc would be better served writing features for our end users. No, we absolutely need that hammer++ to hit that nail.
iamleppert 9y ago
It's crazy to me what amounts to most UI's -- basically forms and buttons, lists of things, images, pages have become so complex. It's like I've died and woken up in a strange, bizarre world where the laws of physics are different, but I still inhabit the same world. Does anyone else feel this way? Is this just how technology works?
- whatever_dude 9y ago
  This is typical of the maturation of any technology platform. What is actually happening is a change from a long-term growing complexity to short-term stable complexity. Historically, building something simple in an HTML page has always been simple. A field here, a button there, you're done. But with increased requirements, that sort of work became exponentially more difficult to maintain. If you have 10 fields each with the same basic functionality, you'd end up repeating the same thing 10 times. If you wanted some complex state management, you're building it all from the ground up. Your code may be "simple" in the sense that you don't need a build tool, preprocessors, or any dependencies to maintain it, but it becomes increasingly difficult to maintain. React, babel, webpack et al can make things much more complicated _to start_, especially for someone not acquainted with it. But the trade off is that things keep more or less the same level of complexity. Adding a feature is easier, duplicating an element or a screen is easier.
  - iamleppert 9y ago
    I disagree with this sentiment and it's tautologically false. Have you ever worked in a mature babel code base? I have worked in many and frequently get contracts to clean them up. I have yet to see a clean one. Can you even point to a clean open source one? The complexity doesn't reach some steady state, it just keeps growing. The argument that something simple needs to be complex because of unknown future needs is a prime example of design based on emotion, not engineering.
- nardi 9y ago
  I think you’re understating the complexity of modern web applications. There are lots of web apps out there that cannot be aptly described as “pages,” or even as simply “UI”.
cachvico 9y ago
What a terrible title. A "web framework" conventionally is the runtime library, e.g. React, or Ruby on Rails. The optimizing compilers are part of the "build tools" or "build chain" or "make system". They weren't ever runtime libraries (except in isolated examples), and the general patterns have been around since the 70s. Yes, it's good to learn how a compiler works.

436 points by p4bl0 9y ago

I would rather suggest the opposite: the compilers will be moved out of frameworks, because they will become more and more powerful and general purpose, so that there is no need to handle framework specific things. When we have web assembly and compilers like the Kotlin compiler that can translate a high-level language to web assembly, there is little need for framework specific compilation.

bdcravens 9y ago

Isn't the title backwards? (Still seems so after reading the article)

OJFord 9y ago
Yes, I agree it's awkward, I think it's meant as: > The new web development frameworks are compilers

cromwellian 9y ago

"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 initially loaded code into deferred loaded code if it is detected to only be used later. You can see this in action with photos.google.com which splits up every UI component, model, and controller into a dependency tree of modules, which are aggressively optimized. When an action needs to fire, only the transitive dependency of reachable code needed to handle it is loaded. The closest external version of this is Malte Ubl's"Splittables" for Closure Compiler (https://medium.com/@cramforce/introducing-splittable-1c882babca7e https://medium.com/@cramforce/introducing-splittable-1c882ba...)

kolme 9y ago
Those features are supported in Webpack and other bundlers. Code splitting: https://webpack.js.org/guides/code-splitting/ https://webpack.js.org/guides/code-splitting/ Tree shaking: https://webpack.js.org/guides/tree-shaking/ https://webpack.js.org/guides/tree-shaking/
- cromwellian 9y ago
  It's not quite the same. It has some aspects of Google's module system in terms of de-duping (our internal version automatically splits up all code referenced in more than one place into a tree of synthetic modules) But Closure's optimizations go far beyond the "tree shaking" described here, which is really about pruning unused module dependencies. Closure does pruning of methods, properties, etc at a fine grained level, moves code at a per-method level between modules, it computes whether functions have side effects and elides unused side-effect-free code, it does type-based optimizations (https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming https://github.com/google/closure-compiler/wiki/Type-Based-P...), the list goes on and on. It's really like having GCC or LLVM for Javascript code. That's one reason why it's slow, because it does far more than the transpilers and minimizers out there. (As many in another, GWT does many of the same things, being a fully optimizing true compiler)
  - lennelpennel 9y ago
    I want to add that you can easily write your own compile pass for the closure compiler as well. All the optimisations described above are just compile passes.
- coldtea 9y ago
  Only in a very primitive way.
- pas 9y ago
  https://github.com/webpack/webpack/issues/2867 https://github.com/webpack/webpack/issues/2867 - "Tree shaking completely broken?" It turns out that it basically supported "skip loading of unnecessary ES6 modules", so kind of like a "warn: unused import", but turned into a silence and no-op. Now with Uglify getting the "pure" annotation, and libraries sprinkling that onto their code, it'll help a bit.

TekMol 9y ago

I don't think so. Browsers will catch up with what developers want. We have seen that with ActiveX, Flash, Java applets, jQuery etc. Every time tech was needed because "The browser alone is not good enough" the browser became better and made the additional tech obsolete.

adamnemecek 9y ago
Yeah, webassembly is kinda changing this.
FooBarWidget 9y ago
Yeah, except it took browsers a decade to get better enough, and the road towards getting better is mired by compatibility problems, requiring tons of expertise to deal with that sort of stuff. But developers want to build useful stuff yesterday, and users demand good experiences the day before yesterday.
- TekMol 9y ago
  I did build useful stuff yesterday. And I'm happy I never used any of the "additional tech". Because now that stuff still runs today and pays my bills.
amelius 9y ago
> Browsers will catch up with what developers want. Developers want everything from JavaScript to C++, Python and Haskell. There's no way a browser can specifically address all what developers want. Therefore browsers should become better virtual machines. Edit: yup, WASM is a good start.
- giancarlostoro 9y ago
  Sounds like you need to read up just a little bit on Web Assembly which is compiled from anything including C, C++, Rust and just about any language. Including Python and others. Web Assembly will make syntax irrelevant for web scripting and JavaScript entirely optional depending on how much WebASM is allowed to access.

nathell 9y ago

> a small 40MB iOS app What a sad, sad world we find ourselves to live in.

albertgoeswoof 9y ago
Indeed, we no longer worry about food, safety and survival and instead our sadness is directed at irrelevant application binary file sizes.
- vim_wannabe 9y ago
  Drop every other issue right now! /s
- astrobe_ 9y ago
  It becomes relevant when one doesn't intentionally interpret it in the wrong level of Maslow's hierarchy.
  - wiz21c 9y ago
    Maslow ? You mean the guy behind the obsolete stuff ? Or the guy who let another one torture monkeys ? http://journals.sagepub.com/doi/abs/10.1177/135050849743004 http://journals.sagepub.com/doi/abs/10.1177/135050849743004 https://en.wikipedia.org/wiki/Harry_Harlow https://en.wikipedia.org/wiki/Harry_Harlow
    - deleted 9y ago
      [deleted]
- ehnto 9y ago
  We can be sad at more than one thing at a time. I am not overly sad about binary file sizes myself, but I wouldn't say they are irrelevant just because other issues exist, and the original comment is just using a turn of phrase. I doubt they really think this is cause for great concern.
  - 9y ago

harwoodleon 9y ago

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 interface building. This should lead to "View source" on an open standard for interface building - which I think React comes close to. I know there are projects around that attempt this, but I am not aware of any real successes - at least in the same way React has grown. The elegance of HTML has been superseded now, because interfaces are rich and packed with features. The DOM design is lacking and slow because of legacy support. If the whole community effort was spent creating a better UI/UX standard (a standard web front end) - compilers would have no business case and i'm not sure they ever should.

hectorlorenzo 9y ago
> If the whole community effort was spent creating a better UI/UX standard (a standard web front end) What do you mean by standard? HTML already has a UX/UI standard (technically standard and with some deviations in terms of design implementation depending on the browser). A <button /> is always a button and looks like a button in any browser. The problem is that it looks awful if you are not Stallman. Both Android and iOS have been improving and refining (visually!) their UI elements, but this has not been done in the web, basically because there isn't a huge company calling the shots behind it. If you want to improve that, we are heading in that direction with Web Components, but at the end of the day it's just an abstraction layer over the DOM elements. And I'm not sure I want Google leading the way (with Polymer). EDIT: Some grammar.
- harwoodleon 9y ago
  HTML has a UX/UI standard for iterating documents. Applications however, are not explicitly catered for. HTML standards for web application development are a bit like putting F1 wheels on a bus. For example : a dashboard is a common interface pattern, but this would (and should) probably never enter the Document Object space.

devveppev 9y ago

> When it comes to eking performance out of hand-authored JavaScript and accompanying runtime libraries, we’ve reached the point of diminishing returns. Are you saying that web developers are writing the best code that they can? That future gains are going to come from more advanced js preprocessors instead of more informed developers? I strongly disagree that we have reached any sort of diminishing returns when it comes to the quality of hand written code. > Between WebAssembly, SharedArrayBuffer and Atomics, and maybe even threads in JavaScript, the building blocks for the next generation of web applications are falling into place. Read the specs for one of these. Read the specs for any of these. Read the specs for js functions you call every day, and image what the native implementation looks like. The web will never approach native performance because w3 has been sabotaging it for a decade. > time to learn how compilers work. I think the author would benefit from learning about how web frameworks work, or perhaps how web specs mandate that your browser works.

inian 9y ago
> I think the author would benefit from learning about how web frameworks work, or perhaps how web specs mandate that your browser works. Haha, he is the creator of Ember.js. I think he knows a thing or two about web frameworks ;)
- sven78 9y ago
  There are a lot of people who create things and learn the hard way what they didn't know at the beginning. Creating Ember and then talking about going back to Flash, says all that needs to be said about his credibility.
- devveppev 9y ago
  And he has come to the conclusion that he is making an optimizing compiler. Perhaps the reason he thinks web frameworks will help us 'approach native performance' is because he doesn't know what native performance is? Could you really understand web performance if you don't understand native performance?
vorg 9y ago

kuon 9y ago

elm is a good example.

kylecordes 9y ago
Elm is a very good example of a compiler, but (as I recall, unfortunately without information in front of me) it's not that great of an example of doing maximal work at compile time to minimize the size of a runtime support library. I don't remember the kilobytes but they are significant. 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.
- zachrose 9y ago
  The latest thought on this from the Elm community is that dead code elimination should be done after compilation[1] and that this should be easy[2]. I don't think the OP's main point was about file size optimization though. Elm's killer "optimization" is to remove the mutable parts of JavaScript and add a strong type system that can prevent practically all runtime errors. To achieve that goal the source language is significantly different than the target language. [1]https://github.com/elm-lang/elm-compiler/issues/1453#issuecomment-236917961 https://github.com/elm-lang/elm-compiler/issues/1453#issueco... [2] https://github.com/elm-lang/elm-make/issues/91#issuecomment-205984891 https://github.com/elm-lang/elm-make/issues/91#issuecomment-...

andy_ppp 9y ago

Domain specific languages I suppose are the next cool aid. Or languages with a comprehensive macro system (like Elixir) can bridge the gap between these ways of thinking. This feels very frontend focused though - I'm wondering if there is a more holistic approach. I have an idea for a framework/project, that over web sockets, views the browser as a thin client for a server side representation; commands would be sent from the browser but defined on the server. I haven't decided how this would work yet fully but it would be interesting to do the DOM diff-ing on the server and have the thin client only transfer the changes. This would hopefully make the initial payload extremely small and the changes being transferred minimal as well. Are there any projects that do anything like this currently?

johanobergman 9y ago
I made a proof of concept for such a framework. There are some really cool benefits (like automatic server side rendering, really small js bundle, all code on the backend etc.) but falls short for things that require immediate response, such as drag/drop, or text input.
tim333 9y ago
Meteor is a little that way although it doesn't DOM diff on the server. It kind of diffs the Mongo database on the server and then updates mini Mongos in the clients where appropriate. Js in the clients then update the DOMs.
jules 9y ago
Seaside from Smalltalk. To some extent the original ASP. There is also a PHP framework that does that, but I forgot it's name.
Bogdanp 9y ago
Not exactly the same but you might want to check out Ur/Web, Eliom and the standard Racket web server lib.
randomstudent 9y ago
Yes. This Elixir library aims to have a virtual DOM on the server and send minimal diffs to the client: https://github.com/grych/drab https://github.com/grych/drab It can already do this for some kinds of diffs, but it doesn't have a full VDOM yet. It basically allows you to build interactive pages without writing any javascript.

TazeTSchnitzel 9y ago

OT, but this jumped out to me: > In the same way that a compiled Android binary bears little resemblance to the original Java source code From what I recall, Java binaries actually look a lot like their source code. They're not human-readable of course, but you can decompile them very easily and get fairly good code back out. This made Minecraft an easy game to mod: just decompile a class, change a line or two, recompile, insert back into the JAR and you're done. Is Android different?

hn_throwaway_99 9y ago
Not really. The bytecode format (.dex) is different, but it's straightforward to convert dex files back to jar files, and then decompile the jar and get readable Java source.
- pjmlp 9y ago
  But it won't be "the original Java source code", specially with ProGuard and more advanced Java constructs, or even if another JVM language is being used.
pjmlp 9y ago
That is only true on a naive compilation, that doesn't make much use of language features introduced since Java 7. Many companies make use of bytecode obfuscators to make it harder to translate back. In Adroid not only is obfuscation part of the build process (ProGuard), there is the additional step of converting from Java bytecodes into DalvikVM bytecodes. So if you only have DalvikVM bytecodes, you might translate to something back that looks like Java, but it won't be the original code.
izacus 9y ago
Android code goes through ProGuard on release usually, which is an optimizer (and obfuscator if enabled). It usually makes a lot of optimizations on bytecode level which makes decompiled code noticably harder to read.
- 9y ago

Matthias247 9y ago

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.

bpicolo 9y ago
Angular 4 does code splitting, but it's bundle size carries a pretty big baseline
- kylecordes 9y ago
  Beyond code splitting, I wonder if a future Angular version may do more aggressive compilation as the linked article and much of this discussion describes, to reduce that baseline. I have written quite a lot of Angular code, and I don't think there is really all that much from and application point of view that absolutely requires a large baseline run time. Much of the same experience and application code base (perhaps with some API adjustments now and then, with semver taken very seriously...) could likely be preserved while making Angular work more and more like an optimizing compiler with a small runtime.
  - bpicolo 9y ago
    They're definitely aiming to make use of the closure compiler (which is why they went with Typescript as a default) https://github.com/angular/tsickle https://github.com/angular/tsickle

cohort 9y ago

Check Svelte out (https://svelte.technology/ 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."

kylecordes 9y ago
Svelte is quite appealing, especially for the "reusable widget" layer web development. But there are two areas where there's probably room for something else to swoop in: * 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.)
- rich_harris 9y ago
  Svelte does now offer an option to compile directly to web components, though it's experimental at this time. You could give StencilJS a go - it's web components through and through, and uses Typescript.
- yesimahuman 9y ago
  This is how we're approaching it with Stencil: https://stenciljs.com/ https://stenciljs.com/

matt42 9y ago

That's funny because all the deep-learning frameworks also did the same move: the API is now just functions building an AST that is then translated by a compiler into parallel cpu or gpu code...

grondilu 9y ago

The author mentions WebAssembly, yet writes at the end : " and a security model that allows us to forget that we run thousands and thousands of untrusted scripts every day." WebAssembly is designed to run in a sandbox. I suppose that does not by itself make it completely safe, but it can not be much worse than the current situation, can it?

chii 9y ago
but isn't wasm something that is supposed to be compiled into native binary? Which means if there's a way to trick the compiler to compile something that looks innocuous, but when run (or somehow exploited) that it does something it's not supposed to? In chrome, the process sandboxing is supposed to protect you - it doesn't matter if it's wasm or not. Does other impl. of wasm does similar security-wise?
- grondilu 9y ago
  > but isn't wasm something that is supposed to be compiled into native binary? No, it compiles into a binary code of its own. That gives it near-native speed, but it's no "hardware-binary" code.
  - chii 9y ago
    ahh, i thought that the binary format is effectively something you (the runtime) translated into actual assembly (to be then executed).
atonse 9y ago
I think WebAssembly has a huge expectations problem: What many people think it is: I can compile my JS frameworks as assembly and ship binaries to the browser, that'll run near-native and be more compact. What WebAssembly actually is: a way to compile libraries from other languages in a manner that you can run them in a JS runtime, but with no access to the DOM, etc. (Think of things like shipping a JS based OCR library or a JS based audio-engine that runs at near-native speeds)

lewisjoe 9y ago

Svelte(https://svelte.technology/ https://svelte.technology/) is one similar idea. It’s a framework that compiles down to plain JS before being shipped out to browsers. There’s a couple of concerns though: #1 How are we going to manage browser inconsistencies? We are very much better than what we were when jQuery came out. Yet we aren’t 100% there either. Browser inconsistencies, still do exist and runtime frameworks try to deal with it. #2 I’ll take Svelte as an example. Say, a component written in Svelte is 2 lines long. The compiled JS file of that component is around 200 lines long (verified). Out of these 200 lines of code, almost a hundred lines are repeating units that occur in every component file. By the time my app reaches a hundred components, this extra 100 lines gets multiplied by 100 times. This bloat is exactly what we want to avoid with runtime frameworks. So, let’s think of the simplest solution. Why not ship these repeating units of code as one module/set/block of code, that gets reused in different places? But wait, isn’t that block of code is what we call “Runtime Frameworks” ? I still think compile-time frameworks are the best bet we’ve got. Would be helpful if somebody can throw light on these aspects though.

rich_harris 9y ago
Svelte author here. If you're using a bundler integration like rollup-plugin-svelte or svelte-loader (for webpack), those repeating lines of code are deduplicated across components. There's a bare minimum of repetition, and we're in the process of reducing it further. You'd be surprised at just how well it scales! Browser inconsistencies are much less of an issue than they used to be. There are only a couple of places (e.g. listening for both 'input' and 'change' events on <input type='range'>, to satisfy IE and everyone else) where we need to accommodate differences.
- fron 9y ago
  Just wanted to say that I've been using svelte a bit at work to create widgets that our clients can embed on their websites, and I absolutely love it. Creating svelte components is super easy and consuming them is even easier. Thank you for having the vision, thank you for making it, and thank you for continuing to improve it.
9y ago

osteele 9y ago

In 2002, the Laszlo Presentation Server compiled XML with embedded JavaScript to swf (Flash) byte code. [A later version also compiled to HTML. Performant cross-browser dynamic HTML was daunting in 2002.] We considered HTML's “View Source” feature important, so we emulated this by causing the compiler to place a formatted source file in the output asset directory, and to embed a “View Source” popup menu. You could turn this off, and probably would for a deployed app, but the nudge was there.

pdimitar 9y ago

> Native code tends to have the luxury of not really caring about file size—a small 40MB iOS app would get you laughed out of the room on the web. Sure. And then your investor comes knocking on the door, sits down, looks at you judgingly, inhales smoke from his $200 cigar and says that he wants more returns from your startup. And you have no choice and have to put 10+ spy... - errr, advertisement, I meant advertisement! - scripts, and your web app consumes those 40MB easily. Don't act like web development is some small elitist circle where things are done extremely well, are optimized, and are with attention to technical detail. They are not. JS is a shit-show still. Compilers help, I agree. You can't go anywhere without reusable code though. Also known as "runtime frameworks".

curveship 9y ago

Just throwing my side project, Surplus, out there as another example of this strategy (https://github.com/adamhaile/surplus https://github.com/adamhaile/surplus). Surplus compiles JSX into optimized code that produces real DOM elements. The combination of an ahead-of-time compiler plus no virtual DOM layer means that the runtime code only has to do the minimal, truly dynamic work. As a result, Surplus is the fastest framework in Stefan Krauss's latest js-framework-benchmark (http://www.stefankrause.net/wp/?p=431 http://www.stefankrause.net/wp/?p=431). DSLs are powerful, compiler support can make them fast.

holri 9y ago

Is there a compiler for server side code? Producing DDL sql-code, views, templates etc from a more abstracted meta model?

supermdguy 9y ago

I think things are changing. Angular 4 was definitely "compiling" their code, instead of just running it. However, with VueJS growing in popularity, lightweight apps are on the rise again. People are tired of 5-10mb web apps.

noshbrinken 9y ago

> The trend started by minifiers like UglifyJS and continued by transpilers like Babel will only accelerate. Not to be pedantic, but are UglifyJS and Babel "frameworks"? Not a Ember user, so maybe Ember has some sort of built-in source code transformer and that's what the author is referring to? I think the basic idea that JavaScript developers, especially those working in a browser environment, will increasingly write source code that compiles to JavaScript "bytecode" is not a recent idea. A much more nuanced reflection on that idea can be found here: http://composition.al/blog/2017/07/30/what-do-people-mean-when-they-say-transpiler/ http://composition.al/blog/2017/07/30/what-do-people-mean-wh.... With all the hand-wringing about "JavaScript fatigue", it's a little bit sad that prominent JavaScript developers use titles like "Compilers are the New Frameworks". The tone of this title is the tone of a bell ringing for the next round of JavaScript fad musical chairs.

evilduck 9y ago
> Not to be pedantic, but are UglifyJS and Babel "frameworks"? The article doesn't make that claim, which kinda invalidates the "pedantry strawman" the rest of your comment is based on.
- noshbrinken 9y ago
  >...what we call web frameworks are transforming from runtime libraries into optimizing compilers. I took that to mean that the frameworks are doing the optimization. But the article doesn't give examples of the frameworks. The only examples of code transforming optimizations are Uglify and Babel. So I thought maybe these were the things the author has in mind and not actual frameworks. I was genuinely confused and prefaced with the aside about pedantry because questioning these kinds of semantics can come across as pedantic. The second half of my comment stands regardless.

zeveb 9y ago

> Our job now is figuring out how to adapt the ideas of high-performance native code while preserving what makes the web great: URLs, instant loading, and a security model that allows us to forget that we run thousands and thousands of untrusted scripts every day. URLs are indeed part of what makes the web great. So, too, is being able to read a document on any device imaginable, from a desktop with multiple monitors to a VT100 to a Plan 9 terminal window to a laptop to a watch to a phone to the custom OS I'm building in my free time. Non-progressively-enhancing JavaScript kills that entirely. Also, I don't think the security model of the web allows or enables us to forget that we're running thousands (hundreds of thousands?) of untrusted scripts; I think it just encourages us to. Really, we shouldn't forget it at all. The web security model — while nothing to sneer at — has enabled wholesale violations of privacy and the reduction of human beings to marketing data.

z3t4 9y ago

Isn't the JavaScript engine itself doing a good enough job of optimizing the JavaScript code !?

z3t4 9y ago

If you want to make a pure web app without server side "rendering", you should forget about HTML/XML and only use JavaScript and CSS. Managing GUI state in JavaScript sure is boring at first, but the trick is to use functions and abstractions, event listeners/observers, and plugin patterns. Then it becomes fun again, the performance is good, the source code is small, and it's easy to debug. Stop using < and > in your web app code!

floatboth 9y ago

> The trend started by minifiers like UglifyJS and continued by transpilers like Babel will only accelerate. No, the Babel trend is decelerating thanks to ES6 being supported practically everywhere. Minifiers (based on Babel :D) are still used but they're not that necessary thanks to HTTP compression. We have a component model with Custom Elements, encapsulation with Shadow DOM, variables (custom properties) in CSS, JavaScript with classes and modules, and HTTP/2 push to deliver these modules without extra roundtrips. The future is more platform, less tooling.

nickbauman 9y ago

The thing you have to always remember is there is no specific language that is JavaScript.

yorik 9y ago

> Ember has always been driven by the idea that web apps are becoming more and more like native apps over time. Well, this is what people keep telling again and again, as if it was enough to repeat it to make it real, but I still have to see one web application that I would prefer to use over a desktop one. Sure, we have hugely complex webapps, but the browser is a really a shitty environment to think of it as a "platform" to do anything else than to read documents.

dasil003 9y ago
> but I still have to see one web application that I would prefer to use over a desktop one. Sure you have, I would make a huge bet you've used a website that you were unwilling to install the app for. On-demand, truly cross-platform app deployment is a huge feature, not to be underestimated.
- j_s 9y ago
  > I would make a huge bet you've used a website that you were unwilling to install the app for HN!
aarpmcgee 9y ago
I think that the Ember community beats this drum because they have no real answer to React Native.

j_s 9y ago

Just let me know which open source web framework has the best batteries-included (as part of the main framework) data grid and I'll be happy.

Animats 9y ago

Yet all this is doing so little. It's not like many people are using WebGL and canvases to do interesting graphical things. Mostly they're just messing with scrolling, popping things up, and fading things in and out. All this machinery is way overkill for what it's used for. (Especially messing with scrolling, badly.)

cachvico 9y ago
You'd be surprised how often WebGL comes into play, take those silky smooth animations for example... or, you know, Google Maps.
chickenfries 9y ago
Flipboard built their mobile web app in canvas: http://engineering.flipboard.com/2015/02/mobile-web http://engineering.flipboard.com/2015/02/mobile-web

JoshMnem 9y ago

It seems like the less code users have access to, the less control they will have over their computers. Example: it might become harder to block tracking and ads, turning the open WWW into something more like mobile phone apps (which are terrible for the freedom of end users).

cosinetau 9y ago
I think that's the very thesis to the free & open source software movement.
deleted 9y ago
[deleted]

martin_drapeau 9y ago

Its funny that companies like Google work so hard to make Javascript interpretation so fast. Yet people write in an abstracted dialect that needs to get compiled down to Javascript because of productivity, convenience, sexiness, or whatever else. So many layers... A developer spends a lot of time debugging. Its so fun to write Jasvacript in the console. Yet we need source maps to solve the above problem in order to debug the code we wrote. Some times I feel the amount of engineering we do in defining new frameworks, dialects, transpilers, etc would be better served writing features for our end users. No, we absolutely need that hammer++ to hit that nail.

iamleppert 9y ago

It's crazy to me what amounts to most UI's -- basically forms and buttons, lists of things, images, pages have become so complex. It's like I've died and woken up in a strange, bizarre world where the laws of physics are different, but I still inhabit the same world. Does anyone else feel this way? Is this just how technology works?

whatever_dude 9y ago
This is typical of the maturation of any technology platform. What is actually happening is a change from a long-term growing complexity to short-term stable complexity. Historically, building something simple in an HTML page has always been simple. A field here, a button there, you're done. But with increased requirements, that sort of work became exponentially more difficult to maintain. If you have 10 fields each with the same basic functionality, you'd end up repeating the same thing 10 times. If you wanted some complex state management, you're building it all from the ground up. Your code may be "simple" in the sense that you don't need a build tool, preprocessors, or any dependencies to maintain it, but it becomes increasingly difficult to maintain. React, babel, webpack et al can make things much more complicated _to start_, especially for someone not acquainted with it. But the trade off is that things keep more or less the same level of complexity. Adding a feature is easier, duplicating an element or a screen is easier.
- iamleppert 9y ago
  I disagree with this sentiment and it's tautologically false. Have you ever worked in a mature babel code base? I have worked in many and frequently get contracts to clean them up. I have yet to see a clean one. Can you even point to a clean open source one? The complexity doesn't reach some steady state, it just keeps growing. The argument that something simple needs to be complex because of unknown future needs is a prime example of design based on emotion, not engineering.
nardi 9y ago
I think you’re understating the complexity of modern web applications. There are lots of web apps out there that cannot be aptly described as “pages,” or even as simply “UI”.

cachvico 9y ago

What a terrible title. A "web framework" conventionally is the runtime library, e.g. React, or Ruby on Rails. The optimizing compilers are part of the "build tools" or "build chain" or "make system". They weren't ever runtime libraries (except in isolated examples), and the general patterns have been around since the 70s. Yes, it's good to learn how a compiler works.