Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›2 »

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Can I just say, goddamn Ember is complicated. I'm working through the free Tuts+ tutorial, but I think some things changed between the tutorial date and the 1.0 release, so the code in the final example doesn't work properly. Unfortunately Ember is opinionated and I don't know its opinions, so I'll be damned if I can figure out what's going on. I'm trying to keep going, because I feel like I'm one or two breakthroughs away from a really powerful prototyping framework, but goddamn.

# ¿ Oct 7, 2013 18:06

Adbot: ADBOT LOVES YOU

# ¿ May 7, 2024 23:23

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

DreadCthulhu posted:

I'm familiar with Backbone and could get that done in there pretty painlessly, but I keep hearing that with Angular you might get more structure that would implementing something like the above a less boilerplatey process. I'm a big fan of a thick API approach (and I have to support virtually the same functionality in mobile as well, meaning I need to push as much logic down as possible to avoid duplication), and am very happy with treating my MVC web UIs as a really dumb and simple wrapper, with no sophisticated logic. Is that something Angular would be a great fit for?

I don't know enough to answer your questions, but the Ember "getting started" tutorial is a client-side todo MVC app. Looking over it might help you decide.

# ¿ Oct 17, 2013 19:24

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

I want to learn about testing, both unit and integration. Can anyone point me at a real low-level, in-depth introduction? Something like Todo MVC for Javascript testing. I get the idea, but I don't know where to start, or how to approach writing tests, or even how to integrate testing into my workflow. It would be nice to learn by example.

# ¿ Dec 18, 2013 19:01

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Is there any kind of super-light, file-based database I can use with something like Node? I ask because I do a lot of prototyping. I deploy to a lot of different environments that I do not control. Anything that reduces the number of dependencies I need makes my life so much easier. I don't care about performance, scalability, or even data integrity, really. I just need something that looks vaguely like a DB that I can use for prototypes.

# ¿ Mar 27, 2014 00:12

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

I'm no where near qualified enough to dole out hardened recommendations, but I really like Ember. Their approach to the router, and data bindings, and the forthcoming Ember Data just works for me. I also like Handlebars. It has a huuugggge learning curve though.

# ¿ Mar 28, 2014 05:23

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Kobayashi posted:

Is there any kind of super-light, file-based database I can use with something like Node? I ask because I do a lot of prototyping. I deploy to a lot of different environments that I do not control. Anything that reduces the number of dependencies I need makes my life so much easier. I don't care about performance, scalability, or even data integrity, really. I just need something that looks vaguely like a DB that I can use for prototypes.

MrDoDo posted:
SQLite?

wwb posted:
How vague? If you just need a key value store a hashtable of json objects works great . . .

Griffith86 posted:
MongoDB would be my suggestion.

Subjunctive posted:
Yeah, if you can't get away with just serializing objects as JSON, sqlite is the go-to choice these days. If you don't need the relational stuff, leveldb is pretty straightforward and pleasingly fast.

Mr. Wynand posted:
For god's sake just use sqlite before jumping into mongodb. In real life, most things have meaningful relationships to eachother, and 99 times out of 100 a relational database is a much better model for that than a document store or an object graph. This whole kneejerk nosql movement drives me batty to no end. Sure it has its applications and many things can be used for some fine optimizations, but I don't hold with breaking it out for no specific reason.

Following up on this. Some context: I'm a designer, but I like to prototype when I can. I don't write production code, and I never will. With that said, I'm trying to gradually improve my prototyping skills. For me, that means moving from strictly client-side prototyping to some client+server prototyping. I've latched on to Node because it's Javascript and that's a language I'm already learning. I tried to pick up Rails once, but learning an entirely new language on top of a entirely different paradigm was too much. Node lets me vomit out code that approximates my design concepts much more quickly than if I had to learn a new language.

Back to databases. Bare with me, because I don't know what I'm talking about. Originally, I was using Local Storage. Then, based on the advice from the tread, I whipped up a simple CRUD API using NeDB, which describes itself as "SQLite for Node.js projects," with an API that "is a subset of MongoDB's." It was really easy to use, and makes a lot of intuitive sense to me, until I start to think about relationships (which, as Mr. Wynand points out, is 99% of even silly little prototypes like mine). From what I can tell, I have to do a lot of the "relational" part myself: Either by maintaining multiple files, or by serializing the relationships inside each record. To me, it seems like NeDB isn't really SQLite at all, except in the sense that it is file-based.

