4 ms·

The title of this submission is a bit misleading. This script parses the .vue file and extracts the three sections into x-template script, Vue.component script

The title of this submission is a bit misleading. This script parses the .vue file and extracts the three sections into x-template script, Vue.component script and a style. These are not standalone in the sense that they cannot exist without vue and vue-template on the page (the later is large and unnecessary when compiling with webpack). Essentially this does what the vue webpack plugin does naïvely and without many of the features like support for different template / JS / style language compilation (e.g. Babel and sass).

type0 8y ago
Gosh,there is so much half assed redundancy in js world that no wonder that so many beginners feel lost. This does seem a bit too experimental to actually be useful. Some vue based projects are actually nice and easy for beginners to be productive (like Nuxt), but the whole vue ecosystem has never clicked with me even after I toyed with it for at least 2 or 3 times.
- turtlebits 8y ago
  I'm in the opposite boat. I don't care to learn all the "magic" cli tools that frontend frameworks provide. This looks great to me, even if it does little.
- aikah 8y ago
  > Gosh,there is so much half assed redundancy in js world that no wonder that so many beginners feel lost. Beginners feel lost because the JavaScript world has learned nothing from Java's ant. These insane build/asset pipelines that take forever to run are the bane of the JS world. It's like nobody remembers you can just write a JavaScript,then link it to an HTML without 35 compilation steps.
  - paradite 8y ago
    We are no longer just trying to toggle a modal or show a popup. The requirement for frontend has changed dramatically and now we need to handle entire UI flow, interactivity, data synchronization, and even some business logic like filtering and validations with JS, HTML and CSS. There's no web app for air traffic controller yet, but pretty much everything else has a web app with a huge set of feature and non-feature requirements.
    - aikah 8y ago
      > We are no longer just trying to toggle a modal or show a popup. > The requirement for frontend has changed dramatically and now we need to handle entire UI flow, interactivity, data synchronization, and even some business logic like filtering and validations with JS, HTML and CSS. What does it have to do with using Babel/Webpack and what not? it hasn't. The DOM is plenty and enough to implement MVC on top of it without requiring 200 libraries from NPM. Developers have been writing complex GUI apps for more than 4 decades without the need for a specific framework, how did they manage to do so yet everybody needs some complex framework in the browser? no they don't. Most of these web apps are forms. Now I'm not saying don't use react and whatever pipeline you are using. But downloading node and all these stuff isn't what a beginner should be exposed to. Beginners should learn basic principles of front-end development which includes the DOM.
      - paradite 8y ago
        > Do you think an app like Photoshop or 3DSMax uses a react like framework on top of whatever C++ GUI they are using? Yes I think so. Why else would they require 1GB of space to install them and specific hardware to run them efficiently? As a matter of fact, they require rendering libraries from graphics card companies. The difference is that they use their own proprietary frameworks instead of open sourcing them. > How many apps can boast about being as complex on the web? most of these web apps are forms. Not a lot, but quite significant nontheless. For example google docs, office 365, Facebook, Amazon, and many cloud solutions for enterprise. I agree most of web apps out there are just fancy forms and don't really need any frameworks, but there are legitimate use cases for them. Edit for your updated comment: Yes, I fully agree that web developers should start from basics, not frameworks and libraries. Cheers.
        aikah 8y ago
        > As a matter of fact, they require rendering libraries from graphics card companies. in order to render graphics. The DOM already gives you all that for free. > For example google docs, office 365, Facebook, Amazon, and many cloud solutions for enterprise Not even VSCode uses a specific framework, which demonstrate my point. Yes, they use Monaco editor for their text editor but this is a very specific library for a specific purpose, this isn't a generic view framework like react and co.
  - rhengles 8y ago
    I agree we can do much simpler. That's why I'm building some conventions to load vue components asynchronally (with each part - html, js and css - separated). You can checkout it here: (example) https://unpkg.com/@arijs/vue-generator@0.1.5/outra/pagina/ https://unpkg.com/@arijs/vue-generator@0.1.5/outra/pagina/ github: https://github.com/arijs/VueGenerator https://github.com/arijs/VueGenerator I had to ship a fork of Vue because the Vue mantainers won't accept the necessary changes to make this work.
- koboll 8y ago
  This is why despite trying Vue first and liking it, after learning React, I would always use it in the future. Vue really requires you invest in its ecosystem a lot more to structure your entire frontend (and Nuxt even more so), whereas React feels and operates much more strictly as a JS library. The basic benefit of Vue is that it comes with much of the React boilerplate already abstracted away behind syntactic sugar. But once you learn to do that yourself with React, it's no slower to start building. It just takes a longer learning curve to get to that point.
  - burlesona 8y ago
    After using each in production for about two years I came to the opposite conclusion. For me the React experience includes tons of bikeshedding over which accessories (routing, state management, etc) to pair it with and how to wire those up. The Vue experience started simple and scaled up nicely as we reached the point that we needed more stuff, since there’s an official library for basically everything and it all works very nicely together. It’s pretty subjective I guess but interesting how different development experiences can be.
    - bhj 8y ago
      > For me the React experience includes tons of bikeshedding over which accessories (routing, state management, etc) to pair it with and how to wire those up. This is React's biggest strength IMO, that it doesn't handle routing, state, etc. It just makes your UI a function of state. How an app needs to manage state can vary wildly, but it's all the same to React.
