Stimulus: A modest JavaScript framework for the HTML you already have • Hacker News Board

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

#61

Post by lostphilosopher » Tue, Jan 02, 2018, 8:26 PM UTC

scarface74 wrote: post #51

lostphilosopher wrote: post #47

Earlier quoted context omitted.

> "It allows us to party with productivity like days of yore. A throwback to when a single programmer could make rapacious progress without getting stuck in layers of indirection or distributed systems. [source]( https://github.com/stimulusjs/stimulus/blob/master/ORIGIN.md... I suspect if you're in a situation where you need bureaucratic approval or "CYA" you don't have one of the main problems stimulus is trying to…

I am the architect for a small development shop. Upper management has never in the past year said no to my decisions. I built our dev shop from scratch - environments, procedures, trainings, dev ops, and many of the hires. I'm very cognizant though if things went south because of major architectural decisions I made - not minor code bugs - or that they didn't give the scaleability, reliability, Security, etc. that wa…

I don't disagree with anything you're saying. You're working in a specific context that affords you a set of options different from the sets of options available in different contexts. My read of Stimulus is that it's geared for contexts other than yours. However, it could still be one of your options.

Which brings us to - "scaleability, reliability, Security, etc." - valid concerns! Depending on your context's risk tolerance brand new technology might not be an option at all, ever. You've already pointed out elsewhere the reasons to give Stimulus "the benefit of the doubt." So maybe it's within your context's tolerance? Maybe not.

But here's two distinctions I think are important. First, for many businesses and applications the biggest risk vector isn't scalability, or reliability, or even security - it's existence and viability. Can this be made (within X constraints) and do people want it? Will they pay for it? Will it turn a profit? If the answers are "no" no amount of technology will help. Rails (and Turbolinks and Stimulus, etc.) should certainly allow your app to be scalable (etc), but are optimized for the productivity needed to answer those questions - including on limited time with a tight budget. My freelance rep depends just as much on my abilities in that domain as it does on my more technical chops (a somewhat unintuitive realization for a developer). The second distinction is most important, and the piece I often think is missing - just because X technology is scalable, reliable, and secure doesn't mean any implementation of it is. What's cool about the "Rails/Basecamp way" is that it puts scalability, reliability, security, performance, etc. within reach for a wider range of people/teams. Stimulus seems like another step in that direction.

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

#62

Post by bphogan » Tue, Jan 02, 2018, 8:41 PM UTC

aaron-lebo wrote: post #57

sheraz wrote: post #25

I think this, along with its sibling Turbolinks [1], is filling a much needed gap with regards to complexity in these javascript frameworks. Myself, I've been playing with intercoolerjs [2] for a few weeks, and it is quite refreshing. These are great libraries for small full-stack teams who do not want to get lost in the complexity of front-end stuff like react, webpack, etc. [1] - https://github.com/turbolinks/turbo…

Frontend stuff doesn't have to be complex. The idea behind React is very simple and it's really something every front end dev should know. You need to understand the why of DOM diffing. It is not complicated. If a frontend dev doesn't want to learn that then they will be out of a job in a decade. It transfers, too. React, Vue, Elm, Reagent, etc, they are all doing this, because it is good, and none of them in isolati…

Front-end stuff doesn't have to be complex, but it is. For example, a lot of places using React think they need Redux too. And React-router. And many other components. React itself is quite simple. But the architectures that developers build are often incredibly complex.

This was the case with jQuery, Angular, and things that came before.

I see two main problems in software development, especially on the front-end. First, developers jump on brand-new ground-breaking frameworks and use them in production, learning how they work as they go. This results in brittle systems. That's not necessarily bad, but it's not always great from a maintenance perspective. React is hot right now. But there are a ton of in-production Angular 1.x apps out there because that was what was hot when those projects started.

That brings me to the second problem in tech - developers doing the "hot new thing" displaying a ton of hubris. It's "easy" and "straightforward", implying that anyone who doesn't get it just isn't smart or will be obsolete soon.

I'd worry more about losing my job due to not keeping up with machine learning rather than not learning whatever new JS framework people think is hot right now.

Here's the deal - web developers figured out server-side rendering 20 years ago, and managed to make turning databases into web pages easy about 12 years ago. It's possible to create applications that people love using a lot of that technology, with some JS on top. It's certainly faster to go to market with something that way.

Not every app is Facebook. A lot of the stuff people work on outside of HN fall into one of two categories:

1. Apps that are behind a firewall - internal in nature, used by a handful of enterprise users. 2. Apps that won't be around in 3 years from now because the company will shift focus/replace it with an off-the-shelf product/company gets acquired.

In both those cases, I'd look for the simplest approach to get something running, and simplest to maintain.

Bottom line: it's easier to leverage existing skill-sets than it is to ask people to learn a whole new thing all the time.

Anyway, at the end of the day, I don't really get too worked up about how another person chooses to solve the "make the browser display a web app." Every situation is different. React can be simple. So can server-side rendering with some Knockout/Stimulus/Intercooler/jQuery sprinkled around.

Maintainable quality code that makes money wins in the long run. Whatever you implement it in.

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

#63

Post by meesterdude » Tue, Jan 02, 2018, 8:43 PM UTC

itwy wrote: post #60

learc83 wrote: post #56

Earlier quoted context omitted.

The central argument of your post appears to be based solely on personal opinion because you provided no evidence to back it up. meesterdude provided evidence that runs counter to that opinion. I'm not sure what you're complaining about.

He's parroting what they said. "rewritten"... more like revamped.

> That’s really the bottom line here: We rewrote Basecamp from scratch and it turned out great!

https://signalvnoise.com/posts/3856-the-big-rewrite-revisite...

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

#64

Post by bphogan » Tue, Jan 02, 2018, 8:43 PM UTC

jaredcwhite wrote: post #32

As a Rails dev, I find this very interesting. I've already jumped on the Vue bandwagon and have had a pretty good time using it. That being said, I recently started a new small-ish Rails project and loaded Vue in via 5.1's Webpack integration...and ended up just hacking together some jQuery stuff for minor front-end dynamism. It just was easier/faster for me to do that in this particular context. However, I could def…

This has been my experience on the last two small things I built. I just reached for the jquery (or even just regular JS) because I didn't need that much.

Isn't it cool to have choices? I don't care if it's not cool to use jquery anymore. I shipped stuff and I'm not even sorry.

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

#65

Post by tannhaeuser » Tue, Jan 02, 2018, 8:58 PM UTC

aaron-lebo wrote: post #57

sheraz wrote: post #25

I think this, along with its sibling Turbolinks [1], is filling a much needed gap with regards to complexity in these javascript frameworks. Myself, I've been playing with intercoolerjs [2] for a few weeks, and it is quite refreshing. These are great libraries for small full-stack teams who do not want to get lost in the complexity of front-end stuff like react, webpack, etc. [1] - https://github.com/turbolinks/turbo…

Frontend stuff doesn't have to be complex. The idea behind React is very simple and it's really something every front end dev should know. You need to understand the why of DOM diffing. It is not complicated. If a frontend dev doesn't want to learn that then they will be out of a job in a decade. It transfers, too. React, Vue, Elm, Reagent, etc, they are all doing this, because it is good, and none of them in isolati…

I'd be careful with predictions wrt JavaScript frameworks. Though I personally like React, just two or three years ago Angular was the framework of choice for many (I've never been a fan of it). Front end framework churn seems inherently cyclic in nature, where a new minor generation breaks with tools of the slightly older generation to define itself on the marketplace.

Moreover, it must be said that neither React nor Angular are front end libraries in itself; they merely organize DOM manipulation and event handling in a more or less bureaucratic way.

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

#66

Post by c8d3f7b49897918 » Tue, Jan 02, 2018, 9:04 PM UTC

aaron-lebo wrote: post #57

sheraz wrote: post #25

I think this, along with its sibling Turbolinks [1], is filling a much needed gap with regards to complexity in these javascript frameworks. Myself, I've been playing with intercoolerjs [2] for a few weeks, and it is quite refreshing. These are great libraries for small full-stack teams who do not want to get lost in the complexity of front-end stuff like react, webpack, etc. [1] - https://github.com/turbolinks/turbo…

Frontend stuff doesn't have to be complex. The idea behind React is very simple and it's really something every front end dev should know. You need to understand the why of DOM diffing. It is not complicated. If a frontend dev doesn't want to learn that then they will be out of a job in a decade. It transfers, too. React, Vue, Elm, Reagent, etc, they are all doing this, because it is good, and none of them in isolati…

> The Turbolinks/Intercooler approaches seem to be managing state with the DOM,

