4 ms·

I very much like Quincy, but I can't agree with this article. “The Universe is under no obligation to make sense to you.” The universe may be under no obligat

I very much like Quincy, but I can't agree with this article. “The Universe is under no obligation to make sense to you.” The universe may be under no obligation to make sense to us, but our tools are. The fact is that the vast majority of the complexity currently be introduced into web development is unnecessary for the vast majority of web applications. I built a tool to make it possible to implement most modern web UX patterns[1] with almost no javascript code whatsoever, and to be adopted as much or as little as necessary for a given project. It is possible to make modern web development simple (or at least as simple as it was in 2004[2]) if you make that a goal. Javascript fatigue is real. Lots of smart people are simply abandoning front end development altogether. The Javascript community needs to face up to this fact with an open mind and not dismiss what a significant number of people are experiencing. [1] - http://intercoolerjs.org/examples/index.html http://intercoolerjs.org/examples/index.html [2] - http://intercoolerjs.org/2016/05/19/back-to-the-future.html http://intercoolerjs.org/2016/05/19/back-to-the-future.html

DougBTX 10y ago
> unnecessary for the vast majority of web applications There's a sliding scale of what counts as "necessary" to different developers. For example, the first entry in the intercooler.js examples is a "Click To Edit UI" that doesn't escape HTML in user input. For many websites, that probably doesn't matter all that much, but for developers that care about script injection, they might go for a different solution that makes that sort of problem harder to introduce. That exposes the underlying complexity though, since using string concatenation to generate HTML is no longer a safe option.
- carsongross 10y ago
  That's because I'm using a library, mockjax, to mock out AJAX requests for the examples, to keep them as simple as possible. Any sane server side web framework is going to escape HTML for you.
  - DougBTX 10y ago
    I agree that it is good to keep the examples simple, I liked how easy it was to toggle between the live example and the source code. If the rendering was still done on the client using `userDisplayTemplate`, I'd guess that the response to the save web service call would be a JSON object. The server would then need to know that the user object it returns should have HTML strings as its properties, rather than just a plain text. Possible, but the complexity doesn't go away.
    - carsongross 10y ago
      I'm not sure what you are getting at. One of the core ideas with intercooler is to use HTML, not JSON, as your data transport, to get back to the original model of the web as described by Roy Fielding (REST/HATEOAS), rather than move more towards a JSON/RPC model. There are some good practical and theoretical reasons for doing this: http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht... http://intercoolerjs.org/2016/02/17/api-churn-vs-security.html http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht...
      - DougBTX 10y ago
        Ah, thanks, that makes much more sense. I hadn't noticed that was mock server-side code, I thought it was advocating "vanilla JS" as a client side framework, using string-bashing as a template language.
dsp1234 10y ago
A lot of open source JavaScript libraries are MIT licensed, including intercoolerjs, and the concept of "under no obligation" is directly encoded in that license: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE." [0] - https://opensource.org/licenses/MIT https://opensource.org/licenses/MIT
- echelon 10y ago
  I think the option that was insinuated here was to take one's time and talent and apply it to working under a different language's ecosystem. One that has presumably better tooling.
ng12 10y ago
There's complexity of tooling, and complexity of code. I'll take simple code over simple tools any day. The package.json in my SPA is bloated but the majority of the code is pretty simple and the bits that aren't are well-encapsulated. Back when I was using just jQuery and maybe Backbone or KO the tooling was simple but an incredible amount of rigor was required to keep the code maintainable. A big part of my job right now is providing a dev environment where people don't get fatigued -- most of the tech decisions I make are geared towards ease-of-use by backend devs. Sure, the toolchain is relatively complex, but it's a fundamental part of why I'm able to do that.
- tboyd47 10y ago
  If complexity of tools guaranteed simplicity of code, great. But if no one bothers to really understand the tools (since they change so often anyway), you end up with complex everything.
