Is there anything actually novel here? These types of things always seemed to run into composition issues (controllers inside of controllers) in terms of communication and what not. The net result was invariably far less appealing than, say, angular 1 or vue or non-SPA React.
It doesn't need to be novel right? It just needs to be helpful.
It’s likely a significant fraction of people who jumped to the same solutions had some prior exposure to jquery.
Personally, when I work on projects I tend to develop a pure HTML+CSS solution first and then bolt on JS if needed, so this kind of stuff might make me more comfortable with writing proper webapps since it's still just basically "bolt JS on HTML".
Which, IMO isn't too bad, I keep my pages under 100KB. If I throw out a picture for an older project, I can easily get back those 30KB to stay under 100KB.
I've been using Stimulus + Turoblinks for my current side project and I love it. Nice and simple way to add a bit of interactivity to existing HTML on your page.
Edit: thanks, I found it, I was just pointing out to the typo so other people don't get confused.
http://quickenloans.github.io/Behaviors.js/
It has no server-side dependencies and should be easy enough to use. But it doesn't use push history, which limits its usefulness for more extensive use cases.
Turbolinks also makes websites appear extremely slow when on slow connections. It's much more frustrating to sit there with a loading bar hovering at 20-30% than to see a spinner.
The manual even describes how to use just a plain <script> inclusion, instead of the build tool of the day.
Doing so is not a great idea, because build tools solve real and extant problems, but they're very common.
Really painful when JavaScript is only used on the browser and the frontend files need to be integrated into the backend infrastructure written in a more sane language.
Can anyone with experience of Stimulus suggest why I'd pick it over intercooler?
The ability to think effortlessly about code has value.
Anyway, just stopping by to say that Vue has struck a good balance for me. Peppering in {{template values}} in existing HTML works really well, and when things start to get more complex I can easily break my dom out into components.
They didn't just "invent" the library in hopes it would work for someone. It's what they run in production on one of the most long running SAAS apps on the internet.
At the end of the day Vue-cli or create-react-app ultimately just generates static assets. Adding your statically built SPA into a Rails app should be no harder than adding jQuery. Rails should not need to know about webpack & vice versa. The key is to build components not a full fledged SPA. Pick either Rails or Vue router. If the former, Vue is just a component/view library, don't treat it like a framework.
One criticism I have relates to The syntax for denoting action methods. Did you agonize over the choice of syntax uses hash and implication? E.g.
click->hello#greet
Interested to hear thoughts of others in a discussion about this.
I know it is vanilla ES6, but at some point it starts looking more like Java than JavaScript. The boilerplate necessary to convey a simple instruction is directly proportional to the averaged speed of everything else (authorship, maintenance, execution, testing, frequency of reuse, and so forth).
`export` -> exports the thing
`default` -> if you require from this module, this is the default
`class` -> class definition
`extends` -> speaks for itself
`Controller` class it's extending.
You could maybe rework it so you don't export it on the same line:
```
class Foo extends Controller {}
export default Foo
```
The parallel I see here to Java is the object orientation - which is a fair criticism. There are probably ways to execute on this using other mechanisms other than inheritance. But then, sub-classing to me still feels better than assigning the prototype via direct assignment.
In a language with fewer developers/smaller projects/fewer interdependent modules, there would be no need for exporting (no privacy, everything public by default), there would be no special syntax for extending a class (after all, you could just write it yourself if you need it), there might not even be any classes at all (again, you could just implement them if necessary).
But as languages mature, code bases start to grow, and every project depends on a web of dozens of slightly incompatible packages, people begin to realize that they need some mechanism to enforce order and to standardize on a single, officially blessed implementation of all those things you could just do yourself (and everyone did, with no regard for compatibility).
Then, when the language feels bogged down with the ceremony necessary for programming "at scale", someone decides to just throw all that baggage over board and develops a fresh scripting language, where the cycle begins anew.
[1] https://github.com/firstandthird/domodule [2] https://github.com/firstandthird/simple-domodal [3] https://github.com/firstandthird/complete
It's a super awesome pattern, that makes things super simple and it's super lightweight as well.
It's not perfect, but it's better for the newer browsers - they get something fact and neat, IE users get a slower one, but they would never get a really nice experience.
Yeah so no. There is no way gzip could only compress 16% of utf8 data.
As a package author you use whatever you want (rollup, webpack, gulp, grunt, ...), but you will most likely publish to npm, because bower is dead.
As a consumer you use npm or yarn, it doesn't matter, and a tool that handles modules, probably webpack. Even if you'd use something else (rollup & parcel come to mind), it doesn't matter, they will all treat your dependency the same.
EDIT: Yeah i just saw you're referring to Polymer. I take it back, everything you said applies. But then again, people probably want to suffer when they use it. Though very few actually do use it. I just don't think it's a good example to make to describe web dev in general. Rather Google was the only one that missed the train it seems, they worked in the opposite direction.
Polymer starter kit
https://github.com/Polymer/polymer-starter-kit
- npm
- bower
- polymer-cli
Doing a polymer test requires downloading and installing Web Component Tester, which then requires:
- npm
- grunt
- gulp
- bower
My relatively standard project (using React) needs just Yarn and Webpack. It's got quite some dependencies, but I've never run into those being insufficient.