Now I think I should just go back to something like Node-SQLite. But, what gives me pause is how much more difficult the syntax seems to be. Instead of an API, it looks like I basically construct query strings and pass them to the DB. It seems like I'm missing something, because it looks my choices are either 1) a nice, easy-to-use Javascript API, but a database that doesn't really deal with relationships or 2) lots of string manipulation. So I guess my question is, am I misinterpreting how relationships are modeled on the NeDB side? Alternatively, am I missing the API layer for the SQL side? Or perhaps I just need to harden the gently caress up?

# ¿ Apr 16, 2014 18:25

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Mr. Wynand posted:

Those query strings you speak of are the SQL language, and for better or for worse pretty much all relational databases work with some flavor of it. Although the syntax might not be very pretty and often counter-intuitive, the core structure of it (conditions, joins, selects etc) is more or less just relational algebra which, barring some unfathomable advance in theoretical mathematics, is the be-all end-all model of working with relational data, period. Point being: it may look weird, but it's actually the best way of doing those sort of things.

But anyway, you don't need to worry bout any of that - as you suspect, you are indeed missing an API layer here, usually you don't have to work with SQL strings directly (and there are in fact good reasons you should actively avoid it) - the thing you are missing is an ORM library. I don't have any specific experience with node ORMs but it looks like there's no shortage of them. You'll be able to just work with JS objects. The SQL strings are still going to be there, and it's good to remain peripherally aware of that fact, but for the most part it will just be magic "put object into database" -> "get object form database" and most will let you set up relations and stuff without getting too bogged down with joins and stuff, at least for the trivial case.

I know this is just for prototyping and whatnot but I really thinking picking up some SQL basics is going to serve you well over the very long term, even if you never ever write production database code. It's not really that complicated a model but it's extremely powerful and widely used, it's going to help you make sense of a lot of stuff.

ORM, fantastic. That was the term I'm missing, thank you.

As to your larger point, sigh, I know, you're right. In fact, I've actually taken a database class before, years and years and years ago. It was the course that convinced me that computer science was not for me. So while I have a passing familiarity with the terms you mentioned, my knowledge is so calcified as to be basically useless. My hope is that an ORM library allows me to ease my way back into databases while still affording some degree of productivity.

# ¿ Apr 16, 2014 19:14

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Not really sure how to Google for this, but for modern Javascript, what kind of style recommendations are there for quotes vs. double quotes? Sometimes people seem to use double quotes extensively. Others use single quotes. I cut my teeth on C-like languages and Perl, so by habit I tend to only use double quotes for interpolation or escaped characters, but I wondered if modern JS has other conventions?

# ¿ May 9, 2014 19:36

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Interesting, thanks. You ask people about tabs vs. spaces, or braces at the end of the line vs. braces on a new line and all hell breaks loose. With quotes, it sounds like it's basically personal preference.

# ¿ May 9, 2014 22:12

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

EVGA Longoria posted:

Bower is just a package manager for website libraries.

It handles things like dependencies and keeping your libraries up to date for you, like any package manager. So if you have AngularJS + Bootstrap + Bootstrap-Angular + UI-Router all together, it can get a bit frustrating to manage all of that. That's where Bower is great.