- cocktailpeanuts 10y ago
  I think there's a conflict of interest when a guy whose job is to adopt these frameworks says they're good, don't you think? Not saying you're wrong. I'm not even saying what you're doing doesn't matter. In theory it should work as you described. But I'm saying in reality you may be too into what you're doing that you don't realize what others think. I've had a few people who were in your position in my past job, and they seemed to believe what they are doing is indeed better for the team (and so did the managers, that's why they were working on it in the first place!), but from an actual "user" point of view, they didn't help at all but made me a very dissatisfied developer. The thing is most people don't officially complain about it because they don't want to be seen as a loser who "can't move fast enough". But here's what REALLY happens while you're thinking everyone's benefitting from your work: As a developer, less code WITHOUT knowing what's going on underneath is the worst feeling ever. That's one of the biggest criticisms on rails. But that's a different story since rails actually provides huge benefit as a result (and people know that it isn't going anywhere so it's worth learning) When we come to JS land, there's no clear "10X" benefit to adopting these technologies. Sure there are incremental benefits but they don't justify learning every new packaging tool / framework every couple of months. I shit you not, a lot of companies have gone from grunt to gulp to webpack (and who knows what's next) just because they're the cool new tool that's "better" than the other. Some may say I'm lying just to exaggerate, but I am not. They do this because they want to "attract new developers who are looking to work with latest technology". But in my opinion that's the stupidest thing a product building company should do. You're better off attracting great developers by building a product that's so compelling that developers want to contribute no matter what the stack is. I'm sure Snapchat had no problem attracting top talent in LA when all they had was a shitty mobile app that they didn't even bother making pretty. Lastly in most cases, only a few people on the team are responsible for taking on these framework migrations. Which means the rest of the developers just become "users" and are left feeling like some passive idiots who just follow the "early adopters". As a result the developers fall into two categories: 1. People who don't want to feel left out and pretend they like the tool and keep following (and this feeling of "following" feels really shitty if you are not a "follower" kind of person); 2. People who complain how these "upgrades" are totally unnecessary and as a result treated like "old school" by the people of group 1. Step back and think about how much efficient web development has become for 90% of developers (Not for you, who already are on board and an expert in adopting one new edge tool every month). To be clear, I know how to use all these tools (grunt, gulp, webpack, etc.) but whenever I need to build a quick prototype I just use plain old html/css/jquery. You could say you could use things like Yeoman to set up things quickly, but that's not the point.
sotojuan 10y ago
FWIW FreeCodeCamp eventually teaches fullstack JavaScript SPA application development. It'd be weird for its creator to suddenly say you don't need any of that.
Sacho 10y ago
But whatever tools you used to use for the "vast majority" of web applications probably still exist. You are under no obligation to use the newer tools. Other people are developing new tools for their different needs and different applications, but this doesn't place a demand on you to follow suit. For example, there's tons of libraries provided via CDN so you can link them in script tags. That's as far back as I can think in terms of JS tooling. Bower still exists. So do grunt and gulp. jQuery is still releasing new versions, so is angular 1. I assume backbone and knockout still exist. If javascript fatigue was an epidemic, then there would be a huge swath of developers who just want to use the current, existing tools. That would surely provide a solid maintenance base for these existing tools so you can continue to use them for a very long time. Javascript fatigue seems like a self-correcting problem.
vilmosi 10y ago
What do you mean without any JS necessary? You are introducing a JS library that does that for you, which defeats the point. Even bootstrap does that. It doesn't mean it's necessary. I can find a lot of "no code necessary" apps that do the same in angular/react/whatever.js
- carsongross 10y ago
  What I mean is that you, the developer, don't need to write any JavaScript to implement your general web application. I think this is obvious if you read the docs, which I encourage you to do: http://intercoolerjs.org/docs.html http://intercoolerjs.org/docs.html
