|
I'm not a web dev. I come from an embedded background. Failure is not an option, code from the 70's has to run without issue, etc. I don't understand how anyone arrives at a tool like Bower. Not the package management or the "heavy lifting" of traversing a tree, but why any project would look at a build solution involving the step "Then we pull a shitload of unvetted code from various places around the web and shove it out to our customers" and think that the big problem with this was the lack of automation. Another link that's been making the rounds: https://scalenpm.org/ So the above strawman is acceptable at enough places that when this one service can't handle the extreme pressures of 250 requests per second the entire thing came down. And a bunch of webdevs, thinking it appropriate to pull a shitload of dependencies from third parties for daily activities, were out of luck. The solution, instead of making a local repo or checking things in to source control, is to throw heaps of money at the people who built this shambling wreck! It really seems like the entirety of frontend web tooling needs to be burnt to the ground and rebuilt by adults. Thoughts?
|
#
?
Nov 26, 2013 22:57
|
|
|
|
| # ? May 5, 2024 04:06 |
|
|
as it turns out you can't even make your own local npm repo without duplicating their entire hosed up technology stack and replicating their database.
|
|
#
?
Nov 26, 2013 23:05
|
|
|
And what's the deal with airline peanuts?
|
|
#
?
Nov 26, 2013 23:47
|
|
|
The worst part of web devs is how if I'm at any social event and I'm talking to some person that is in some way a programmer, the conversation ends up progressing to the point where I basically call all Javascript programmers retards. I've never had anybody spring "Well I'm a Javascript programmer" after I say this -- because I have no compunction saying this after they've already told me they're a Javascript programmer. For me the social filter is just not there. Fortunately the people I've done this to usually aren't web devs, which means I didn't have to have a conversation with a web dev.
|
|
#
?
Nov 27, 2013 00:26
|
|
|
Also for a description of what happens when a web dev decides to write a secure messaging system:shrughes.com blog posted:Check out http://noplaintext.com/. It promises military-grade encryption, in the browser.
|
|
#
?
Nov 27, 2013 00:29
|
|
|
See? This is the kinda poo poo I was talking about, regarding embedded/application programmers making GBS threads on web devs. I see this opinion everywhere, why is it so pervasive? I will never go away. I AM FOREVER
|
|
#
?
Nov 27, 2013 00:56
|
|
|
Embedded development is honestly really loving hard, and forces you as an individual to solve problems on your own, with uncommon tools like oscilloscopes and logic analyzers. Most other forms of programming have devolved into just pasting compiler error messages into google, and doing whatever the first thing on stack overflow says. Also note that Arduino programming does not qualify as real embedded development (in my book, anyway. And my book is the only one that counts).
|
|
#
?
Nov 27, 2013 01:23
|
|
|
Webdev is a funny problem -- the pointy end is really pretty simple UI-layer code. Doing more complex stuff gets vastly more complex in a hurry but not so vastly and noticibly complex that the "designer/developers" get clear indication they can't handle that poo poo. So they keep solving immediate problems and pushing the ball forward and you get un-maintainable clusterfucks of horse cum like vbulletin. That said, I've seen loads of desktop / embedded devs fall flat on their face when faced with simple tasks like "configure a functional web server" too.
|
|
#
?
Nov 27, 2013 01:29
|
|
|
JawnV6 posted:I don't understand how anyone arrives at a tool like Bower. Not the package management or the "heavy lifting" of traversing a tree, but why any project would look at a build solution involving the step "Then we pull a shitload of unvetted code from various places around the web and shove it out to our customers" and think that the big problem with this was the lack of automation. How is it different anywhere else? "Then we pull a shitload of unvetted code from various places around the web, build it and shove it in a .deb, and shove it out to our customers" "Then we pull a shitload of unvetted code from various places around the web, build it and shove it in a .egg, and shove it out to our customers" "Then we pull a shitload of unvetted code from various places around the web, build it and shove it in a .exe, and shove it out to our customers" Why do you trust Red Hat, PyPI or Mozilla (Firefox installer or similar), but not the people running NPM? Why are they different?
|
|
#
?
Nov 27, 2013 01:54
|
|
|
People in computer land don't understand people who are in business land, imagine that. People from embedded land don't understand people who are in "I can always fix it since it's a server and not embedded in a million little chips" land, imagine that. Fancy poo poo with pointers and unrolled loops from the 70s are not a great idea for websites in the 2010s, imagine that. Completely different domains are going to have a bit of culture shock.
|
|
#
?
Nov 27, 2013 02:52
|
|
|
shrughes posted:The worst part of web devs is how if I'm at any social event and I'm talking to some person that is in some way a programmer, the conversation ends up progressing to the point where I basically call all Javascript programmers retards. I've never had anybody spring "Well I'm a Javascript programmer" after I say this -- because I have no compunction saying this after they've already told me they're a Javascript programmer. For me the social filter is just not there. Fortunately the people I've done this to usually aren't web devs, which means I didn't have to have a conversation with a web dev. lol I'm glad yospos is effecting your day to day human interactions.
|
|
#
?
Nov 27, 2013 03:10
|
|
|
shrughes posted:The worst part of web devs is how if I'm at any social event and I'm talking to some person that is in some way a programmer, the conversation ends up progressing to the point where I basically call all Javascript programmers retards. I've never had anybody spring "Well I'm a Javascript programmer" after I say this -- because I have no compunction saying this after they've already told me they're a Javascript programmer. For me the social filter is just not there. Fortunately the people I've done this to usually aren't web devs, which means I didn't have to have a conversation with a web dev. But were they black?
|
|
#
?
Nov 27, 2013 03:11
|
|
|
Thread confirmed all assumptions concerning shrughes/ Asperger's.
|
|
#
?
Nov 27, 2013 03:40
|
|
|
if you can't build and deploy to internal servers if your companies external connection to the internet dies something has gone very wrong imo
|
|
#
?
Nov 27, 2013 03:41
|
|
|
Reminder that Java still exists and therefore embedded/compiled programmers don't get to disparage other languages.
|
|
#
?
Nov 27, 2013 03:45
|
|
|
not sure what's goin on with shrughes but it really does seem like the javascript 'community' in general seems to be reinventing a lot of basic stuff and doing it really badly
|
|
#
?
Nov 27, 2013 03:47
|
|
|
rotor posted:if you can't build and deploy to internal servers if your companies external connection to the internet dies something has gone very wrong imo number of times in my career I've wanted to build and deploy to internal servers while the external connection was down: 0 clearly a very important scenario to spend time on
|
|
#
?
Nov 27, 2013 04:44
|
|
|
Plorkyeran posted:number of times in my career I've wanted to build and deploy to internal servers while the external connection was down: 0 it's a bad practice to rely on external resources because they may be interrupted or they may just go missing completely. this is like configuration management 101 and just because you haven't been bitten by it yet doesn't mean you won't ever be.
|
|
#
?
Nov 27, 2013 04:53
|
|
|
someone was telling me that heroku works by making a deploy the same as a build so if you don't manage your own repos then you could theoretically wind up in a position where two deploys to prod from the same tag are running different versions of 3rd party libraries and I broke out in hives
|
|
#
?
Nov 27, 2013 04:55
|
|
|
Pollyanna posted:Reminder that Java still exists and therefore embedded/compiled programmers don't get to disparage other languages.
|
|
#
?
Nov 27, 2013 05:24
|
|
|
ManoliIsFat posted:I'm amazed by your desire to show you're down but conflated "script kiddies" with you're amazement that C programmers look down on people who's sole programming experience is making websites in django. I know enough to know what I don't like 
|
|
#
?
Nov 27, 2013 05:36
|
|
|
rotor posted:it's a bad practice to rely on external resources because they may be interrupted or they may just go missing completely. this is like configuration management 101 and just because you haven't been bitten by it yet doesn't mean you won't ever be. which is why every company with a website needs to own a datacenter, a power plant, fiber connecting them to every tier 1, and a paramilitary force to guard all of them reducing external dependencies is useful, but that does not make it automatically a good use of time. i once had to copy some libraries off a coworker's machine because github was being ddosed. this was an utter disaster which cost us minutes of productivity. clearly we should have then invested the time to be able to deal with this if it ever happened again (it didn't). another time i was unable to deploy because our internet connection was down. not because i couldn't fetch things needed for the build, but because our servers were not on site, and having our servers on site would have been a loving terrible idea because the office's internet connection was unreliable.
|
|
#
?
Nov 27, 2013 05:37
|
|
|
rotor posted:someone was telling me that heroku works by making a deploy the same as a build so if you don't manage your own repos then you could theoretically wind up in a position where two deploys to prod from the same tag are running different versions of 3rd party libraries and I broke out in hives Gemfile.lock is sort of a thing that people use and if you're getting two different libraries with the same sha1 hash then you're probably being attacked by the nsa and using your own repos won't help you
|
|
#
?
Nov 27, 2013 05:41
|
|
|
Plorkyeran posted:which is why every company with a website needs to own a datacenter, a power plant, fiber connecting them to every tier 1, and a paramilitary force to guard all of them I didn't mean to give you the impression that I thought you must keep your servers local, obviously offsite hosting makes sense for a bunch of reasons. I just meant that if you did have them, an external network outage should not mean that you can't deploy to internal machines as for the other part, I'm happy that you haven't been bitten by external dependencies becoming unavailable, but I'd refer you to my previous post. it's like how losing a hard drive is really the only thing that will make people think seriously about backups. rotor fucked around with this message at 05:49 on Nov 27, 2013 |
|
#
?
Nov 27, 2013 05:43
|
|
|
Plorkyeran posted:Gemfile.lock is sort of a thing that people use and if you're getting two different libraries with the same sha1 hash then you're probably being attacked by the nsa and using your own repos won't help you most people I know pin to major versions and let minor ones float but idk the details of the heroku builds so meh
|
|
#
?
Nov 27, 2013 05:45
|
|
|
the sane thing to do is to pin to major versions in Gemfile and commit Gemfile.lock (which inherently pins to a specific hash). not doing this results in such an utter mess even just during development that i really hope that not committing Gemfile.lock is rare, of course, rvm in production is apparently a thing and i guess not committing Gemfile.lock is only a little more insane that that
|
|
#
?
Nov 27, 2013 05:54
|
|
|
basically while i think you're overly harsh on some of the technology and some of the practices, i will not deny that there are a lot of completely insane and terrible things done on a regular basis that's part of why i think complaining about how it's hard to host your own npm repo is silly - you're worrying about 5 nines of reliability when most of the people using the stuff are at like 2 and have much bigger problems (and it's not even clear that those bigger problems are actually losing them money and being at 99% may well be the right choice)
|
|
#
?
Nov 27, 2013 06:03
|
|
|
Explicitly listing "we need this version of jQuery, and this version of the pane view widget, and this version of casserole widget" in a declarative manner doesn't seem that bad to me, and it's a very common thing for most projects. Distribution of libraries is another, similarly related problem: if I need "jQuery, version 1.5" where do I get it? In C projects, there's a bunch of different solutions, but the answer we use is "autoconf" / "your distro devel packages". In Python projects, there's a standard, and it is "pip / requirements.txt" / "PyPI". In Ruby projects, there's a standard, and it is "Gemfile.lock" / "Ruby gems". In Node projects, there's a standard, and it is "project.json" / "npm". In Web projects, the most popular solution is "Gruntfile" / "bower". I don't see why any of these is worse than any other.
|
|
#
?
Nov 27, 2013 06:10
|
|
|
In a lot of cases bower just doesn't do much of anything, and you've introduced an extra tool for no real point. The one JS-heavy SPA site I worked on (~20k lines of CoffeeScript) had a pile of third-party libraries, but none of them had any sort of build process (brunch just concats and minifies the contents of the vendor directory, so adding a dep was literally just save the file and add it to the repo), and none had any dependencies other than jQuery. If your libraries depend on other libraries or have their own build systems, then a dependency managing tool tends to be very useful. At the moment this isn't the case for most front-end libraries, but I suspect that'll change over time.
|
|
#
?
Nov 27, 2013 06:21
|
|
|
The real answer should be "they're in version control like everything else", because managing versions is literally what version control is for. Public development is in a bit of a different situation because people don't want to check out 7 copies of OpenCV for the seven different open-source projects they work on, but if you're developing proprietary software (or open-source software where you just release the source but don't have external contributors), there's no reason not to have one mondo-repository with all your dependencies. And then you just don't have to care about your dependencies at all for the 99.9% of the time that you're not upgrading them.
|
|
#
?
Nov 27, 2013 06:53
|
|
|
Plorkyeran posted:basically while i think you're overly harsh on some of the technology and some of the practices, i will not deny that there are a lot of completely insane and terrible things done on a regular basis the contortions you have to go through to host a local npm repo are symptomatic if a lot of things imo. this was a solved problem literally a decade ago, setting up a local rpm repo was like an hours work. but npm apparently decided that standing on the shoulders if giants was for suckers so they reinvented it and did a lovely job at it. does it matter that much? idk there's been a lot of wailing and gnashing of teeth on various mailing lists so I gotta think a lot of people wasted a significant amount of time blocked on npm and github outages that should never have impacted anyone.
|
|
#
?
Nov 27, 2013 06:58
|
|
|
Jabor posted:The real answer should be "they're in version control like everything else", because managing versions is literally what version control is for. yep
|
|
#
?
Nov 27, 2013 07:00
|
|
|
Sorry JawnV6 you are just a bad web programmer.  I mean you are obviously a smart dude but you're freaking out over an issue that doesn't bother enough web developers for them to need to address it. People at larger companies probably have (or should have) an off-site hosted versions of their build that isn't completely reliant on GitHub and/or npm but if you're just a small shop, why bother with all that? But honestly you have been doing web stuff for what? 2-3 weeks? Imagine if I started doing embedded development and wrote some stupid post ranting about how much embedded development sucks because I have to worry about memory constraints, and how, "we've had GB of RAM in other systems for years why do I have to work with a couple of megabytes? Oh and BTW I've only been doing this for ~2 weeks." rotor posted:the contortions you have to go through to host a local npm repo are symptomatic if a lot of things imo. this was a solved problem literally a decade ago, setting up a local rpm repo was like an hours work. but npm apparently decided that standing on the shoulders if giants was for suckers so they reinvented it and did a lovely job at it. It didn't really matter until node blew up this past year because no one needed a private repo when npm worked so well for everyone. I'm guessing within the year someone will figure out something that will satisfy most people's use cases. Personally my company has had to tarball node modules into S3 because npm would sometimes fail for no apparent reason and would wreck our builds. npm actually says though that if you're building an application you should be checking in your node modules into your repository.
|
|
#
?
Nov 27, 2013 08:09
|
|
|
Strong Sauce posted:
yeah my first question on looking at the giant list of bullshit you have to go through to set it up was "jesus gently caress, where is the vmware image for this thing"
|
|
#
?
Nov 27, 2013 08:15
|
|
|
Strong Sauce posted:
the point I'm trying to make is that they ignored over a decade of precedent and previous art and many, many implementations of the same thing and just did their own shitass version that can barely hold up under any decent load and is very difficult to implement local copies of, and for no good reason other than they were apparently just ignorant. The way they implemented it isn't any easier, nor does it have any other features that something like rpm doesn't. They're reinventing the wheel and they're doing it very badly.
|
|
#
?
Nov 27, 2013 08:21
|
|
|
rotor posted:the point I'm trying to make is that they ignored over a decade of precedent and previous art and many, many implementations of the same thing and just did their own shitass version that can barely hold up under any decent load and is very difficult to implement local copies of, and for no good reason other than they were apparently just ignorant. The way they implemented it isn't any easier, nor does it have any other features that something like rpm doesn't. They're reinventing the wheel and they're doing it very badly. I don't think they ignored it as much as the fact that they didn't care at the time because it really wasn't important for them to get it into their package manager. Adding all the features to get to parity with rpm would take away time from working on stuff that was more important to node.js/npm. Now that this is becoming a pain point I think it will be addressed sooner rather than later.
|
|
#
?
Nov 27, 2013 08:44
|
|
|
Pollyanna posted:Reminder that Java still exists and therefore embedded/compiled programmers don't get to disparage other languages. What does this mean?
|
|
#
?
Nov 27, 2013 10:11
|
|
|
Web is completely engrossed in the act of reinventing old ideas badly. Trying to ape 2001's Flash slowly by committee and failing, creating massive js libraries that do one thing bad (js animation anyone?), trying to transform a limited ui into a development platform but only creating worse alternatives to existing tech, the list goes on. Backend stuff can be proper cs-grade stuff, though, as long as you can differentiate between fads and the good stuff. But that's endemic of any programming environment.
|
|
#
?
Nov 27, 2013 14:17
|
|
|
MeramJert posted:What does this mean? it means pollyanna thinks "embedded/compiled" is a "side" and that it has skeletons in its closet
|
|
#
?
Nov 27, 2013 14:30
|
|
|
|
| # ? May 5, 2024 04:06 |
|
|
I thought it was something about Java having nice library/dependency management tools available. 
|
|
#
?
Nov 27, 2013 15:02
|
|