Just using AngularJS? Drop that SOB in your JS folder. Or, even better, use one of the open CDNs for it (GoogleCDN is the official one @ https://developers.google.com/speed/libraries/devguide#angularjs ) -- no need to even download it in that case, and you might speed up your user's experience some too.

It's been a while since I've used Bower, but does it behave consistently? Last time I tried it, some packages would put their stuff in subdirectories, some wouldn't. Some would include non-JS assets, some wouldn't. Some would include version numbers, some wouldn't. In the end I'd still have to go through and figure out how the package named itself so I didn't see the value. Maybe I'm not using it properly or things have changed, though...

# ¿ Jun 21, 2014 05:11

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

EVGA Longoria posted:

Yeah, this. It's basically all up to the package author how it's laid out. Half of them are just dist files, half are a full distribution including src and tests. It really is crap, but it's the kind of crap that comes about when working backwards with no central authority.

So really, Bower should come with the caveat that it's only useful if you buy into the whole webdev toolchain: Setting up your package such that it can install all its dependencies, setting up your repository such that it ignores Bower's mess, use a task runner in such a way to build something that doesn't include all the extra cruft, etc.

# ¿ Jun 22, 2014 20:04

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

I wish the web development community was half this dedicated to accessibility.

# ¿ Jul 7, 2014 16:06

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

^ I don't know what Middleman is, but that doesn't look like any Ember app I've ever seen. I normally wouldn't chime in since this is not really my area of expertise, but Ember is really opinionated about how things get done (which is why I like it). If you're not going to do things "the Ember way," then you're going to run into poo poo like this at every turn. Right now, "the Ember way" seems be Ember CLI. As it stands, it looks like you're using a combination of standard Javascript (app.js), Coffeescript? (controllers.em), and whatever Emblem is. Any one of those could be breaking Ember's "convention over configuration" assumptions.

Anyway, to answer your question, the Ember CLI documentation expects outlines where it expects to see things. Personally, I prefer pod structure. The Ember core team has indicated that pod structure is the future, but the tooling isn't as good yet.

On an unrelated note, HTMLbars just landed in canary, so soon the world will be freed from the scourge of metamorph tags! :neckbeard:

# ¿ Aug 20, 2014 18:32

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Wheany posted:

Man I wish all these frameworks would take an immediate timeout in the documentation when they introduce some cute/non-obvious functionality.

Examples being Ember's function prototype extensions for computed properties and observers (meaning stuff like getButt: function(){}.property('leftCheek', 'rightCheek')) and Angular's usage of function.toString() and then parsing the parameter names from the string representation for dependency injection.

When I notice things like that, it's like an immediate needle scratch moment and I spend the next several minutes trying to find out what the hell is happening.

Not sure if this is relevant since my Javascript isn't fundamentally that strong, but I was just reading over Ember's prototype extensions documentation. The computed property stuff is mentioned at the end. I'm not sure how long that page has been around though, and it would be nice if the page indicated when it was introduced, perhaps by version number, or if there was a feed for non-trivial documentation updates.

# ¿ Aug 27, 2014 14:28

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

I'm working on a single-person/hobby Node+Ember app to up my "full stack" prototyping game, and am certainly not a "real" developer by any means, but I sometimes have to laugh at how much of a clusterfuck the tooling is. Between idiomatic Node and idiomatic Ember, I am using three package managers (NPM for Node, NPM again for Ember, Bower for Ember) and two task runners (Grunt for Node, Broccoli for Ember). The working directory for my little tinker app is over 300+ Mb...

Beyond that, even though both the client and the server are nominally Javascript, their module loaders are different enough to trip me up whenever I switch from one (Ember and its resolver) to the other (Node's require system). Then there's the context switching between callback-based, event-based, and promise-based code styles (which I suppose is useful for people like me who are trying to get a better grasp on the fundamentals). Aaaand the fact that my project has more dotfiles/config files than my home directory.

# ¿ Aug 30, 2014 20:23

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

I think what you're trying to do would be better suited to the view, particularly the "didInsertView" hook. Maybe something like?

code:

App.IndexView = Ember.View.extend({
  didInsertView: function() {
    // jQuery!
  }
});

# ¿ Sep 4, 2014 20:19

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

My Rhythmic Crotch posted:

http://lmgtfy.com/?q=python+model+view+controller

The commonality is that they are written in Javascript? I give up

edit: I'll try not to be a dick for a second. MVC is just a concept, and so it could be implemented in any language where you have GUI capabilities. If the specifics of a certain framework seem odd then I can offer 3 suggestions: look at another framework, look at the source code to that framework, or try to implement whatever it is you want to do without a framework at all and see what happens (you might be surprised how easy it is to live without it).

Related, but here are a poo poo ton of ways to do it in JS and things that compile to JS: http://todomvc.com

# ¿ Oct 5, 2014 01:53

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

You might look into Ember CLI too. Like everything Ember, it has its own take how to handle modules. I don't really know what half this stuff means, but I signed for Ember knowing that people smarter than me were going to impose their opinions my workflow, so best to just go with it.

# ¿ Oct 19, 2014 21:17

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Ember just announced its roadmap for v2.0. I love Ember, but I only write toy apps so I'm not really qualified to preach. Still, I like their "pave the cowpaths" approach to adding features. I also like how the tooling and documentation are integral parts of the development cycle, and their commitment to minimizing breaking changes. The TL;DR seems to be "aping cool features from React, avoiding the Angular 2.0 clusterfuck."

# ¿ Nov 4, 2014 00:07

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

TildeATH posted:

So I finally jumped into MVC and built a small app with Ember and Ember-CLI but, I don't know, it just seems too over engineered to me. I don't work on a big team, and for some reason I don't like the jQuery dependency and so I'm going to play around with React, which looks interesting. I'm a little leery of JSX, though, and prefer writing out the vanilla JavaScript. Does that make sense?

Not that you shouldn't play around with other frameworks, but removing jQuery as a dependency is on the Ember roadmap:

quote:

Once we move over to HTMLBars, the interaction between Ember.js and the DOM gets smaller. We can probably treat jQuery as an optional dependency and only use it if it is available via globals or as an AMD module. We just want to make sure that we remove components/views using jQuery if its available so that jQuery UI widgets that have stored data in the DOM via jQuery.data() get cleaned up appropriately.

(The HTMLBars thing took a lot longer than they thought it would.)

# ¿ Jan 22, 2015 18:58

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Wheany posted:

I thought I'd take a bold new step and write a "unit test"

So I went and read http://www.ember-cli.com/#testing

And surprise surprise, the documentation is real bad.

I can run "ember test" which will magically run all files through jshint, which it does anyway when building. I say magically, because as far as I know, the jshint-test has no file of its own.

"Test filenames should be suffixed with -test.js in order to run."
Sure, but where should I put them?
They even give me source code for a test that I could c&p to a file and run and have fail, if I knew where to save it.

Under <projectdir>/tests/unit

Doesn't Ember CLI create unit test stubs whenever use generate? You could probably generate a few dummies to see what scaffolding it spits out and where for a more practical example. But overall I agree, the Ember CLI page and documentation sucks. For a long time, it was like "sure pod syntax works out of the box just fine," when in actuality there was an active Github issue to add support. Ugh.

# ¿ Jan 27, 2015 19:11

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

TildeATH posted:

I've got an ember CLI project and I want to create a select with options dynamically outside of ember-land and use Select2 to turn it into a Select2 thing. I added select2.min.js to my brocfile and since ember already has jquery baked in, I thought I could do $("my-select-element").select2() somewhere in the bowels of some javascript somewhere and be fine.

But it looks like the select2 function isn't being registered and comes back undefined. Anyone got any ideas why and suggestions on how to make this work? I realize I'm operating outside what Ember wants me to do, so I know the answer may be, "Nuh uh".

Are you doing app.import(...) in the brocfile? I include things like D3 and moment and they "just work" in views when I need them without any extra boilerplate so seems like what you are trying to do should be fine.

# ¿ Feb 2, 2015 18:12

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

I've hosed around with Gulp and Grunt and Broccoli a little, and when I have a choice, I just end up using NPM scripts. Chaining together what are essentially a bunch of simple shell commands is, at worst, no more time consuming than whatever weird bugs and incompatibilities I'd inevitably run into with dedicated task runners.

# ¿ Feb 6, 2015 06:29

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

RobertKerans posted:

Grunt/Gulp are fantastic for design, where a fairly large set of scripts all doing specific things to a prototype are necessary. But for most dev tasks, yeah, NPM scripts are generally better.

I'm a designer, I'd love to hear some examples of how you're using those tools to prototype...

# ¿ Feb 6, 2015 18:15

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Helicity posted:

I have to give a presentation to 40 devs tomorrow on script loading and module patterns. What a cluster-gently caress front-end dev has become, sheesh.

You're not kidding. I'm working on a stupid little side project and decided to embrace "modern" practices. It's just a skin for my site. But, I thought I'd use it as an opportunity to put together a build system with asset compilation, use a "package" "manager" (Bower) for front-end stuff, and keep things under version control.

I'm trying to do everything with NPM scripts, because after a few days I realized I was spending a lot more time on Grunt than it was saving. For a collection of static pages that I am using to write my CSS, I need the following: 1) Autoprefixer and 2) LESS for stylesheets, along with 3) HTTP-server, 4) live-reload, and 5) watch for live reloading. On top of that, I am using Bower for 6) normalize.css, 7) Font Awesome, and 8) Retina.js. To make that work, I have to maintain a 9) package.json file, which cannot contain comments, because beep boop I am a robot. Bower wants a 10) bower.json too, with its own required version. Luckily, I found 11) versiony-cli so I can automate package.json -> bower.json version synchronization. Of course, I had the audacity of wanting to change where Bower puts its poo poo, so that requires a separate 12) .bowerrc file. And now I have a bunch of junk I don't want to commit so I have to edit my 13) .gitignore file. To save time, I added NPM and Bower poo poo to 14) ~/.gitignore_global. Unfortunately I don't understand git, so I use SourceTree, which uses 15) ~/.hgignore_global.