pixelbath 10y ago
> Lots of smart people are simply abandoning front end development altogether. The Javascript community needs to face up to this fact First, I'm not sure who these people are that can afford to just not work because they had a bad experience with a Javascript framework or two. Second, I'm not sure the onus is on the community to take their (or anyone else but their own) feelings into account. I don't really see how Intercooler is any better than vanilla jQuery; you've just offloaded explicit promises and event assignment into custom HTML attributes that don't translate to any other framework. After doing some reading, it looks like you were frustrated with Angular's AJAX calls...did you try one with jQuery?
- carsongross 10y ago
  HTML-as-data-transport is the key to HATEOAS[1], which is what most distinguishes the web from other network application architectures[2]. Intercooler enables a fundamentally different network architecture than RPC-via-JSON, that of the original web network architecture as described and advocated for by Roy Fielding. I know it is easy to dismiss intercooler, especially for those with a big commitment to the currently fashionable javascript technologies, but there is some good theory behind it. It is worth spending some time reading the blog and docs to understand the deeper aspects of the library. [1] - http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht... [2] - https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS

DougBTX 10y ago

> unnecessary for the vast majority of web applications There's a sliding scale of what counts as "necessary" to different developers. For example, the first entry in the intercooler.js examples is a "Click To Edit UI" that doesn't escape HTML in user input. For many websites, that probably doesn't matter all that much, but for developers that care about script injection, they might go for a different solution that makes that sort of problem harder to introduce. That exposes the underlying complexity though, since using string concatenation to generate HTML is no longer a safe option.

carsongross 10y ago
That's because I'm using a library, mockjax, to mock out AJAX requests for the examples, to keep them as simple as possible. Any sane server side web framework is going to escape HTML for you.
- DougBTX 10y ago
  I agree that it is good to keep the examples simple, I liked how easy it was to toggle between the live example and the source code. If the rendering was still done on the client using `userDisplayTemplate`, I'd guess that the response to the save web service call would be a JSON object. The server would then need to know that the user object it returns should have HTML strings as its properties, rather than just a plain text. Possible, but the complexity doesn't go away.
  - carsongross 10y ago
    I'm not sure what you are getting at. One of the core ideas with intercooler is to use HTML, not JSON, as your data transport, to get back to the original model of the web as described by Roy Fielding (REST/HATEOAS), rather than move more towards a JSON/RPC model. There are some good practical and theoretical reasons for doing this: http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht... http://intercoolerjs.org/2016/02/17/api-churn-vs-security.html http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht...
    - DougBTX 10y ago
      Ah, thanks, that makes much more sense. I hadn't noticed that was mock server-side code, I thought it was advocating "vanilla JS" as a client side framework, using string-bashing as a template language.

dsp1234 10y ago

A lot of open source JavaScript libraries are MIT licensed, including intercoolerjs, and the concept of "under no obligation" is directly encoded in that license: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE." [0] - https://opensource.org/licenses/MIT https://opensource.org/licenses/MIT

echelon 10y ago
I think the option that was insinuated here was to take one's time and talent and apply it to working under a different language's ecosystem. One that has presumably better tooling.

ng12 10y ago

There's complexity of tooling, and complexity of code. I'll take simple code over simple tools any day. The package.json in my SPA is bloated but the majority of the code is pretty simple and the bits that aren't are well-encapsulated. Back when I was using just jQuery and maybe Backbone or KO the tooling was simple but an incredible amount of rigor was required to keep the code maintainable. A big part of my job right now is providing a dev environment where people don't get fatigued -- most of the tech decisions I make are geared towards ease-of-use by backend devs. Sure, the toolchain is relatively complex, but it's a fundamental part of why I'm able to do that.