- manatlan 8y ago
  > This does seem a bit too experimental to actually be useful I use it for 3 years ... I've just updated it, to make css scopable, and decided to release it to the public. I've got a "big app", with more thant 50 components, with vuetify, vue-router & vuex, 2 websockets and a lot of fetch ... it works as expected (btw I've never used vue-cli/nodejs/webpack with them ;-)

type0 8y ago

Gosh,there is so much half assed redundancy in js world that no wonder that so many beginners feel lost. This does seem a bit too experimental to actually be useful. Some vue based projects are actually nice and easy for beginners to be productive (like Nuxt), but the whole vue ecosystem has never clicked with me even after I toyed with it for at least 2 or 3 times.

turtlebits 8y ago
I'm in the opposite boat. I don't care to learn all the "magic" cli tools that frontend frameworks provide. This looks great to me, even if it does little.
aikah 8y ago
> Gosh,there is so much half assed redundancy in js world that no wonder that so many beginners feel lost. Beginners feel lost because the JavaScript world has learned nothing from Java's ant. These insane build/asset pipelines that take forever to run are the bane of the JS world. It's like nobody remembers you can just write a JavaScript,then link it to an HTML without 35 compilation steps.
- paradite 8y ago
  We are no longer just trying to toggle a modal or show a popup. The requirement for frontend has changed dramatically and now we need to handle entire UI flow, interactivity, data synchronization, and even some business logic like filtering and validations with JS, HTML and CSS. There's no web app for air traffic controller yet, but pretty much everything else has a web app with a huge set of feature and non-feature requirements.
  - aikah 8y ago
    > We are no longer just trying to toggle a modal or show a popup. > The requirement for frontend has changed dramatically and now we need to handle entire UI flow, interactivity, data synchronization, and even some business logic like filtering and validations with JS, HTML and CSS. What does it have to do with using Babel/Webpack and what not? it hasn't. The DOM is plenty and enough to implement MVC on top of it without requiring 200 libraries from NPM. Developers have been writing complex GUI apps for more than 4 decades without the need for a specific framework, how did they manage to do so yet everybody needs some complex framework in the browser? no they don't. Most of these web apps are forms. Now I'm not saying don't use react and whatever pipeline you are using. But downloading node and all these stuff isn't what a beginner should be exposed to. Beginners should learn basic principles of front-end development which includes the DOM.
    - paradite 8y ago
      > Do you think an app like Photoshop or 3DSMax uses a react like framework on top of whatever C++ GUI they are using? Yes I think so. Why else would they require 1GB of space to install them and specific hardware to run them efficiently? As a matter of fact, they require rendering libraries from graphics card companies. The difference is that they use their own proprietary frameworks instead of open sourcing them. > How many apps can boast about being as complex on the web? most of these web apps are forms. Not a lot, but quite significant nontheless. For example google docs, office 365, Facebook, Amazon, and many cloud solutions for enterprise. I agree most of web apps out there are just fancy forms and don't really need any frameworks, but there are legitimate use cases for them. Edit for your updated comment: Yes, I fully agree that web developers should start from basics, not frameworks and libraries. Cheers.
      - aikah 8y ago
        > As a matter of fact, they require rendering libraries from graphics card companies. in order to render graphics. The DOM already gives you all that for free. > For example google docs, office 365, Facebook, Amazon, and many cloud solutions for enterprise Not even VSCode uses a specific framework, which demonstrate my point. Yes, they use Monaco editor for their text editor but this is a very specific library for a specific purpose, this isn't a generic view framework like react and co.
- rhengles 8y ago
  I agree we can do much simpler. That's why I'm building some conventions to load vue components asynchronally (with each part - html, js and css - separated). You can checkout it here: (example) https://unpkg.com/@arijs/vue-generator@0.1.5/outra/pagina/ https://unpkg.com/@arijs/vue-generator@0.1.5/outra/pagina/ github: https://github.com/arijs/VueGenerator https://github.com/arijs/VueGenerator I had to ship a fork of Vue because the Vue mantainers won't accept the necessary changes to make this work.
koboll 8y ago
This is why despite trying Vue first and liking it, after learning React, I would always use it in the future. Vue really requires you invest in its ecosystem a lot more to structure your entire frontend (and Nuxt even more so), whereas React feels and operates much more strictly as a JS library. The basic benefit of Vue is that it comes with much of the React boilerplate already abstracted away behind syntactic sugar. But once you learn to do that yourself with React, it's no slower to start building. It just takes a longer learning curve to get to that point.
- burlesona 8y ago
  After using each in production for about two years I came to the opposite conclusion. For me the React experience includes tons of bikeshedding over which accessories (routing, state management, etc) to pair it with and how to wire those up. The Vue experience started simple and scaled up nicely as we reached the point that we needed more stuff, since there’s an official library for basically everything and it all works very nicely together. It’s pretty subjective I guess but interesting how different development experiences can be.
  - bhj 8y ago
    > For me the React experience includes tons of bikeshedding over which accessories (routing, state management, etc) to pair it with and how to wire those up. This is React's biggest strength IMO, that it doesn't handle routing, state, etc. It just makes your UI a function of state. How an app needs to manage state can vary wildly, but it's all the same to React.
manatlan 8y ago
> This does seem a bit too experimental to actually be useful I use it for 3 years ... I've just updated it, to make css scopable, and decided to release it to the public. I've got a "big app", with more thant 50 components, with vuetify, vue-router & vuex, 2 websockets and a lot of fetch ... it works as expected (btw I've never used vue-cli/nodejs/webpack with them ;-)