I won't speak for turbolinks, but with intercooler the idea is to return to a stateless architecture, the second aspect of the REST-ful architecture[1]. State, as such, is stored on the server, not on the client.

It has scaled quite well in my applications: browsers are very fast at swapping new HTML into a page. The downsides can be additional chattiness with a server and a lack of interactivity if you are building a fancy (or fancy part of an) application, such as a game. In those cases, intercooler is not a good choice.

[1] - https://en.wikipedia.org/wiki/Representational_state_transfe...

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

#67

Post by pwaai » Tue, Jan 02, 2018, 9:04 PM UTC

aaron-lebo wrote: post #57

sheraz wrote: post #25

I think this, along with its sibling Turbolinks [1], is filling a much needed gap with regards to complexity in these javascript frameworks. Myself, I've been playing with intercoolerjs [2] for a few weeks, and it is quite refreshing. These are great libraries for small full-stack teams who do not want to get lost in the complexity of front-end stuff like react, webpack, etc. [1] - https://github.com/turbolinks/turbo…

Frontend stuff doesn't have to be complex. The idea behind React is very simple and it's really something every front end dev should know. You need to understand the why of DOM diffing. It is not complicated. If a frontend dev doesn't want to learn that then they will be out of a job in a decade. It transfers, too. React, Vue, Elm, Reagent, etc, they are all doing this, because it is good, and none of them in isolati…

> Frontend stuff doesn't have to be complex. The idea behind React is very simple and it's really something every front end dev should know.

You are always going to have a hard time convincing others when you speak in absolutes while invalidating all other cases.

To me these non-full stack frameworks actually meets a totally neglected market full of people that come from jQuery before even learning vanilla Javascript.

Different strokes for different folks, and that goes for how perception of complexity is interpreted. Someone knee depth into React/Redux will not be able to walk in the shoes of someone just exploring or even experienced developers looking for something more simple and easier to get into.

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

#68

Post by andrewingram » Tue, Jan 02, 2018, 9:27 PM UTC

andrewmcwatters wrote: post #29

andrewingram wrote: post #13

Earlier quoted context omitted.

It bothers me a bit that it feels intentionally dismissive of (or oblivious to) the current state-of-the-art of JavaScript frameworks. None of the criticism mentioned feel like an honest reflection of my last two years working with React (4 years total). Universal rendering is mainstream, there are plenty of options for vastly simplifying initial setup and overall complexity (eg Next.js). From what I understand, simi…

> It bothers me a bit that it feels intentionally dismissive of (or oblivious to) the current state-of-the-art of JavaScript frameworks. This is definitely not software for you then.

I don’t follow, most of the things it complains about aren’t current problems, they’re historical. The cutting-edgeness is irrelevant (and I suspect we mean different things by it anyway). The problem is that the document is arguing against an inaccurate caricature of other technologies

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

#69

Post by crescentfresh » Tue, Jan 02, 2018, 9:31 PM UTC

jaredcwhite wrote: post #32

As a Rails dev, I find this very interesting. I've already jumped on the Vue bandwagon and have had a pretty good time using it. That being said, I recently started a new small-ish Rails project and loaded Vue in via 5.1's Webpack integration...and ended up just hacking together some jQuery stuff for minor front-end dynamism. It just was easier/faster for me to do that in this particular context. However, I could def…

> Vue is overkill

The number of projects where something as small and simple as Vue could be considered overkill has to be remarkably small, I feel. I've used Vue in single pages (i.e. a single page of a large application) inside a single div as needed. In my case attaching behavior inside a modal dialog (ie the modal was managed by some other framework). It is very small and lean as is.

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

#70

Post by jdc0589 » Tue, Jan 02, 2018, 9:58 PM UTC

sheraz wrote: post #25

I think this, along with its sibling Turbolinks [1], is filling a much needed gap with regards to complexity in these javascript frameworks. Myself, I've been playing with intercoolerjs [2] for a few weeks, and it is quite refreshing. These are great libraries for small full-stack teams who do not want to get lost in the complexity of front-end stuff like react, webpack, etc. [1] - https://github.com/turbolinks/turbo…

its not "cool" anymore, but I always thought knockout was pretty simple, worked well, and fulfilled a lot of this use-case.

I built a couple knockout based apps that worked phenomenally well across lots of platforms, and were pretty lightweight dependency wise. Organization and convention was paramount to keep consistent since it doesn't enforce a bunch of best practices like a larger framework would; but, looks like all of these sit in basically that same space.