|
Why does an end-user care if file names and production code is not intelligible? If someone's hacked in to change code, then the problem is deeper than obfuscation.
|
#
?
Jun 30, 2017 21:03
|
|
|
|
| # ? Jun 1, 2024 23:56 |
|
|
Tei posted:Is a sign of a abstraction leaking. Do that means something to people? I don't LIKE it either, but really, how much effort are you willing to expend to write a customized WebPack that intelligently bundles your code into meaningful sub bundles that maximize performance? I can't even imagine how to do that other than hand craft each bundle by some sort of meaningfulness, but then you won't maximize performance. Pick your poison.
|
|
#
?
Jun 30, 2017 21:12
|
|
|
Tei posted:Is a sign of a abstraction leaking. Do that means something to people? 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.
|
|
#
?
Jun 30, 2017 21:37
|
|
|
People should already be having separate bundles if their use case dictates it. Many sites use at least main.js and vendor.js, with the thinking that the vendor file should be significantly larger, and also shouldn't change as frequently. Do this, then turn on HTTP/2 and see even better performance. What measurable value are you actually getting from splitting up into indeterminate chunks like that? I don't think it's the sign of an abstraction leaking or an issue of code generation - it's a sign of premature optimization, and making the build process more convoluted for no real value. I'm not convinced you would see measurable gains splitting things up in an arbitrary fashion, and on any large site you're going to slow things down for repeat users, mobile users, and poor connection users. This feels like it would be very low on the list of things you should do to improve site performance.
|
|
#
?
Jun 30, 2017 22:37
|
|
|
I don't think anyone is advocating for anyone to implement aggressive chunk splitting.
|
|
#
?
Jun 30, 2017 23:36
|
|
|
Though I don't think the build processes are more convoluted, it's just an option you enable in webpack.
Thermopyle fucked around with this message at 23:58 on Jun 30, 2017 |
|
#
?
Jun 30, 2017 23:37
|
|
|
Thermopyle posted:Though I don't think the build processes are more convoluted, it's just an option you enable in webpack. It's a plugin. If it caused me a headache in any way, for negligible improvement, I'd be frustrated. I'm still fixing bad merges and tweaking configs from a round of Webpack plugin shenanigans from December, so it could easily happen. I just look at 749 open issues and 64 open PRs for webpack and wonder if that's a good place for an asset bundler to be.
|
|
#
?
Jul 1, 2017 00:15
|
|
|
Webpack is complicated, without a doubt. It's also trying to solve some surprisingly complex problems. Unfortunately these two things often go hand-in-hand.
|
|
#
?
Jul 1, 2017 00:44
|
|
|
I feel a little slack that webpack 3 is out while I've still been trying to muster the will to learn/upgrade to webpack 2.
|
|
#
?
Jul 1, 2017 00:45
|
|
|
Kekekela posted:I feel a little slack that webpack 3 is out while I've still been trying to muster the will to learn/upgrade to webpack 2. It's a much smaller difference, your 2 config should be mostly (totally?) fine. I don't have any really wild ones but they all worked with zero effort.
|
|
#
?
Jul 1, 2017 01:21
|
|
|
Newbie question here. Why are you guys talking about Webpack and not Gulp? are not both tryiing to solve the same problem? Has gulp fallen from the cool kids grace? Can I continue using gulp, or some demon is going to remove fhe carpet from below my feets?
|
|
#
?
Jul 1, 2017 06:19
|
|
|
Tei posted:Newbie question here. Yes if you opt to choose one completely free piece of software over another entirely and completely free and open source piece of software you will be shot in the face by Satan and all his angels.
|
|
#
?
Jul 1, 2017 06:26
|
|
|
Dogcow posted:Yes if you opt to choose one completely free piece of software over another entirely and completely free and open source piece of software you will be shot in the face by Satan and all his angels. Are you saying they both have the same "Cool Kids Factor" and neither have fallen from grace.... yet? Because if is that. Good. I was scared for a minute.
|
|
#
?
Jul 1, 2017 06:39
|
|
|
Kekekela posted:I feel a little slack that webpack 3 is out while I've still been trying to muster the will to learn/upgrade to webpack 2. Be grateful that you only feel slack. It makes me feel ill.
|
|
#
?
Jul 1, 2017 06:40
|
|
|
Tei posted:Newbie question here. Gulp is a task runner. Webpack is an asset bundler that has plugins that can do things that traditionally a task runner would be used for. Use software that makes you happy.
|
|
#
?
Jul 1, 2017 07:26
|
|
|
Tivac posted:Gulp is a task runner. No man, you have to use the first ever invented tool that kind of suits your need. Don't just jump to the latest flash-in-the-pan that's been heavily used for the last four years.
|
|
#
?
Jul 1, 2017 09:30
|
|
|
Kekekela posted:No man, you have to use the first ever invented tool that kind of suits your need. Don't just jump to the latest flash-in-the-pan that's been heavily used for the last four years. The correct answer is that both Webpack and Gulp have been out for more that a few months, so you shouldn't be using either of them.
|
|
#
?
Jul 1, 2017 17:33
|
|
|
Tei posted:Are you saying they both have the same "Cool Kids Factor" and neither have fallen from grace.... yet? Because if is that. Good. I was scared for a minute. No, Gulp has fallen from grace, because it's easier to use Webpack and bash scripts to accomplish the same thing, with fewer plugins, and less configuration code. There's a balance between adopting cutting edge new technologies just because they're shiny and pretty, and getting the job done in a better, more maintainable way. Updating the DOM with jQuery, VB.NET, and Java 6 all get the job done, but at some point, increasing numbers of people say "gently caress that, I don't want to work with that". You either give a poo poo about making your code base better in a pragmatic way, or you continue suffering unknowingly. As a consequence, developers that prefer to continuously improve don't want to work with the stack and you end up with a Dead Sea effect at your organization. From an anecdotal hiring perspective, at least in the Midwest, it is harder to get quality developers if you advertise Grunt, Gulp, Angular 1, jQuery, etc. as your stack. The Javascript ecosystem and community is not just churning, but iterating at a rapid rate. Some of it's messy, but there are actual improvements, so you have to be willing to stay somewhat up to date and continually assess things. Any number of JS surveys or ThoughtWorks radar can help you determine where things are or might be moving. luchadornado fucked around with this message at 18:05 on Jul 1, 2017 |
|
#
?
Jul 1, 2017 17:58
|
|
|
Tei posted:Newbie question here. No, they are not both trying to solve the same problem. Webpack lets you build your application in a not-insane environment and then "compiles" your application to run in an insane environment. By "not-insane" I mean it provides an environment that lets you organize your project around modules that are imported and maintained on a dependency graph...just like every modern good language. By "insane" I mean the browser. Modules on a dependency graph is the core purpose and feature of webpack. Now, because of the fact that it maintains your dependency graph, its a natural place for extending into lots of other features like dead code elimination, chunking or code splitting, treating other assets like modules and a lot of other stuff. People using webpack realized that when you're using webpack, you're already using a system (the npm/package.json scripts thingamabob) that lets you run scripts which let you do most of gulps functions. Because of this, there's not really any big reason for most people to bring Gulp into the system at all.
|
|
#
?
Jul 1, 2017 19:37
|
|
|
Okey. Thanks for the replies. I think I am going to check this Webpack thing. Sounds funny. I may not need it, but is going to be a interesting visit.
|
|
#
?
Jul 1, 2017 19:41
|
|
|
To say bash and webpack can completely replicate gulp in terms of scripting and cross platform compatibility isn't quite right. Webpack has it's own blind spots and plugin bloat, for example if you want to properly adopt Typescript and rollup and things. Bash has issues with cross platform compatibility, as well as being a little more unwieldy if you have some specific transformation needs that your npm cli tools don't cover. The JavaScript ecosystem has a serious deep seated problem with tools, with churn, with documentation, with tools becoming overgeneralised and then reliant on extremely specific plugins that due to their specificity, never get maintained once they're created. In such an ecosystem, there's really not a huge problem sitting with one particular tech even if it's considered archaic, provided the company has done the work to make it work to your current requirements. Iteration for tooling in the JavaScript ecosystem has often meant trading known problems for unknown ones, which in many circumstances is just not acceptable if running under a deadline project. It's of course easy to end up stuck in your ways to the detriment of your process, but it's a misrepresentation of people and companies to say if they're using tool x they are losers who 'just can't keep up'. Javascript is a large collection of keyhole use cases and key tools which fit differently for a very wide variety of projects, owing to its popularity. It's got a very VERY long way to go before it can establish a ONE TRUE STACK or whatever.
|
|
#
?
Jul 1, 2017 23:23
|
|
|
Something that surprised me is that theres not style direction on how the modules in the node_modules/ directories are written. I wanted to find a example of well written Javascript to show to a junior developer, and tried to find a well written example in node_modules. Embarrassingly (for me) every module was written differently, and obviously in a not exquisite way. They seems to rely in the unix rule of "do one thing, but do that thing well", so they do what they need to do, but most of them are ugly code only a mother can love. I guest the reason is that theres 5.000.000 ways to write javascript, so trying to find consensus for node_modules would go against the culture of javascript.
|
|
#
?
Jul 2, 2017 07:41
|
|
|
Tei posted:Something that surprised me is that theres not style direction on how the modules in the node_modules/ directories are written. I would bet that not a small number of those look so ugly because they're been transpiled from typescript. Not to excuse bad code of course, but looking at reasonable typescript code and then seeing the transpiled version really clears up how convenient typescript is.
|
|
#
?
Jul 2, 2017 07:45
|
|
|
Yeah on the npm modules I've published I only push the lib directory, which is built with Babel. The src folder goes into .npmignore. Rather than opening the node_modules folder you should check out the project on GitHub.
|
|
#
?
Jul 2, 2017 15:05
|
|
|
Maluco Marinero posted:To say bash and webpack can completely replicate gulp in terms of scripting and cross platform compatibility isn't quite right. Webpack has it's own blind spots and plugin bloat, for example if you want to properly adopt Typescript and rollup and things. Bash has issues with cross platform compatibility, as well as being a little more unwieldy if you have some specific transformation needs that your npm cli tools don't cover. To be clear I purposely did not say that bash could or should completely replace Gulp because I was sure there's something out there that's better done with Gulp. In fact I didn't even mention bash because I feel like JS is a better choice because if you're using NPM scripts you've got node installed. So, since you brought it up, what are some of those specific things that are better done with Gulp? I'm not sure what you mean about using typescript with webpack, though. It's pretty easy, just use the advanced typescript loader and go on your way, no?
|
|
#
?
Jul 2, 2017 16:30
|
|
|
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. 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
|
|
|
Theres logical advantages with compiled stuff. "Compile time" just don't exist with interpreted stuff. And large complexity could be cut down with large complex compilers that do a good job. All of this may turn real when browsers have a solid webbytecode support. So, soonish.
|
|
#
?
Jul 2, 2017 18:57
|
|
|
Thermopyle posted:To be clear I purposely did not say that bash could or should completely replace Gulp because I was sure there's something out there that's better done with Gulp. In fact I didn't even mention bash because I feel like JS is a better choice because if you're using NPM scripts you've got node installed. Helicity brought up bash which is why I did. Usually it's to do with file transforms that don't fit within the package definition that Webpack depends upon. For example, I want: - Typescript, Javascript and support files like json, svg, etc to go to a build folder - Send the compiled files to a node folder for server side rendering (make sure it has the dependencies) - Build most of client except for major dependencies in rollup, which tree shakes, removes most of the fat, and flattens the main executing Javascript. (also removes the complexity of webpack dependency function evaluation, which can dramatically slow down mobile app startup) - We can't put all the dependencies through the rollup treatment, so we do in fact use webpack, but it's just for the last mile with 'externals' bearing most of the dependencies preminified and properly optimized. - altogether this can result in tiny bundles that execute real quick for complex apps, which is nice for handling mobile Also, command line interface watches are often incomplete or don't target files the way you want to, or are wasteful and not amenable to optimisation, watching with Gulp.watch or Chokidar plus gulp-changed allows you to boil down the watches to very specific globs and bases, whilst also removing extra passes of unchanged files. Webpack can reuse old caching information for optimisation, but is tailored to it's specific purpose, and I've never had a project that didn't also need building of say email templates, packaging of render server, client & api server for deployment. Of course, I can concede that some things could be better done in Webpack, but Webpack as the center of the world build strategies are often more trouble than they're worth, and kind of a pain if you say want to change your stylesheet preprocessor language, or need that code in an npm ready format, or a dozen other little 'off the path' use cases. Gulp serves as a nice low level build tool that allows me to express the transformations I need, and I've worked with it long enough that I can deal with it's warts. Now, I'd love something better than Gulp to come along in the npm ecosystem, that does what it does, but does it better, but that doesn't seem to be on the horizon at present. Bash scripts allow for config variables but are not nearly as expressive as code. Webpack is a very specific tool that doesn't address all the build functionality you might need for a project as a whole, even one entirely written in Javascript. Anyway, this a whole lot of words to say: Webpack good, Gulp bad, oversimplifies the issue because they are fundamentally different tools that do different things.
|
|
#
?
Jul 3, 2017 00:09
|
|
|
Most developers looking to bundle their assets should probably start with Webpack first, and use something else if Webpack somehow doesn't provide what they need. You might have a workflow that benefits from Gulp, I'll be the first one to tell you not to change if it truly fits your needs, but Webpack and Gulp serve the same purpose for many front-end developers. I've done everything you've mentioned with Webpack except the server-side rendering (isomorphic React is the devil, but that's another topic). I've replaced thousands of lines of Gulp with a 200 line Webpack config. I've updated 2-3 projects from Grunt to Gulp, and over a dozen from Gulp to Webpack. No problems with optimized bundles, tree-shaking, or watching. Shell scripts are an easy way to do things like "move all assets in X to Y" or "delete X" without bringing in plugins or anything else. They work very well as pre- and post- npm scripts, unless you have a snowflake developer that is the one person that refuses to use OSX, Linux, or WSL. .NET shops get a pass here. Most places I've seen locally still using Grunt or Gulp it's because they aren't paying down their tech debt. So for me, seeing these build tools used in 2017 is more of a symptom of a larger problem. They're the same places still using .NET 4.5 for example. I'm not going to say someone is stupid or lazy or an rear end in a top hat for not paying down tech debt or working towards being a "craftsman", but I'm personally at the point in my career where I don't want to work places that don't value those things. I like picking up new tech that solves my problems and makes my life easier, and I like being around similar people.
|
|
#
?
Jul 3, 2017 00:57
|
|
|
Maluco Marinero posted:- Build most of client except for major dependencies in rollup, which tree shakes, removes most of the fat, and flattens the main executing Javascript. (also removes the complexity of webpack dependency function evaluation, which can dramatically slow down mobile app startup) Good news, as of the latest version of webpack, you can use scope hoisting like rollup or closure instead of function closures!
|
|
#
?
Jul 3, 2017 01:31
|
|
|
Thermopyle posted:Good news, as of the latest version of webpack, you can use scope hoisting like rollup or closure instead of function closures! Oh goodo. Look I'm not gonna say there's no tech debt to be paid down in my build processes, I've just seen many times that forcing in a new tool that is ideally better has merely traded the tech debt for other chunks of tech debt. Honestly this is more than a Javascript problem than a webpack or gulp or whatever problem, the amount of almost there but still a pain in the rear end for build tools is just frustrating. Getting Typescript configured right is also way harder than it should be with common concepts like typings for dependencies and so on. Simple is better, but the brittle edges of these tools end up requiring complexity to get to a good build tool. P.S. Isomorphic React isn't really the devil, but it sure is if you decided to do it all retroactively. Built as a first class concern, it's a great way to do prerendered pages mingled with rich client code, without having to trade out performance.
|
|
#
?
Jul 3, 2017 01:45
|
|
|
Thiis how I use gulp in the template system.code:code:The file js/foo+bar+jill.min.js is generated by the real gulp. Edit: *I only had one, where files wanted to end in ";" or would break. But that was a easy fix and since I have not hit any problem. Tei fucked around with this message at 13:05 on Jul 3, 2017 |
|
#
?
Jul 3, 2017 07:04
|
|
|
Docker. Explain it to me like I'm an old fart who is set in his ways. Right now I use vagrant and install a new machine, set up a virtualenv on that, install Django, get nginx running, blah blah blah. What does Docker do different / better / worse than that? What about moving to production? My vagrant machine is "copy config files over to EC2 and you are 90% of the way there" when it's time to set up on a real server. How does Docker compare? Thanks in advance!
|
|
#
?
Jul 3, 2017 15:35
|
|
|
Lumpy posted:Docker. Explain it to me like I'm an old fart who is set in his ways. Right now I use vagrant and install a new machine, set up a virtualenv on that, install Django, get nginx running, blah blah blah. What does Docker do different / better / worse than that? What about moving to production? My vagrant machine is "copy config files over to EC2 and you are 90% of the way there" when it's time to set up on a real server. How does Docker compare? Thanks in advance! Let's talk about VMs vs. Docker/containers first. They accomplish similar things, but containers are more lightweight than a VM in terms of both size and performance. There are also a ton of Docker images already out there on hub.docker.com. If you want a Hello World app with Node, Cassandra, and nginx... just docker-compose a few pre-built images and you're up and running in a matter of minutes. An alpine-node image like what you'd use for a production Node server is like 80MB or something trivial. Download docker images and pass them around instead of trying to setup Ruby environments, dealing with Python 2 vs 3, setting up databases, etc. Another advantage of containers is if you're operating in a clustered environment. Let's say you need 20 Node containers to drive your web site. Sure, you could manually create a bunch of EC2s and manually deploy, or even autoscale with ELB/ALB, but that still involves work. With containers you can use ECS/Kubernetes/Swarm/Mesos to manage clusters of containers relatively painlessly. The final point worth mentioning relates to "copy config files over to EC2 and you are 90% of the way there". Your local development environment probably isn't the same as the EC2, and I don't mean even like both using Ubuntu 16.04 or whatever. With containers if it works on your local environment and you deploy that container to production, that's an awesome guarantee you have - you're minimizing the effects of differing environments. Reasons to use Docker, if you like/want: better performance than VMs, to get away from configuring various software on your local system, large ecosystem of pre-built images, easier cluster management, more guarantees between environments. Emphasis on the configuring on your local system and more guarantees part - those two things save so many headaches. Plus, you can still use Vagrant with Docker if you like. luchadornado fucked around with this message at 16:23 on Jul 3, 2017 |
|
#
?
Jul 3, 2017 16:13
|
|
|
Helicity posted:helpful So if I need a Django app running on gunicorn fronted by nginx using a postGRE DB, I download three (four?) containers and they all run in one Docker instance magically together? Or is an image a bunch of containers that has already been configured to "just work"? Reading these: https://www.capside.com/labs/deploying-full-django-stack-with-docker-compose/ http://ruddra.com/2016/08/14/docker-django-nginx-postgres/ it looks like the former, but I still do all the manual configuration. But then once I do that, I can somehow save that as an "image" and deploy that all willy-nilly to other dev machines / production boxes?
|
|
#
?
Jul 3, 2017 16:53
|
|
|
How the heck do you dev on VMs or docker? Unless you're vim user it seems like you're stuck using one of 3 file sync methods, none of which really work well if you want hot reloading and all that.
|
|
#
?
Jul 3, 2017 17:32
|
|
|
prom candy posted:How the heck do you dev on VMs or docker? Unless you're vim user it seems like you're stuck using one of 3 file sync methods, none of which really work well if you want hot reloading and all that. You can have folders in the VM be mounted on your host machine, so you can edit "server" files locally with whatever you want to edit them with. Which for me is MacVim  (oh god not another editor derail...)
|
|
#
?
Jul 3, 2017 17:41
|
|
|
Sometimes a virtual machine is useful. Like if you need to create a enviroment to compile for android with framework X, but the only way to do it is on a vm, because in your machine the whole stuff breaks and refuse to compile. But then you have a separate enviroment where you develop, and another (inside the vm) where you can compile. Is not nice. We should go back to write cgi programs in C.
|
|
#
?
Jul 3, 2017 17:47
|
|
|
Lumpy posted:So if I need a Django app running on gunicorn fronted by nginx using a postGRE DB, I download three (four?) containers and they all run in one Docker instance magically together? Or is an image a bunch of containers that has already been configured to "just work"? Sorry that wasn't really clear - a container is just an instance of an image, people/me tend to use them interchangeably. You download a Node image, and when it's running, the docker instance is called a container. The subject is called "containerization" because "imageification" sounds silly. Yes, Docker Compose is the preferred method of keeping several containers together on the same machine. In reality, you would only want say 1-2 nginx containers fronting multiple Node containers, so it wouldn't make sense to compose Node/nginx together outside of development. But you could build your nginx and Node images the way you want, and then use Docker Compose to bring them together onto the same machine for development.
|
|
#
?
Jul 3, 2017 18:54
|
|
|
|
| # ? Jun 1, 2024 23:56 |
|
|
prom candy posted:How the heck do you dev on VMs or docker? Unless you're vim user it seems like you're stuck using one of 3 file sync methods, none of which really work well if you want hot reloading and all that. VM's don't really work that well as you alluded. Docker is significantly easier. You can use volumes (https://docs.docker.com/engine/tutorials/dockervolumes/) for times when you really need to pass data back and forth, but for just having docker see your source: code:You wouldn't do hot reloading or development against the containerized code, though. Say you have a Node app that talks to a Postgres DB. Start the container for the DB so Node has something to talk to, then just develop away on the Node side of things just like you would if Docker weren't being used.
|
|
#
?
Jul 3, 2017 19:02
|
|