Live data from Hacker News

Stimulus: A modest JavaScript framework for the HTML you already have

stimulusjs.org

41–50 of 65 posts

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#41
post #36

Earlier quoted context omitted.

I did two other frameworks that are super similar, hooked up with dynamic loading of the code with webpack, and the older one RequireJS. It's a super awesome pattern, that makes things super simple and it's super lightweight as well.

Unfortunately they get crazy bloated when we transpile them down for older ie. I believe we’re going to be using the new Babel stuff to hopefully easy that a bit. Ie 10 is still a sore spot though :/

We try to transtile as little as possible. And we do detect IE so that we can serve special bundles with special polyfills for that browser.

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.

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#42
post #20

With 30KB in size, this framework might be something I can integrate into my websites to get a nice look-and-feel while preserving usability when script blockers are active. 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"…

30KB? That's a lot, this is not minified and Gzip'ed is it?

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#43

> export default class extends Controller { 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).

Do you mind expanding on what you mean? When I look at the instructions here, they seem pretty concise. `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 ```…

Java has no concept of default, but otherwise `public class Foo extends Controller {}` would be pretty similar. It's not that the keywords are overly verbose for the purpose they express, it's that they relate more to "code bureaucracy" than to direct functionality.

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.

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#44

> export default class extends Controller { 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).

I've never written any java code, but I really love the module systems inspired by it. I've been using this kind of packaging in both javascript and golang, and it actually feels way simpler than in ruby where I'll always end up with `Namespace1::Namespace2::Namespace3::klass` to deal with the global scope of everything.

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#45
post #28

Earlier quoted context omitted.

Is that a real world scenario or something you can imagine but haven't actually done?

If you want a real world scenario, here is one 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 https://github.com/Polymer/web-component-tester

Polymer is indeed ridiculous. But there's a reason it's not used that often.

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.

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#46
post #20

With 30KB in size, this framework might be something I can integrate into my websites to get a nice look-and-feel while preserving usability when script blockers are active. 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"…

30KB? That's a lot, this is not minified and Gzip'ed is it?

Well, I just opened the script in firefox and checked the network tab in the dev console. It's 26KB gzip and 31KB after decompression.

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.

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#48
post #22

Earlier quoted context omitted.

Why would a project have both npm and yarn, or bower, webpack and gulp?

Easy, each library is its own little world of dependencies, with the author favoring a different build tool, so simple npm install or npm serve might require all of them to satisfy all the dependencies build scripts.

I think you're confusing something. You don't "build" dependencies, you consume them as pre-built modules.

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.

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#49

Previous discussion: https://news.ycombinator.com/item?id=16052105 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.

Is there anyway to use turbolinks with a java backend? Or is it only specific to rails?

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#50

Previous discussion: https://news.ycombinator.com/item?id=16052105 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.

Is there anyway to use turbolinks with a java backend? Or is it only specific to rails?

You can. Here's a blog post from somebody who uses it with an Elixir backend.

https://changelog.com/posts/why-we-chose-turbolinks

Post reply on HN