All that for HTML and CSS. It still breaks at the drop of a hat. Watch dies whenever I switch branches because the files are temporarily deleted. Parallelshell is an ugly hack and the live-reload process often dies but doesn't exit cleanly, so the port it uses stays in use until I manually kill the process. (I added a bash script to do that.) Autoprefixer sometimes requires magic comments in my code to tweak behavior. Linters do too, or they want their own dot files. My node_modules directory is over 100 Mb right now. Any time NPM dies, it drops a nice, stinking poo poo of 16) an npm-debug.log file in my project directory. Worst of all, I just tried to hook up a module loader, Browserify (17) and the whole thing fell apart. My choices are to either type out require("../../../../vendor/package/random/git/structure/module.js") or install 18) debrowserify, which never works properly because, surprise surprise, random bower.json files on Github are often broken.

I don't know how you people do this professionally.

# ¿ Apr 2, 2015 02:10

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Thermopyle posted:

Gulp is good, but when I was learning I wish someone would have pointed out to me that you could use npm as your build tool, so I usually like to bring that up when a discussion arises around it.

I almost always use npm as my build tool nowadays.

I use NPM as a build tool when I can but then package.json happens and there's no way to add comments with some horribly convoluted hack because web development. :sigh:

# ¿ Jul 29, 2015 15:17

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

