6 ms·

From what I could see, the amount of churn in the Javascript world is unsurpassed by anything in software or product, almost to an order of magnitude. I ended

From what I could see, the amount of churn in the Javascript world is unsurpassed by anything in software or product, almost to an order of magnitude. I ended up being a product designer (my main, academic education), a frontend, and a backend with varying levels of expertise in my lifetime, so I have some direct experience. My current advice as of April 2019 is to keep calm, if you can stay away from JS, do it, if you can't, pick Vue, avoid Webpack, use Typescript, and forget the rest. That should go fine for the next couple years, if you can manage to remove Webpack, even longer.

epicureanideal 8y ago
What do you think is problematic with Webpack? Or do you think it will simply become unnecessary at some point?
notduncansmith 8y ago
I like your advice to avoid Webpack and prefer TypeScript, but I think the advice to lean away from JS in general is poorly-founded. JS is a powerful, portable language with lots of opportunities to add value. It’s a good language to have in your toolkit along with others, and you can make a good living by learning to write good JS programs.
- rolleiflex 8y ago
  That is true. I meant it as in: ‘If you can avoid writing something in JavaScript, do so’. Obviously, there are contexts where it is the only game in town — I have big hopes for WebAssembly for that reason.
Jorge1o1 8y ago
What's the matter with Webpack? It carries quite a lot of advantages, like tree-shaking, code splitting, and lazy loading. These are real, tangible performance benefits, so I'm going to need some kind of compelling evidence as to why avoid Webpack.
- untog 8y ago
  Configuring it is a giant time suck. Particularly if you want to do hot reloading and all that kind of stuff. I'm a big fan of Parcel for 90% of the things I do. It just works.
  - s_y_n_t_a_x 8y ago
    Webpack works well without any configuration. The nice part is you can do advanced stuff with it if you so choose.
  - mattbreeden 8y ago
    It does just work. Until you want to use something that the core devs don't use. Like having the most popular front end framework be unusable for at least 6 months: https://github.com/parcel-bundler/parcel/issues/645 https://github.com/parcel-bundler/parcel/issues/645 Often you'll need to hope some third party made a plugin or make one yourself, which isn't really any different than using webpack, but the webpack ecosystem is much larger. I struggled through parcel for a long time before I switched to Webpack 4 and had all of my existing build system and some additional niceties working in <45 minutes (probably 30 min of that was just reading the docs).
    - ricardobeat 8y ago
      Looks like that particular issue was closed in July 2018? Also, anybody who considered that feature important enough could have fixed it. It's not rocket science. Certainly 10x easier than when that magical something in the webpack build chain breaks.
      - mattbreeden 8y ago
        > Looks like that particular issue was closed in July 2018? Yes, after being open for 6 months. > Also, anybody who considered that feature important enough could have fixed it. It's not rocket science. First off, maybe- but I was responding to the comment of 'it just works', so that's not relevant. My entire commentary was on 'it just works'. It doesn't really 'just work' if users have to implement their own plugins and fix their own bugs on super popular JS integrations. Second off, a user did fix it, and it took the devs a month to respond to the PR- so you're still at the mercy of the core devs. > Certainly 10x easier than when that magical something in the webpack build chain breaks. And this I'd just have to disagree with you on. Webpack has way more eyes and as a result I have had one issue (bug) with it which had already been fixed. I had many issues using Parcel beyond the one I linked of the most popular front-end framework not working.
mamcx 8y ago
About web pack and many others: I use Vue with several others dependencies. But 0 package managers. This is mine: cat js/vue.js js/vue-router.js js/vuelidate.min.js js/validators.min.js js/vuex.js js/vuex-i18n.umd.js js/translation.js js/vue-moment.js js/vue-virtual-scroll.js > js/build.js 0 problems. Predictable, not folder with millons of little JS files, etc...
- slezyr 8y ago
  What about Babel, JSX? I'm a C++ dev that's trying to learn JS. As I know if you want to use modern JS you have to compile it with babel to "portable" JS with Babel. And it was really painful to create DOM elements with createElement and small wrappers around them, so JSX should help here. Or you can just skip those?
  - rolleiflex 8y ago
    Listen to the pain. You can skip JSX and Babel. As I’ve mentioned before, Vue obviates the need for both.
  - coldtea 8y ago
    Libs are all ready to use, you don't need to compile them with babel. And for stuff you write yourself, they'll only need babel if you (a) want to support some ancient browsers (e.g. IE7), or (b) you want to use fancy new JS features. If you're OK to target 90% of the people with actual browsers from 3-4 years ago, then you don't need Babel at all (at least not for that).
- colecut 8y ago
  Are you able to use vue components? I would love to see how you manage your app js code with this approach.
  - mamcx 8y ago
    I have a single JS file, not vue components. Is still possible, but then my DIY build.sh need to be more complex. Still, the main point is that you can bring as much extra machinery as needed, instead of bring all then only use a fraction.
pmoleri 8y ago
Does Vue + TS remove the need for Webpack? Which one creates the JS and CSS bundles?
- miedpo 8y ago
  You technically don't need bundles for Vue. It can be inserted in a plain script tag and work with other tags on the page. You can even do components that way and import them with a script tag. CSS can be done the old fashioned way too. Vue's nice like that. It's easy to not use a bundle or to use one depending on what you'd like to do.
stevenwliao 8y ago
Which production-ready options do you see for frontends without JavaScript?
- rolleiflex 8y ago
  None yet, unfortunately. I expect the first ones to come out of Go compiling down to WebAssembly.
  - kwindla 8y ago
    We'll need a new toolchain -- wasm debugger support in the browser, especially. (I love your username.)
  - Risord 8y ago
    Why languages that compiles to JS won't apply? Let's say Elm for example? Still I am too excited to see rise of traditional non-specialized languages to web game with webasm like Blazor (C#/.Net) but yep not production ready.
renlo 8y ago
You went from "JS changes too much" to "If you use JS, use these hot new frameworks / libraries" (Vue, avoiding Webpack) ... which I think underscores the constantly changing nature of frontend.

epicureanideal 8y ago

What do you think is problematic with Webpack? Or do you think it will simply become unnecessary at some point?

notduncansmith 8y ago

I like your advice to avoid Webpack and prefer TypeScript, but I think the advice to lean away from JS in general is poorly-founded. JS is a powerful, portable language with lots of opportunities to add value. It’s a good language to have in your toolkit along with others, and you can make a good living by learning to write good JS programs.

rolleiflex 8y ago
That is true. I meant it as in: ‘If you can avoid writing something in JavaScript, do so’. Obviously, there are contexts where it is the only game in town — I have big hopes for WebAssembly for that reason.

Jorge1o1 8y ago

What's the matter with Webpack? It carries quite a lot of advantages, like tree-shaking, code splitting, and lazy loading. These are real, tangible performance benefits, so I'm going to need some kind of compelling evidence as to why avoid Webpack.

untog 8y ago
Configuring it is a giant time suck. Particularly if you want to do hot reloading and all that kind of stuff. I'm a big fan of Parcel for 90% of the things I do. It just works.
- s_y_n_t_a_x 8y ago
  Webpack works well without any configuration. The nice part is you can do advanced stuff with it if you so choose.
- mattbreeden 8y ago
  It does just work. Until you want to use something that the core devs don't use. Like having the most popular front end framework be unusable for at least 6 months: https://github.com/parcel-bundler/parcel/issues/645 https://github.com/parcel-bundler/parcel/issues/645 Often you'll need to hope some third party made a plugin or make one yourself, which isn't really any different than using webpack, but the webpack ecosystem is much larger. I struggled through parcel for a long time before I switched to Webpack 4 and had all of my existing build system and some additional niceties working in <45 minutes (probably 30 min of that was just reading the docs).
  - ricardobeat 8y ago
    Looks like that particular issue was closed in July 2018? Also, anybody who considered that feature important enough could have fixed it. It's not rocket science. Certainly 10x easier than when that magical something in the webpack build chain breaks.
    - mattbreeden 8y ago
      > Looks like that particular issue was closed in July 2018? Yes, after being open for 6 months. > Also, anybody who considered that feature important enough could have fixed it. It's not rocket science. First off, maybe- but I was responding to the comment of 'it just works', so that's not relevant. My entire commentary was on 'it just works'. It doesn't really 'just work' if users have to implement their own plugins and fix their own bugs on super popular JS integrations. Second off, a user did fix it, and it took the devs a month to respond to the PR- so you're still at the mercy of the core devs. > Certainly 10x easier than when that magical something in the webpack build chain breaks. And this I'd just have to disagree with you on. Webpack has way more eyes and as a result I have had one issue (bug) with it which had already been fixed. I had many issues using Parcel beyond the one I linked of the most popular front-end framework not working.

mamcx 8y ago

About web pack and many others: I use Vue with several others dependencies. But 0 package managers. This is mine: cat js/vue.js js/vue-router.js js/vuelidate.min.js js/validators.min.js js/vuex.js js/vuex-i18n.umd.js js/translation.js js/vue-moment.js js/vue-virtual-scroll.js > js/build.js 0 problems. Predictable, not folder with millons of little JS files, etc...

slezyr 8y ago
What about Babel, JSX? I'm a C++ dev that's trying to learn JS. As I know if you want to use modern JS you have to compile it with babel to "portable" JS with Babel. And it was really painful to create DOM elements with createElement and small wrappers around them, so JSX should help here. Or you can just skip those?
- rolleiflex 8y ago
  Listen to the pain. You can skip JSX and Babel. As I’ve mentioned before, Vue obviates the need for both.
- coldtea 8y ago
  Libs are all ready to use, you don't need to compile them with babel. And for stuff you write yourself, they'll only need babel if you (a) want to support some ancient browsers (e.g. IE7), or (b) you want to use fancy new JS features. If you're OK to target 90% of the people with actual browsers from 3-4 years ago, then you don't need Babel at all (at least not for that).
colecut 8y ago
Are you able to use vue components? I would love to see how you manage your app js code with this approach.
- mamcx 8y ago
  I have a single JS file, not vue components. Is still possible, but then my DIY build.sh need to be more complex. Still, the main point is that you can bring as much extra machinery as needed, instead of bring all then only use a fraction.

pmoleri 8y ago

Does Vue + TS remove the need for Webpack? Which one creates the JS and CSS bundles?

miedpo 8y ago
You technically don't need bundles for Vue. It can be inserted in a plain script tag and work with other tags on the page. You can even do components that way and import them with a script tag. CSS can be done the old fashioned way too. Vue's nice like that. It's easy to not use a bundle or to use one depending on what you'd like to do.

stevenwliao 8y ago

Which production-ready options do you see for frontends without JavaScript?

rolleiflex 8y ago
None yet, unfortunately. I expect the first ones to come out of Go compiling down to WebAssembly.
- kwindla 8y ago
  We'll need a new toolchain -- wasm debugger support in the browser, especially. (I love your username.)
- Risord 8y ago
  Why languages that compiles to JS won't apply? Let's say Elm for example? Still I am too excited to see rise of traditional non-specialized languages to web game with webasm like Blazor (C#/.Net) but yep not production ready.

renlo 8y ago

You went from "JS changes too much" to "If you use JS, use these hot new frameworks / libraries" (Vue, avoiding Webpack) ... which I think underscores the constantly changing nature of frontend.