3 ms·

> > Seeing those quasi-JS expressions in HTML attributes is enough to put me off Vue. > They are supremely useful. Ultimately, it's knowing how to use them to

by EB66 8y ago

> > Seeing those quasi-JS expressions in HTML attributes is enough to put me off Vue. > They are supremely useful. Ultimately, it's knowing how to use them to their maximum potential. Supremely useful for a typical full stack developer -- yes. Supremely useful for a dev team with members who specialize in web design (plain HTML, CSS, etc) -- not necessarily. When your source code mixes a bunch of different web technologies it limits the types of developers who can effectively work on it. Many commenters here regard React and Vue as "easy", but for many designers it's not easy. There are plenty of talented web designers who are just not interested or not capable of working efficiently with React/Vue. Our company built an in-house JS component framework that is heavily inspired by React and Vue but that doesn't suffer from the intertwining of disparate web technologies. HTML, CSS and JavaScript stay separate from one another. As a result, our designers can independently iterate on UI without needing to touch a bit of JavaScript or quasi-JavaScript constructs.

ohhellno 8y ago
If it is so good, why don't you open source it? Edit: not sure why this is being downvoted, I am genuinely curious.
- EB66 8y ago
  I'm not arguing that our framework is better than React or Vue -- our framework just works better for us. We do plan to eventually open source it, but there's a lot of work to be done before a public release: better documentation, better tutorials, remove some constructs specific to our company, etc. We've open sourced some of our internal JS libraries before and it's worked out well -- the contributions submitted and bugs reported by others have been very helpful.
jpochtar 8y ago
If your designers aren't programming, they probably don't need to write HTML/CSS either. Full disclosure: I'm a founder of Pagedraw, which lets designers make UIs as easily as they draw them in a design tool, but are production ready. The designers don't need any code, but programmers can connect it to Javascript data bindings/event handlers as needed. No one has to write HTML/CSS by hand any more.
oatmealsnap 8y ago
Coupling the CSS and JS and HTML isn't a random design choice. It came out of some very useful styleguides for AngularJS (and other guides too, I'm sure). These guidelines suggest grouping the CSS and HTML and JS together when they are related. It makes a lot of sense in larger applications, but maybe not so much for server-rendered static pages. There are global styles, and there are styles that are relevant only to a particular component. Hoist styles up to a global (or more general) layer whenever you can, but I really appreciate the fact that I know the important styles I need will be in the same file/folder.
- EB66 8y ago
  > These guidelines suggest grouping the CSS and HTML and JS together when they are related. It makes a lot of sense in larger applications. I absolutely agree with you on that. It's important to point out that grouping and intertwining are two very different things. If you are building a large client-side rendered JavaScript web app, then it is very beneficial to group together the JS, HTML and CSS for a particular component. That's what we do too. However, it is highly debatable whether the JS, HTML, and CSS should be intertwined together (i.e., literally mixed within the same lines) and controlled using framework-specific quasi-JS syntax. As I mentioned above, when you do the latter, you will unquestionably limit the types of developers who are able to work effectively with the code base. If your team is comprised of a bunch of full stack developers, then you won't face much limitation. But if you're like us and your dev teams include web designers who are JS 'lightweights', then it's a problem. Reading your other comment from above: > I hate seeing code syntax mixed with markup syntax. You can end up with hard to parse views (reminds me of PHP and Rails), and abstracts the final HTML structure from the developer. You hit the nail on the head -- I couldn't agree more.

by EB66 8y ago

ohhellno 8y ago

If it is so good, why don't you open source it? Edit: not sure why this is being downvoted, I am genuinely curious.

EB66 8y ago
I'm not arguing that our framework is better than React or Vue -- our framework just works better for us. We do plan to eventually open source it, but there's a lot of work to be done before a public release: better documentation, better tutorials, remove some constructs specific to our company, etc. We've open sourced some of our internal JS libraries before and it's worked out well -- the contributions submitted and bugs reported by others have been very helpful.

jpochtar 8y ago

If your designers aren't programming, they probably don't need to write HTML/CSS either. Full disclosure: I'm a founder of Pagedraw, which lets designers make UIs as easily as they draw them in a design tool, but are production ready. The designers don't need any code, but programmers can connect it to Javascript data bindings/event handlers as needed. No one has to write HTML/CSS by hand any more.

oatmealsnap 8y ago

Coupling the CSS and JS and HTML isn't a random design choice. It came out of some very useful styleguides for AngularJS (and other guides too, I'm sure). These guidelines suggest grouping the CSS and HTML and JS together when they are related. It makes a lot of sense in larger applications, but maybe not so much for server-rendered static pages. There are global styles, and there are styles that are relevant only to a particular component. Hoist styles up to a global (or more general) layer whenever you can, but I really appreciate the fact that I know the important styles I need will be in the same file/folder.

EB66 8y ago
> These guidelines suggest grouping the CSS and HTML and JS together when they are related. It makes a lot of sense in larger applications. I absolutely agree with you on that. It's important to point out that grouping and intertwining are two very different things. If you are building a large client-side rendered JavaScript web app, then it is very beneficial to group together the JS, HTML and CSS for a particular component. That's what we do too. However, it is highly debatable whether the JS, HTML, and CSS should be intertwined together (i.e., literally mixed within the same lines) and controlled using framework-specific quasi-JS syntax. As I mentioned above, when you do the latter, you will unquestionably limit the types of developers who are able to work effectively with the code base. If your team is comprised of a bunch of full stack developers, then you won't face much limitation. But if you're like us and your dev teams include web designers who are JS 'lightweights', then it's a problem. Reading your other comment from above: > I hate seeing code syntax mixed with markup syntax. You can end up with hard to parse views (reminds me of PHP and Rails), and abstracts the final HTML structure from the developer. You hit the nail on the head -- I couldn't agree more.