I have a very, very large project that uses LESS on the frontend. I'd like to integrate Zurb's Foundation Emails, which is written in SASS. Is there any non-idiotic way to integrate the two? Right now I'm considering some kind of awful two-phase compile process, where I have a small shim SASS file to override Foundation defaults and then the compiled CSS is imported to a LESS file, where all the project-specific classes are defined.

The other option I am considering is just going with SASS for the email component, and while that is good because it offloads the problem of figuring out how to support a million email clients onto Zurb, it creates a separation from the rest of the frontend, which will invariably mean the email styles will get out of sync with the rest of the project.

E: What I'd really like is to convert SASS to LESS. I see there's grunt-refactor but alas, the project uses Gulp.

# ¿ May 11, 2016 06:38

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

I'd just do SQLite, you can npm install it without anything else and use something like ORM2 to avoid actual SQL.

# ¿ Aug 9, 2016 16:31

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Kind of a shot in the dark here, but does anyone use Selenium (or some front end for Selenium) for functional testing? And if so, tried to do full page screenshots? Apparently there's some years-old bug in Chrome webdriver that makes this not work. But Firefox and Phantom have their own issues. Like, surely mine isn't the only company in the world that wants to screenshot functional tests on a wide range of browsers (including mobile). Can someone point me at the right Google terms?

# ¿ Aug 14, 2016 16:57

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Well I'm an idiot and npm installed a side project in my Dropbox folder and it utterly hosed up Dropbox. I hate FE development.

# ¿ Aug 18, 2016 05:01

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Thermopyle posted:

The output of computer generated files is usually unintelligible. If you're using this stuff your HTML is computer generated. Most of my projects nowadays involve a skeleton HTML file with like 10 lines and then my build tools insert all kinds of poo poo in there. There is no reason for you to look at it, just like there's no reason for you to look at the contents of the executable files generated by your C++ compiler.

I'm sure when people started using compilers to generate machine code there were people who got mad because they didnt like the look of the generated code.

Tom Dale of Ember gave a talk related to this recently. He argues the major frameworks are morphing into compilers for the web. https://tomdale.net/2017/04/making-the-jump/

# ¿ Jul 2, 2017 18:43

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

One thing with BEM, what's with the double underscores? Like why is that a thing?

# ¿ Jul 21, 2017 15:27

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

But I mean, why two dashes/underscores instead of one? I'm a designer so I look at that, find it to be aesthetically displeasing, and wanna know why.

# ¿ Jul 21, 2017 15:38

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

I�m looking for a Node framework to complement Ember on the frontend. Specifically, I�d like something opinionated like Ember, with a focus on tooling and stability. I�m only a hobbyist, so I appreciate structure. Any suggestions for what I should look at? It seems like there are a lot of dead frameworks for Node...

# ¿ Oct 12, 2017 17:29

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Express is decidedly unopinionated, and Koa looks like �Express, but with generators.� Hapi is interesting though.

# ¿ Oct 13, 2017 15:52

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Helicity posted:

Hapi is nice if you want stable and opinionated. It's not nearly as fast in benchmarks, but in real-world use the performance difference is considerably less noticeable.

Yeah this is what I�m looking for. Like I said, I�m a hobbyist. I�m working on a project to scratch a personal itch and stay somewhat current in modern webdev. I�m more interested in the frontend, but the nature of my project requires some server code. I�d rather focus on the particulars of my business logic and outsource the details of things like session management and authentication to a stable, opinionated framework. This will likely never see a user other than myself, much less run into performance bottlenecks. Plus, I want to write code that I can abandon for a few months and come back to without major breaking changes to the ecosystem. Ember does semver and maintainability as well anyone � if Hapi is similar, then that�s ideal.

# ¿ Oct 14, 2017 03:31

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

I feel your pain. I make fun of the Javascript community and its incessant need to invent new frameworks every week, but at least the field is evolving. Design tools are universally awful. They�re all about drawing screens with shape primitives like rectangles and lines. None of them model state in any meaningful way, and none have truly broken out of the print mindset of a small number of fixed sizes. AirBnb and Framer are doing some cool stuff, but they�re not accessible to most designers. Everything else � Sketch, Figma, Principal, Adobe (Photoshop, Illustrator, XD), Invision � is essentially an extension of a mindset that dates back to the 80s, if not earlier. Imagine if the programming world had more and more powerful IDEs built atop BASIC. That�s basically design tools in 2017.

# ¿ Dec 9, 2017 18:22

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Just curious since I only tangentially follow Javscript developments, but is there any notion of a Javascript standard library?

# ¿ Feb 9, 2018 05:45

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

I decided to play around with Docker today. I'm sure it's cool but it's darkly humorous to me that within an hour of starting I was using one syntax for the Dockerfile (sentence-case, extension-free), another for docker-compose.yml (standard filename), and a third for .dockerignore (system file). This seems needlessly brittle, especially when it comes to shared values like ports to expose or paths. Do I really just need to copy and paste across these files (and my project files) or is there a better way to glue everything together?

# ¿ Mar 20, 2018 02:16

Adbot: ADBOT LOVES YOU

# ¿ May 7, 2024 23:23

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Spraynard Kruger posted:

I don't think these things usually involve much copying and pasting across them... The Dockerfile defines how to build the image (start with a Node base image, install my npm packages, put app code here, etc). The docker-compose.yml file is an optional, more structured way to store your development settings. And .dockerignore is just like .gitignore, a simple list to define what shouldn't be put inside your Docker image (like your .git folder, maybe your node_modules or Python virtualenv, etc).

The Fool posted:

The Dockerfile defines the container image you are going to run.

The docker-compose.yml file is for settings while running the container. Basically everything you define in docker-compose you should be able to instead define in the command line if you so choose.

Fair enough. Maybe I�m not using Docker for its intended purpose, but I tend to pick up projects then abandon them for months at a time, after which the Javascript universe has changed � new Node fork, new NPM replacement, new OSX version changed everything, etc. I thought Docker might be a good way to abstract over some of that churn.

Almost out of the box I�m mounting directories so I can do live code development in Docker containers. That means copying path names between the Dockerfile and docker-compose.yml. Then, I already had port settings for my app in a config file, so I have to copy those values to docker-compose.yml. Then .dockerignore starts looking a lot like .gitignore (but not exactly). The end result is I miss one slash or colon somewhere across a dozen various configuration files and it�s off to a Google to try to debug.

# ¿ Mar 21, 2018 16:09

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›2 »