tboyd47 10y ago
If complexity of tools guaranteed simplicity of code, great. But if no one bothers to really understand the tools (since they change so often anyway), you end up with complex everything.
cocktailpeanuts 10y ago
I think there's a conflict of interest when a guy whose job is to adopt these frameworks says they're good, don't you think? Not saying you're wrong. I'm not even saying what you're doing doesn't matter. In theory it should work as you described. But I'm saying in reality you may be too into what you're doing that you don't realize what others think. I've had a few people who were in your position in my past job, and they seemed to believe what they are doing is indeed better for the team (and so did the managers, that's why they were working on it in the first place!), but from an actual "user" point of view, they didn't help at all but made me a very dissatisfied developer. The thing is most people don't officially complain about it because they don't want to be seen as a loser who "can't move fast enough". But here's what REALLY happens while you're thinking everyone's benefitting from your work: As a developer, less code WITHOUT knowing what's going on underneath is the worst feeling ever. That's one of the biggest criticisms on rails. But that's a different story since rails actually provides huge benefit as a result (and people know that it isn't going anywhere so it's worth learning) When we come to JS land, there's no clear "10X" benefit to adopting these technologies. Sure there are incremental benefits but they don't justify learning every new packaging tool / framework every couple of months. I shit you not, a lot of companies have gone from grunt to gulp to webpack (and who knows what's next) just because they're the cool new tool that's "better" than the other. Some may say I'm lying just to exaggerate, but I am not. They do this because they want to "attract new developers who are looking to work with latest technology". But in my opinion that's the stupidest thing a product building company should do. You're better off attracting great developers by building a product that's so compelling that developers want to contribute no matter what the stack is. I'm sure Snapchat had no problem attracting top talent in LA when all they had was a shitty mobile app that they didn't even bother making pretty. Lastly in most cases, only a few people on the team are responsible for taking on these framework migrations. Which means the rest of the developers just become "users" and are left feeling like some passive idiots who just follow the "early adopters". As a result the developers fall into two categories: 1. People who don't want to feel left out and pretend they like the tool and keep following (and this feeling of "following" feels really shitty if you are not a "follower" kind of person); 2. People who complain how these "upgrades" are totally unnecessary and as a result treated like "old school" by the people of group 1. Step back and think about how much efficient web development has become for 90% of developers (Not for you, who already are on board and an expert in adopting one new edge tool every month). To be clear, I know how to use all these tools (grunt, gulp, webpack, etc.) but whenever I need to build a quick prototype I just use plain old html/css/jquery. You could say you could use things like Yeoman to set up things quickly, but that's not the point.

sotojuan 10y ago

FWIW FreeCodeCamp eventually teaches fullstack JavaScript SPA application development. It'd be weird for its creator to suddenly say you don't need any of that.

Sacho 10y ago

But whatever tools you used to use for the "vast majority" of web applications probably still exist. You are under no obligation to use the newer tools. Other people are developing new tools for their different needs and different applications, but this doesn't place a demand on you to follow suit. For example, there's tons of libraries provided via CDN so you can link them in script tags. That's as far back as I can think in terms of JS tooling. Bower still exists. So do grunt and gulp. jQuery is still releasing new versions, so is angular 1. I assume backbone and knockout still exist. If javascript fatigue was an epidemic, then there would be a huge swath of developers who just want to use the current, existing tools. That would surely provide a solid maintenance base for these existing tools so you can continue to use them for a very long time. Javascript fatigue seems like a self-correcting problem.

vilmosi 10y ago

What do you mean without any JS necessary? You are introducing a JS library that does that for you, which defeats the point. Even bootstrap does that. It doesn't mean it's necessary. I can find a lot of "no code necessary" apps that do the same in angular/react/whatever.js

carsongross 10y ago
What I mean is that you, the developer, don't need to write any JavaScript to implement your general web application. I think this is obvious if you read the docs, which I encourage you to do: http://intercoolerjs.org/docs.html http://intercoolerjs.org/docs.html

pixelbath 10y ago

> Lots of smart people are simply abandoning front end development altogether. The Javascript community needs to face up to this fact First, I'm not sure who these people are that can afford to just not work because they had a bad experience with a Javascript framework or two. Second, I'm not sure the onus is on the community to take their (or anyone else but their own) feelings into account. I don't really see how Intercooler is any better than vanilla jQuery; you've just offloaded explicit promises and event assignment into custom HTML attributes that don't translate to any other framework. After doing some reading, it looks like you were frustrated with Angular's AJAX calls...did you try one with jQuery?

carsongross 10y ago
HTML-as-data-transport is the key to HATEOAS[1], which is what most distinguishes the web from other network application architectures[2]. Intercooler enables a fundamentally different network architecture than RPC-via-JSON, that of the original web network architecture as described and advocated for by Roy Fielding. I know it is easy to dismiss intercooler, especially for those with a big commitment to the currently fashionable javascript technologies, but there is some good theory behind it. It is worth spending some time reading the blog and docs to understand the deeper aspects of the library. [1] - http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht... [2] - https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS