babel和postcss引起的一点儿思考

写es6，一般都会用到babel，它能把es6转为更好的es5，而es5可以直接在浏览器上运行。postcss是css界的babel，它可以把css转为更好的css，比如autoprefixer，让不同浏览器都支持某属性效果。我不知道为什么会有es6的出生，但是它的出现，确实让javascript更加先进，简洁，这就是技术的力量。既然es6都出现了，为什么浏览器们不尝试去认识es6呢？编写es6的人当初是怎么思考的？浏览器们会不会与时俱进呢？

工作中的我们，常常要考虑很多适配问题，但是大家似乎一直在配合浏览器和设备，因为作品需要载体展现，浏览器载体不进化，那么作品就要各种匹配和变化。就像浏览器不支持es6，所以有人研发了babel，手写css前缀麻烦，于是自动前缀插件应运而生。有没有一种可能，在es6出来的时候，或者出来前，各大浏览器厂商也做出相应支持和改变？时至今日，这种可能似乎没有苗头，否则也不会有babel和postcss的闪亮登场。我有时会想，如果浏览器给力，是不是就不会有那么多所谓的兼容性问题？浏览器设备就像源头，用户想喝到纯净的水，要么让浏览器在源头过滤，要么用户在喝水前一秒采取措施。然而大多数人事先都不知道浏览器出来的水有杂质，都是在喝过之后，发现不对劲，然后才找解决方案，久而久之，形成一种经验。这确实是一件好事，但是如果能从源头解决问题，是不是会更好呢？学过物理的人都知道，避免噪音影响自己，有好多种办法。比如找到噪音源，关掉它。比如在传播的过程中减弱声音，关上窗户和门。比如自己给耳朵塞上棉花。我个人更倾向于找到噪音源，然后关掉它，如果我控制不了的噪音源，比如外面放炮盖房子，那就退而求其次，关上门窗，给耳朵塞棉花。

解决问题，就像行军打仗一样，如果能主动进攻，就不要被动挨打。挨打后，才想着怎么预防以后不被挨打，或者减少挨打的次数并非良策啊，此乃下策，从源头解决实为上策。如果不能从源头解决问题，也要举一反三，处理一个问题进而解决一类问题，形成一个方案。

浏览器今后会不会支持es6+？前端开发者是不是要一直这样兵来将挡水来土掩，有问题解决问题？我们骑驴看唱本儿，走着瞧。