|
Chenghiz posted:Please don’t post links to w3schools. Is MDN better? The same information always seems to be on both.
|
# ¿ Oct 21, 2017 06:56 |
|
|
# ¿ May 19, 2024 07:13 |
|
I don't wanna sound like one of those people who thinks Microsoft Google and Mozilla have all run their course but I'm that guy. Who's running the other one, the w3 schools?
|
# ¿ Oct 21, 2017 21:34 |
|
I would like to see documentation by the World Wide Web Consortium, which is where language features and standards come from. And I want browser makers like those companies you mentioned to implement those standards properly. Mozilla fell into the same "social posturing" politically fuelled pit Google fell into and I don't think Microsoft is doing much better. I care about technology not what organisations the CEO is currently donating to. Why does that go with the technology I am using? If these companies are the ones designing browser features we're not in a good place.
|
# ¿ Oct 22, 2017 01:42 |
|
Thermopyle posted:Besides Google, etc basically are the W3C. there's no escaping them is there.
|
# ¿ Oct 22, 2017 02:45 |
|
Posting in appreciation of js-joda. It's got a few, what feels like, weird ways of going about things if you're trying to calculate a specific date or time. But it is infinitely clearer in practice than a similar solution provided by moment. Moment does internationalisation though.
|
# ¿ Dec 4, 2017 17:33 |
|
lordfrikk posted:My proof of concept is a very basic SPA that just loads a JSON file telling the app of the different versions of our docs in different directories. Each of those has another JSON file that has the table of contents with filenames. I use that to build the sidebar menu and the files are just loaded directly via JavaScript and injected into a page. You're doing everything the modern way. Which is to serve a static page that loads what it needs via JSON and then dynamically builds the DOM live on the client side. It sounds like you're on the right track if you're a hipster.
|
# ¿ Dec 5, 2017 15:35 |
|
I'm at a weird time in my life where I cannot decide between having lots of spinners for all the different things that load everywhere. Or whether there should be one single spinner somewhere always at the same place on the page. Then just have a value that counts up and down the number of different things that are loading to decide whether the spinner should be spinning.
|
# ¿ Dec 5, 2017 15:39 |
|
Doom Mathematic posted:I think you may have just reinvented the loading bar? I like the idea of websites using a permanent loading bar across the top of the page, that empties when there are things to load. I also think web browsers should do a similar thing or replace the need for on-page spinners/loading bars altogether. Embrace the modern skinny jeans web, Chrome.
|
# ¿ Dec 5, 2017 18:19 |
|
As we move further into the realm of static pages that download dynamic content after they load, the loading indicator in the browser has become somewhat irrelevant. Even just loading js/css assets is gone now, as those are often loaded dynamically too. We're one step away from images being loaded the same way video is... or maybe a script downloads it, displays after it loads.
|
# ¿ Dec 5, 2017 19:39 |
|
I've run into what I feel is a bit of an oversight on the part of Vue.js which is their handling of form input bindings. https://vuejs.org/v2/guide/forms.html The wisdom is to have a local state containing all of the form input values, and that's great. However it seems to me every project would have a form design unique to the project. Therefore I would expect to see a 'form' component directory with a component for each type of form field. Unfortunately this doesn't work if you want input bindings. At that point you are going to have to deconstruct what Vue.js calls syntactic sugar, `v-model` is useless, and it reveals some of what happens under the hood so that you can try to emulate it. Effectively nullifying the benefits of using Vue.js' form input bindings entirely. https://vuejs.org/v2/guide/components.html#Form-Input-Components-using-Custom-Events This it seems to me would happen fairly early on in every project using Vue.js. Now I'm starting to feel a bit happier with my original solution, which I wrote before learing about the built in form input bindings functionality. Which involves simply reading the form using FormData.
|
# ¿ Dec 14, 2017 16:41 |
|
Hey you guys are into this stuff there's a new bundler to use instead of Webpack. https://medium.freecodecamp.org/all-you-need-to-know-about-parcel-dbe151b70082 Called Parcel. I will probably stick with Browserify because I still think having a static `index.html` rendered is silly. But I'd take a very close look, if it were between Parcel and Webpack. Hi I'm your RSS feed popping in.
|
# ¿ Dec 22, 2017 20:19 |
|
I had something like that once, iframes all over the place, all of it was very intentional though. Several of them from several different domains so the only way to perform a lot of the communication between them was via postMessage. Was real hard. Glad I'm not doing that stuff anymore. Can you refactor what you're doing? Sometimes I find bashing out a prototype in a couple of hours that works better than the actual product is a good demo for management.
|
# ¿ Dec 26, 2017 17:01 |
|
My crystal ball piped up and is telling me your application's future. At some point you will have the mega get request, as well as several areas of the app which need only part of it. Leading to duplication on the server, duplication on the client, or careful api surgery. It's ok to just make several api calls if you need them.
|
# ¿ Jan 1, 2018 02:20 |
|
Wait a minute this isn't a crystal ball at all, it's my dirty laundry.
|
# ¿ Jan 1, 2018 11:05 |
|
I used Vue to build my last project and I'm very happy with the result. Vue /w vuex and vue-router. After a year of working with React and Redux, Vue was such a breeze to use, it was delightful.
|
# ¿ Jan 16, 2018 10:39 |
|
You could build an enum that describes the components you want to render. Then render them based on a prop you pass, if I guessed what the question was I want a pizza.
|
# ¿ Jan 21, 2018 05:12 |
|
Knifegrab posted:What is the most modern and best solution to have two divs that are side by side, switch to being above/below one another depending on size of browser (responsive) Table layouts with javascript that detects inner bounds of the window and restructures it.
|
# ¿ Jan 27, 2018 16:54 |
|
One reason I can think of is that Angular 1.x is famously hard to use and is rife with side effects everywhere all the time. Technical debt mounts to a point where you just aren't going to get any new features on any kind of a reasonable time budget. Vue is incredibly easy to use on the other hand. You already have a working proof of concept, you can build it exactly the way it is from scratch in a matter of weeks or less. I've seen companies struggle to escape technical debt sometimes sacrificing months or even a full year. Because their software is such a hodgepodge of technologies, cobbled together underneath the weight of an ever changing spec. It's spaghetti everywhere. That's why a company would want to switch. Then you have a fresh start with the product more or less looking the same but it's faster, noticeably less buggy, and your developers are able to work on it.
|
# ¿ Jan 28, 2018 01:51 |
|
Oh, I'm more experienced with vue so naturally I'd lean toward implementing that. The monolith is a problem, but I wouldn't suggest changing it in the re-write. The goal of the re-write should be to implement all documented features as they are. Breaking the product up and further refactoring happens after the code base is minimal and manageable again. When it's manageable again, steps should also be taken to ensure the same architectural design problems don't resurface. In my experience really good software usually goes through a couple of revisions. With the framework I'm familiar with, it can go really fast. The tools we have today are incredible in a lot of ways.
|
# ¿ Jan 28, 2018 02:42 |
|
Browserify gives you node style CommonJS modules (require, module.exports). To get ES6 style modules to work (import, export) you need to use babel tooo http://egorsmirnov.me/2015/05/25/browserify-babelify-and-es6.html
|
# ¿ Feb 2, 2018 23:15 |
|
Skandranon posted:You could also look at using Rollup.js, Browserify is really showing it's age. Rollup can also handle commonjs by adding a plugin which is really nice. It unfortunately doesn't convert es2015+ into es5 though, I've found Typescript's compiler is fantastic at that so I'd prefer Typescript + Rollup over Babel + Browserify. Unfortunately I've been driven somewhat away from Typescript because of the effort it takes to manage dependencies. I'd really like an alternative to Babel.
|
# ¿ Feb 4, 2018 02:37 |
|
I really like commonjs, because I don't have to compile my tests. I usually end up using Browserify because it has that in mind.
|
# ¿ Feb 4, 2018 02:44 |
|
I got really into Typescript and how specific it forced me to be, it helped develop quite a few best practices and is a great language to work with. I just eventually found it easier to use basic es2015+. Types stopped being as useful to me maybe I should try again. Dunno if it's good/bad practice to expose my github profile here but this is what got me annoyed enough with Typescript that I stopped using it. https://github.com/rollup/rollup/issues/1476 Side note to this discussion has anyone tried out booblay as an alternative to Babel? https://buble.surge.sh/guide/
|
# ¿ Feb 4, 2018 04:36 |
|
I like rollup because it does what I need and nothing else.
|
# ¿ Feb 6, 2018 04:29 |
|
Nolgthorn posted:Side note to this discussion has anyone tried out booblay as an alternative to Babel? Trip report: My new favourite thing is this plus rollup, there's a rollup plugin that makes it so easy to use... my entire config is. JavaScript code:
JavaScript code:
JavaScript code:
Nolgthorn fucked around with this message at 12:44 on Feb 6, 2018 |
# ¿ Feb 6, 2018 12:41 |
|
FormatAmerica posted:I love .NET development but new platform attempts over the past couple decades have been a hot fuckin mess. Ruby on Rails died in the span of 5 years
|
# ¿ Feb 8, 2018 04:15 |
|
I've done front end and back end a lot, front end is easy if you're doing server rendering. Front end is massively more difficult than back end if you're doing client rendering. And more difficult than either of them is dev ops.
|
# ¿ Feb 16, 2018 00:41 |
|
I often hear controversy when I say client side is harder. Recently I did a sort of bare bones CMS, just markdown. But even with that you want to upload files. So what do you do, you don't want to put that on a different page really. So you end up negotiating popups, ajax file uploads, json injected into templates, delete, edit, if you have edit you may as well preview/edit text file contents too. There you go that's a hundred lines of carefully engineered javascript. What had to be done on the server? Some rest routes. Use the database to store and update records, return json. The server stuff is simple comparatively.
|
# ¿ Feb 17, 2018 07:56 |
|
You also need the CSS to hold it together, for it to work across devices. If you're doing modern front end then you need to know a myriad of tools including compilers, bundlers, frameworks. I just can't think of any project I've worked on where the server was more complicated than the client. I differentiate between dev ops and server side work though, so that may be where a lot of disagreement comes from. Dev ops is hard.
|
# ¿ Feb 18, 2018 04:16 |
|
I bet there's more failed companies that used Angular than Vue though so you could try and sell them on that.
|
# ¿ Feb 19, 2018 03:12 |
|
Code should never be adapted just so that you can run tests on it, you shouldn't have an `isTest` boolean anywhere or things like that. However if you're not able to test code effectively then it's probably too tightly coupled with other code and should be adapted for that reason. I see no problem with passing a function as a prop for example.
|
# ¿ Feb 21, 2018 08:18 |
|
Thermopyle posted:While writing code often is stupid, in this instance (and it is of course common) using libraries is what is stupid! Part of the issue is that too many libraries try to do too many things, and themselves use too many libraries as well. Which seems to be acceptable which is also an issue. The current standard stack seems to be Webpack, Babel, React/Redux. Which is nuts.
|
# ¿ Feb 23, 2018 12:55 |
|
I'm trying to get serious about switching away from `npmjs` as it's something I've been wanting to do for a while. The recent bug that has been wiping out servers and the dev's response has finally pushed me to devote some time to it. As I understand use of the npm repository is inescapable for general work. But maybe I can get away from their cli, something like yarn although I'd like to also avoid it, yarn has a lot of the same foundational issues with team structure and politics that npm suffers from. Anyone have experience with other ones?
|
# ¿ Feb 23, 2018 14:08 |
|
Jspm looks neat. I've also never heard of Traceur I've been using Bubel for es6->es5 compilation I could try out both of those tools. What gives me pause is the really long page about publishing, it seems not to be focused or maybe it's just really detailed. Could you give me a brief example of how you would publish a module?
|
# ¿ Feb 23, 2018 14:53 |
|
No because I don't want to get into a political argument I only want good tools so that I can make stuff, politics belong nowhere near software. Politics are what npm and yarn are suffering from so I'll look for software developers who are interested in software.
|
# ¿ Feb 23, 2018 19:03 |
|
I hope to find out
|
# ¿ Feb 23, 2018 19:20 |
|
https://developer.mozilla.org/en-US/docs/Web/API/Push_API I'd like to get push notifications working, is the only way to do it with a Google API key? There has got to be another way to do it. Related, I see a load of website push notification startups out there but I can't figure out what they're doing that I can't do with a small amount of code myself. It seems like I just send a POST request to their endpoint instead of the Google API endpoint mentioned. And either way I still need a Google API key. Nolgthorn fucked around with this message at 07:29 on Feb 26, 2018 |
# ¿ Feb 26, 2018 07:22 |
|
I have discovered and am excited about pnpm.
|
# ¿ Feb 27, 2018 18:31 |
|
Sedro posted:might be better now but there's no incentive for me to switch back. Fewer dependencies and libraries. Otherwise, I want there to be more better reasons than that.
|
# ¿ Feb 28, 2018 01:14 |
|
|
# ¿ May 19, 2024 07:13 |
|
IAmKale posted:Does VueJS have a concept of a "service"? I'm trying to figure out how to initialize a singleton class to wrap an API and manage auth credentials and use it across multiple components and pages. If I just use a regular "import...from..." when I want to use the class of course it won't preserve state and I'll have to initialize it every time. You can export the instance you want to work with, javascript will only really import anything one time so you always end up with the first instance you created in whatever module you're importing. In Vuejs I like to just augment the vue instance itself. code:
code:
What does javascript want from me! I've given it everything! My whole life! Nolgthorn fucked around with this message at 14:40 on Mar 14, 2018 |
# ¿ Mar 14, 2018 14:29 |