3 ms·

Thanks for the link to your presentation. Very interesting to see the history in one place. I'm not totally clear on the primary cause of the mess once we get t

Thanks for the link to your presentation. Very interesting to see the history in one place. I'm not totally clear on the primary cause of the mess once we get to npm, bower, grunt, etc. Is the main issue the shortcomings of JS itself or something else..?

acemarke 10y ago
I'll go ahead and quote the most relevant slides from my presentation: > Javascript/Client Challenges: > - No built-in module definition system > - No encapsulation > - Prototypal-based inheritance system unlike most languages > - No static type declarations or compilation > - Dynamically modified objects and data > - Minimal standard library > - Variations in browser capabilities > - Document layout model repurposed for application layouts > Javascript/Client Dev Goals > - Minimize bytes sent over the wire > - Handle browser compatibility issues > - Fill in gaps in JS standard library and language spec > - Reuse and share code between apps > - Build increasingly complex full-blown applications that just happen to live inside a browser So, it's all those aspects together. People want to use the latest syntax, patch holes in the language, standardize behavior, share code, and run full-blown compilation pipelines that parse, transform, link, and optimize, and use all that to build complex applications. That's a completely different world than just using jQuery to toggle some divs. In addition, these pieces have really only come together in the last 6 years or so. The C ecosystem has been around since the late 70s, Java is over 20 years old, and so on. Those ecosystems have had time to build out tools and conventions, and the underlying platforms have been more stable as well. In the front-end world, browsers and runtime capabilities are constantly changing, and as people are pushing the limits of the language and ecosystem, others are inspired by those ideas. So, there's a lot of catch-up and iteration going on. I'm not going to say that it's easy to keep up with or that everything about these changes is perfect and wonderful. That said, I _do_ think that the rate of change is slowing down somewhat, and that the situation is stabilizing. I think the last year and a half of "Javascript Fatigue" complaints have also raised awareness of the churn, and that there's a big emphasis on improving developer experience going on right now. For example, the Webpack team has made a huge effort to rewrite their docs from scratch ([0]), and there's several utilities out there that try to make it easier to write Webpack configs without having to fiddle with every last option yourself ([1], [2]). There's also tools like Create-React-App ([3}), which try to encapsulate the entire build tool process for you ([4]). So, yeah - everyone's still trying to sort things out a bit, but ultimately the tools and technologies now available are letting people do a lot of things they couldn't do before. [0] https://webpack.js.org/ https://webpack.js.org/ [1] https://github.com/andywer/webpack-blocks https://github.com/andywer/webpack-blocks [2] https://github.com/webpack-flow/webpack-flow https://github.com/webpack-flow/webpack-flow [3] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app [4] https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_need_a_boilerplate/davn6e8/?context=1 https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_ne...

acemarke 10y ago

I'll go ahead and quote the most relevant slides from my presentation: > Javascript/Client Challenges: > - No built-in module definition system > - No encapsulation > - Prototypal-based inheritance system unlike most languages > - No static type declarations or compilation > - Dynamically modified objects and data > - Minimal standard library > - Variations in browser capabilities > - Document layout model repurposed for application layouts > Javascript/Client Dev Goals > - Minimize bytes sent over the wire > - Handle browser compatibility issues > - Fill in gaps in JS standard library and language spec > - Reuse and share code between apps > - Build increasingly complex full-blown applications that just happen to live inside a browser So, it's all those aspects together. People want to use the latest syntax, patch holes in the language, standardize behavior, share code, and run full-blown compilation pipelines that parse, transform, link, and optimize, and use all that to build complex applications. That's a completely different world than just using jQuery to toggle some divs. In addition, these pieces have really only come together in the last 6 years or so. The C ecosystem has been around since the late 70s, Java is over 20 years old, and so on. Those ecosystems have had time to build out tools and conventions, and the underlying platforms have been more stable as well. In the front-end world, browsers and runtime capabilities are constantly changing, and as people are pushing the limits of the language and ecosystem, others are inspired by those ideas. So, there's a lot of catch-up and iteration going on. I'm not going to say that it's easy to keep up with or that everything about these changes is perfect and wonderful. That said, I _do_ think that the rate of change is slowing down somewhat, and that the situation is stabilizing. I think the last year and a half of "Javascript Fatigue" complaints have also raised awareness of the churn, and that there's a big emphasis on improving developer experience going on right now. For example, the Webpack team has made a huge effort to rewrite their docs from scratch ([0]), and there's several utilities out there that try to make it easier to write Webpack configs without having to fiddle with every last option yourself ([1], [2]). There's also tools like Create-React-App ([3}), which try to encapsulate the entire build tool process for you ([4]). So, yeah - everyone's still trying to sort things out a bit, but ultimately the tools and technologies now available are letting people do a lot of things they couldn't do before. [0] https://webpack.js.org/ https://webpack.js.org/ [1] https://github.com/andywer/webpack-blocks https://github.com/andywer/webpack-blocks [2] https://github.com/webpack-flow/webpack-flow https://github.com/webpack-flow/webpack-flow [3] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app [4] https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_need_a_boilerplate/davn6e8/?context=1 https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_ne...