|
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 Basically, you push your code to Heroku, and a file called a buildpack that contains instructions about how to set up the runtime environment (language dependencies, how to build your app). After that, each buildpack can pretty much do whatever the hell it wants if you feel like modifying it and using your own, and have it fetch dependencies statically from a trusted host, or whatever. So yeah, if you don't manage your own repos, you'll generally get whatever your build system fetches for that one. If your language fetches 3rd party libraries from github, that's what it's likely gonna do. If your language's build tools don't, then they shouldn't. That's part of building as you deploy, I guess. There are also plugins that allow to push a directory or package as-is, rather than doing the usual git thing, which could allow us to build before you deploy, getting closer to real releases and probably helping with the rollback mechanisms in the platform. (Disclaimer: while I work for Heroku, I rarely ship code using the client APIs -- what I know of these things might be wrong or inaccurate)
|
#
?
Nov 27, 2013 15:30
|
|
|
|
| # ? May 5, 2024 04:12 |
|
|
Also web dev land is a crazy crazy place. I've said it multiple times before, but I have a decent amount of respect for developers who have the desire to stay there. You're always the junction point of the pressure plates that come from lazy backend people, designers who do not consider the restrictions of the platform, customers who start commenting on poo poo only once it makes it to your plate, project managers that do the same, Marketing people who second guess a lot of decisions made prior by other people. Then there's legal and content writers that dump you 50 pages of text for a box that was designed for a tweet (and consider yourself lucky if it's in a single language), and tight schedules where you're always the last one to be able to work on a project because you depend on everybody else, and do it in the browser to top it off. Then when there's a bug, you're always the first one blamed no matter who made a mistake because your work is the one that is the most visibly customer-facing. Who cares if you had to integrate a responsive design that should work on all devices, but that the designer didn't make correctly because he's a man or a woman who comes for the print world with everything fixed? Who cares if the backend people changed the data format they send you without noticing anyone? Oh and by the way, we'll need you to bolt on accessibility stuff so we don't get in trouble with legal but didn't think of it before! Whelp, fix it, web dev! I left that stuff a few years ago and would not go back there. Again, I have a lot of respect for people who can deal with it. That being said, I still can't really understand how NPM guys need $200k to fix their scaling issues on whatever it is they built. It has to be a house of card of some sort to need that much money to fix it, as I would have expected that caching/replicating data and throwing a bit of hardware at it would have been enough for a long while, especially seeing what other languages/platforms manage to do with fewer resources. I'm fearing the day the stuff they store no longer fits on a single server+replica and they need to shard their service. They're gonna ask for $500k or something that day. MononcQc fucked around with this message at 15:43 on Nov 27, 2013 |
|
#
?
Nov 27, 2013 15:40
|
|
|
http://en.wikipedia.org/wiki/Embedded_Java
|
|
#
?
Nov 27, 2013 16:29
|
|
|
Pollyanna posted:I know enough to know what I don't like I don't know how that could possibly be true.
|
|
#
?
Nov 27, 2013 16:46
|
|
|
MononcQc posted:Also web dev land is a crazy crazy place. I've said it multiple times before, but I have a decent amount of respect for developers who have the desire to stay there. You're always the junction point of the pressure plates that come from lazy backend people, designers who do not consider the restrictions of the platform, customers who start commenting on poo poo only once it makes it to your plate, project managers that do the same, Marketing people who second guess a lot of decisions made prior by other people. all of these things have always been true for GUI devs, even before webs became a thing. there's a couple big differences now: * stakes are generally much higher * the idea of UI standards and uniformity has gone into the trash can * far lower barriers to writing code * no installed base lets you play fast and loose with releases
|
|
#
?
Nov 27, 2013 17:16
|
|
|
Strong Sauce posted: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. I don't really see how this is a distinction worth drawing but ok
|
|
#
?
Nov 27, 2013 17:23
|
|
|
Suspicious Dish posted:How is it different anywhere else? MononcQc posted:Then when there's a bug, you're always the first one blamed no matter who made a mistake because your work is the one that is the most visibly customer-facing. Who cares if you had to integrate a responsive design that should work on all devices, but that the designer didn't make correctly because he's a man or a woman who comes for the print world with everything fixed? Who cares if the backend people changed the data format they send you without noticing anyone? And don't get me started about working with industrial designers. I've only recently found the magic phrasing that makes it apparent that adding 'wireless' to a device implies software error cases that don't exist with a wire. Strong Sauce posted:Sorry JawnV6 you are just a bad web programmer. If web "developers" want the prestige from that airquote they should be a better member of the larger community. I really think we're all one big happy family looking at a common set of problems. Just think the Web branch should be building and using a better caliber of tools.
|
|
#
?
Nov 27, 2013 17:24
|
|
|
I didn't *ignore* the already existing solutions, I just didn't *care* about them! 
|
|
#
?
Nov 27, 2013 17:24
|
|
|
Pollyanna posted: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? Ok, point of order, I'm the same guy with (largely) the same complaint, just in a thread instead of a derail as the last time you brought this up. I don't think other embedded folks spend a fraction of the time I do fretting about this.
|
|
#
?
Nov 27, 2013 17:26
|
|
|
JawnV6 posted:My code comes from a short list of approved vendors, most of whom have a contract and an engineer I can get ahold of. Web devs describe a world where they can't even tell how long the vendor list is without balking at the serious effort that somehow implies. It's apples and oranges. So it's not different at all, then. You can do the same thing on the web side of things. Third-party libraries exist, and people trust them, whether they're on the web, or on the Python Package Index, or on distro packages. If you don't trust them, you don't have to use them. If you trust them, why not use them? Some people find that they can trust third-party code and use it as it helps them in their development. They may use one of npm, bower, pip, yum, apt-get to install this code.
|
|
#
?
Nov 27, 2013 17:42
|
|
|
Suspicious Dish posted:So it's not different at all, then. You can do the same thing on the web side of things. Right, they have the option to do things in a sensible way. They just argue til they're blue in the face that automating the alternative ridiculous extreme is a necessity. My last project had one (1) external dependency. Two if you count the chip vendor and their toolchain. Both vendors had engineers on call. I'm sure you can boil this situation down to "external dependency" and disingenuously pretend it's identical to a solution with 15 npm modules automatically pulled nightly from unknown sites, but I don't get the point. My metric for "trust" in a third party is clearly different. I wouldn't blindly apt-get something either, if you're thinking that's a gold standard for embedded work?
|
|
#
?
Nov 27, 2013 18:06
|
|
|
I'm trying to get it to you that this problem isn't exclusive to webdev — it applies to a lot of development. When I write Linux apps, I'm not going to write an implementation of the X11 wire protocol myself, nor do I want to write a widget toolkit, so I'm going to use an existing one. In fact, if I want to use direct rendering with OpenGL, I have to use libX11, since that's how the API is specified. So, I'm already trusting the libX11 people with their libraries, and I'm trusting the GTK+ people with their toolkit. I'm also trusting all the libraries that pull in (glib, iconv, gnu gettext, the whole text stack like fontconfig/freetype/pango/harfbuzz) I don't think this requires a lot of effort, on my part. Maybe you think that's trusting third-party libraries too much. But it's not a webdev-only issue by far.
|
|
#
?
Nov 27, 2013 18:22
|
|
|
the difference is in volume and in when the dependencies are pulled in and in who or what pulls them in
|
|
#
?
Nov 27, 2013 18:36
|
|
|
I think a lot of this is explainable with the fact that non-dev biz types are a lot more involved with bikeshedding and generally being irritants in web dev than other things, since there isn't quite enough up there to make their eyes glaze over and gently caress off. They can look, squint, point and say "...make that doohickey more like the kajigger and the other thingy." There's also the case that making work for yourself (reinventing the wheel!) is oftentimes a good thing to do when your biz types want to see you look busy. It's also new so there's going to be a ton of false starts and doing poo poo for no loving reason besides to do it your way instead of leaning on existing standards. Patterns/practices have gone back and forth a lot over just the last decade. We seem to bounce between thick and thin clients yadda yadda yadda all the loving time. I find myself wondering if we'll see some practices develop to make the best and most responsive possible JS-free pages because 
|
|
#
?
Nov 27, 2013 18:44
|
|
|
JawnV6 posted:If web "developers" want the prestige from that airquote they should be a better member of the larger community. I really think we're all one big happy family looking at a common set of problems. Just think the Web branch should be building and using a better caliber of tools. I am not saying bower is great, as I haven't used it anyways and I think there are better alternatives than bower's way which you probably wouldn't like either. But are there solutions to just the two problems I thought about off the top of my head? Strong Sauce fucked around with this message at 20:03 on Nov 27, 2013 |
|
#
?
Nov 27, 2013 19:34
|
|
|
Traditional package managers aren't interesting. They're not magic. They're tarballs with scripts that run as root at undefined points in time. DEB/APT has a system that allows a package to hang install/upgrade to ask the user random questions — during this point, the system is running in an undefined state, since you have an old system and half a new system. If you reboot in this, it's very likely you're hosed. RPM/YUM has the same issues of non-atomic upgrades. But they still have two interesting ideas behind them: 1) automated dependency management, 2) a centralized repository of components to pull from. I think that those ideas are what's catching on in the community. You have a declaration that says "I need these libraries", and then you run a tool that depsolves for you. I think domain-specific package managers make sense at some level, since the nitty gritty of "make this library available to the host platform" is going to be different for languages. Ideally, what would happen is we would have one depsolving system, and (this might not be 100% possible) one repository format to store the tarballs in. This way, bootstrapping a new package manager for your language simply means writing a way to make tarballs, and a way to install tarballs. I think a lot of package management systems are going through some of the same growing pains (the way the npm database works is really dumb, I will agree), but I don't think that means package management is useless for everybody.
|
|
#
?
Nov 27, 2013 19:54
|
|
|
Suspicious Dish posted:I don't think that means package management is useless for everybody. I don't think anyone was talking that position but I'm glad we've found something we can agree on.
|
|
#
?
Nov 27, 2013 20:07
|
|
|
I would just like to chime in with the fact that although webdev certainly does suffer from a high-amount of useless hipster poo poo, Node.js is currently the king of poo poo and will probably retain that title for the forseeable future. Well, then again I didn't think Ruby would be so easily unthroned, but they sure did manage, so who knows. But what, specifically, is useless hipster poo poo you ask? It's basically a disdain for everything that came before you, because you are king-poo poo of gently caress-mountain and you just know better. It's dismissing technologies that are (admittedly) complicated or hard to use without actually understanding anything about how they work or why ended up that way. Stuff reinventing inheritance for every other project, and doing so very poorly (classes? that's for, like, Java - ewwwwww). Node is the loving king because the whole stupid thing is built on the premise of re-inventing something that has already been done in pretty much every other language and doing it poorly and I still cannot for the life of me fathom why anyone would use it for anything, ever. I rant about this a lot, but you can have the exact same evented model with its crazy magic scaling sprinkles done perfectly in Erlang, or done merely much better in Python with gevent or whatever greenthread library du jour works best. No loving boomerangs or one-function-per-line or new language constructs needed. It's just as fast or faster. It is beyond me. I mean yes, there is the theoretical capability of sharing implementations between client and server for web apps, but turns out this is actually very loving complicated to make useful and very few node apps actually make use of it. I'm personally not convinced it can ever be made practical. So yeah, Node made their own package distribution without mirroring or even self-hosting capabilities even though every other package distribution out there has those things, is this surprising? Not exactly. We're all hot-poo poo rockstars here in node-land ok? We're too busy solving tomorrow's problems to engage in your pedantic little premature optimization that is clearly outside the minimally viable product we need to deploy our social microblogging scarf-pattern mashup.
|
|
#
?
Nov 27, 2013 23:34
|
|
|
sharing code between client and server isn't that difficult at all but it's not a common case. the use case for node is "the web devs need a little internal service written and they want to write it in javascript" I've used it in place of shell scripts in some places because I'm more comfortable with js than I am with python or perl and shell can be a pita. it's honestly not so much node as the bullshit that has spread up around it. you know how a water lily is this beautiful flower that grows out of a gross swamp? node is like the reverse of that where the beautiful flower grows somewhere regular and then turns it into a gross swamp.
|
|
#
?
Nov 28, 2013 00:39
|
|
|
Mr. Wynand posted:I would just like to chime in with the fact that although webdev certainly does suffer from a high-amount of useless hipster poo poo, Node.js is currently the king of poo poo and will probably retain that title for the forseeable future. Well, then again I didn't think Ruby would be so easily unthroned, but they sure did manage, so who knows. Wahhhh Is someone from the python community really bitching about another programming language/ecosystem's package management system? Edit: You can self-host node modules, however the easiest solution is time consuming. Edit 2: Actually you don't even need to do that. There are solutions where they only copy over node modules that you want from npm's repo. People just haven't bothered to do so. Strong Sauce fucked around with this message at 01:03 on Nov 28, 2013 |
|
#
?
Nov 28, 2013 00:52
|
|
|
rotor posted:sharing code between client and server isn't that difficult at all but it's not a common case. Well sure but like you said, it's not the common case. I think a lot of people had lofty dreams of writing, say, data validation and construction logic on the server and using the same one on the client to reflect equivalent state changes in the UI before they go to the server - that would have (maybe) been a useful thing for nodejs to do that would (maybe) make putting up with it worth your time. Simpy pulling down extremely isolated services is of course much easier to do, but putting a lot of useful functionality (relative to the functionality of the whole app) in such well isolated modules is not. Either way, my point was, this isn't really a reason to use Node.js, and the way it does evented async servers sure as poo poo ain't either. As for still being useful on its own for personal scripts because you feel more comfortable with JS, you know, that's kind of like how people describe horrible games as "well, it's actually still quite fun with friends". You know what else can be fun with friends? Sitting in a room and talking. The game doesn't matter at all and brings nothing to the table. Same with personal one-off scripts, it literally doesn't matter how you write them, even if it's lolcode of course it's going to be just fine because you're the only one that will ever look at it, it never needs to change and it only has to run a handful of times. The "hard" part of programming is dealing with what happens when neither of things is the case. JS is fine, I don't hate it at all. Making a stand-alone interpreter for it is also a fine idea, it makes it useful in many places outside the browser. But building huge high-performance servers out of it and having it be the "it" language for server programming... I just don't understand why. And that's pretty much all Node adds, the server bits that make no sense. v8 + CommonJS would be a lot less perplexing.
|
|
#
?
Nov 28, 2013 01:28
|
|
|
Strong Sauce posted:Is someone from the python community really bitching about another programming language/ecosystem's package management system? I would hardly call myself "someone from the python community" but one of things I definitely like about Python is that, yes, there are lot of hosed up things about it, but people are actually fixing them, there is a process for fixing them and it actually moves forward. When it's slow it's because people actually take the time to deal with issues like compatibility and backport support. The whole distutils/setuptools/distribute/whatever the gently caress we're doing now is definitely one of the worst though. Apparently eggs are going away too, the new poo poo is wheels!  Anyway npm certainly bothers me a whole lot less then the existence of node.js to begin with.
|
|
#
?
Nov 28, 2013 01:36
|
|
|
Mr. Wynand posted:Well sure but like you said, it's not the common case. I think a lot of people had lofty dreams of writing, say, data validation and construction logic on the server and using the same one on the client to reflect equivalent state changes in the UI before they go to the server - that would have (maybe) been a useful thing for nodejs to do that would (maybe) make putting up with it worth your time. I'd prefer to go the other direction and write the entire site in a single good language which is sometimes compiled to JS, but to the best of my knowledge the the only non-toy implementations of that idea are GWT (Java), Wt (C++), and some Haskell thing I don't remember the name of, none of which I consider particularly good options.
|
|
#
?
Nov 28, 2013 01:46
|
|
|
rotor posted:all of these things have always been true for GUI devs, even before webs became a thing. there's a couple big differences now: Yeah, I'm not claiming web devs are alone in their poo poo world. I am somewhat expecting web browser to have a way shittier track record at being good to develop on than anything else. IE6 was still a thing in some place one or two years ago. Playing fast and loose with releases is probably what makes it even worse, because you can say "gently caress it we'll perfect it later" and then you don't. The web also has a fun part to it regarding security where the install base means that you must assume all users want to gently caress your poo poo up, and if a single one of them manages to do it, your entire app can be compromised for everyone. The front-end people are usually the main source of issues such as CSRF and XSS, and this is where budgets can get cut very early or devs just don't know what the hell. JawnV6 posted:I don't think this is all that unique to the Web. When we're putting together a complex electromechanical solution and the motor ground to a halt, everyone's first question was "well, did the software just drive it too far?". Not 'was the limit switch busted?', 'did the ME place the sensor wrong?', 'did the EE wire it up correctly?'. I don't have the benefit of a native test environment conveniently packaged with my development tools. So "software bugs" and "integration bugs" all look the same on a first pass. Again, I don't think it's unique to the web again. I have never worked with embedded stacks and couldn't compare them and am ready to accept there's probably another shitload of crazy going on on there. Web devs tend to be people who graduated from the school of HTML and decided to start developing apps with JS. Node.js people then often managed to make the jump from browser front-end to server-side directly, and they don't necessarily see how different of a world it is the way you would with other languages. This isn't to say it's impossible to do it, or that people didn't migrate from <backend language> to node.js, but then again, I don't expect them to be the worst of the bunch. I think a lot of the problems are from people who don't know better, but it's definitely possible to learn if one makes the effort. Front-end security is definitely poo poo, though.
|
|
#
?
Nov 28, 2013 01:48
|
|
|
I certainly think that HTML and the web, as originally designed, aren't really suited for what we're building today. HTML pages were supposed to be static markup, and then we realized we could generate them on the fly on the server. And then Netscape realized that we can let the client poke into the internal data structures of the browser and build user interfaces without the "HTML markup" part. Of course I recognize the irony that it takes CPU power to do dynamic things, and now we're prerendering everything and static is the new dynamic... Problems like CSRF and XSS clearly simply would not exist in a better-designed system. But, of course, hindsight is 20/20, and no widely-adopted system which people can innovate on would ever be 100% perfect. I think the web standards are moving in a good direction, where 1) HTML is simply one serialization format for DOM nodes, 2) we're allowing the user to build more with DOM nodes, with things like Web Components stuff, which allow us to treat a complex DOM structure for e.g. "a switch" as a black box. I've recently built a web app that uses all of this new stuff (raw DOM, not jQuery/Angular), and it feels like fresh air.
|
|
#
?
Nov 28, 2013 02:04
|
|
|
Plorkyeran posted:This isn't some crazy hope that everyone gave up on; Derby and Meteor are both actively working on making it work. I'd never choose either of them for a real project, but I expect something along the lines of them to win out eventually. quote:I'd prefer to go the other direction and write the entire site in a single good language which is sometimes compiled to JS, but to the best of my knowledge the the only non-toy implementations of that idea are GWT (Java), Wt (C++), and some Haskell thing I don't remember the name of, none of which I consider particularly good options. There's also another approach where you just write your whole loving app client side except for the data store which is just super super smart and can safely run as a public API. Some newer-ish realtime "framework" does this, I forget the name, but it's not actually a framework at all - it's a hosted service you call into. I've no faith whatsoever in the implementation (and service model) I saw, but I think the idea might actually have legs. See, again with the re-inventing and disdain as this is basically the RDBMS-driven app development model of old, which, well it certainly has some serious flaws, but may well worth be revisiting (instead of throwing it out and doing the same thing in a poo poo way using "document stores").
|
|
#
?
Nov 28, 2013 02:14
|
|
|
Suspicious Dish posted:I've recently built a web app that uses all of this new stuff (raw DOM, not jQuery/Angular), and it feels like fresh air. Web dev today is unrecognizable from how it used to be. CSS layout options written by normal people? Browsers that update? Standards that are adhered to? If you had told me in 1999 that in a mere 14 years it would all be fixed, well, actually that would have been quite depressing... But hey whatever, we made it, things are happening etc.
|
|
#
?
Nov 28, 2013 02:18
|
|
|
"fixed" For plenty of websites it's a new era of "optimized for" where webkit is often the winner and people just don't give a crap about other browsers.
|
|
#
?
Nov 28, 2013 02:27
|
|
|
Mr. Wynand posted:Browsers that update? Man, I forgot about how big of a thing this actually is. You almost never see a Chrome 17 or a Firefox 4 anymore, because they auto-update on release. They solved the IE6 problem by simply making it not a problem.
|
|
#
?
Nov 28, 2013 02:28
|
|
|
MononcQc posted:For plenty of websites it's a new era of "optimized for" where webkit is often the winner and people just don't give a crap about other browsers. That's why the WebKit and Chrome teams are not using vendor prefix for unstable features anymore: it turns out giving people a cool feature and telling them "don't use this or you might break later" isn't an effective mitigation solution. Feature flags are a much better tool for this.
|
|
#
?
Nov 28, 2013 02:30
|
|
|
I'm just fed up that 80% of the time I open a google doc in firefox, it ends up crashing the browser. Google are probably the worst there. They made their own browser and then the experience has been gradually getting shittier everywhere else. It probably started back in the days of Buzz and Wave.
|
|
#
?
Nov 28, 2013 02:38
|
|
|
I'm also angry at every stupid web app out there rebinding keyboard shortcuts to do things I am not aware of.
|
|
#
?
Nov 28, 2013 02:40
|
|
|
MononcQc posted:"fixed" I'm surprised how many Japanese sites rely on 100% desktop Flash and thus don't work on the legions of phones and tablets in popular use. Also, there must be at least 20 iOS apps for tourists that target iOS 3 and 4 and no longer work with iOS 6 and 7 at all, half of them are fee liable too which makes it even more odd.
|
|
#
?
Nov 28, 2013 03:36
|
|
|
Suspicious Dish posted:That's why the WebKit and Chrome teams are not using vendor prefix for unstable features anymore: it turns out giving people a cool feature and telling them "don't use this or you might break later" isn't an effective mitigation solution. Feature flags are a much better tool for this. I know an Opera employee, and they were rightly annoyed for a number of years that while they supported - or even pioneered - a lot of the new CSS features, web developers ended up only using them with webkit prefixes. For added fun, it didn't seem to matter if the webkit browsers had supported it unprefixed for years.
|
|
#
?
Nov 28, 2013 13:52
|
|
|
CSS is such lovely voodoo that it is the king of cargo-cult, copy/paste coding. It is kind of understandable that once something enters the cannon it does not leave.
|
|
#
?
Nov 28, 2013 14:22
|
|
|
Computer viking posted:I know an Opera employee, and they were rightly annoyed for a number of years that while they supported - or even pioneered - a lot of the new CSS features, web developers ended up only using them with webkit prefixes. For added fun, it didn't seem to matter if the webkit browsers had supported it unprefixed for years. Webkit prefixes weren't the only place where that was a problem.
|
|
#
?
Nov 28, 2013 16:34
|
|
|
Also stuff like this
|
|
#
?
Nov 28, 2013 18:19
|
|
|
I think that might be my new favorite Mozilla bug... it used to be #330884. But seriously, after a bunch of stagnation and the W3 being absolutely boneheaded about the web, it's nice to see rapid in the web space. Mistakes are going to be made, and people are going to be angry. edit: i'm an idiot and thought i was in the coding horrors thread. there used to be stuff here that was a repeat of stuff also two posts up Suspicious Dish fucked around with this message at 19:02 on Nov 28, 2013 |
|
#
?
Nov 28, 2013 18:50
|
|
|
Mr. Wynand posted:Well sure but like you said, it's not the common case. I also find it oddly confusing because theres no clear indicator under what context the code you're writing is executing. Used to be that you'd be all "well, its python so im on the server" but now it takes a second and I've gotten it wrong more than once. Not a huge deal but it was unexpected. quote:As for still being useful on its own for personal scripts because you feel more comfortable with JS, you know, that's kind of like how people describe horrible games as "well, it's actually still quite fun with friends". some (most?) shell scripts dont have to be performant and if you're just building some scripts to do some file ops and move the bits around on the plate and you want to write it in javascript, who cares? scripts like this need to be readable maintainable more than anything else imo quote:But building huge high-performance servers out of it and having it be the "it" language for server programming... I just don't understand why. And that's pretty much all Node adds, the server bits that make no sense. v8 + CommonJS would be a lot less perplexing. its nice to be able to easily stand up simple web services without a bunch of fuss. this ability exists and is widely used in python and ruby as well, so i dont see why you'd have an issue with node? my issue is more with the ecosystem around it being written by idiot children, bower and this thing with npm being only the latest examples
|
|
#
?
Nov 28, 2013 19:54
|
|
|
|
| # ? May 5, 2024 04:12 |
|
|
Plorkyeran posted:I'd prefer to go the other direction and write the entire site in a single good language which is sometimes compiled to JS, but to the best of my knowledge the the only non-toy implementations of that idea are GWT (Java), Wt (C++), and some Haskell thing I don't remember the name of, none of which I consider particularly good options. when adobe donated the tamarin stuff I had this tiny spark of hope that someone would get a wild hair and allow actionscript compiled to bytecode to run in the firefox js interpreter, that would have been so great. rotor fucked around with this message at 20:01 on Nov 28, 2013 |
|
#
?
Nov 28, 2013 19:58
|
|