1. 9

    After 2 years my experience with Vue has been positive. I’m still confident it was a good decision to move my team from React to Vue. Not because Vue is better, but because it is a better fit for us.

    Why though? These comparisons of libraries/frameworks that amount to “differences of technical details” are not worth writing. Did the author have some problem that couldn’t be solved with React and could be solved with Vue? That would be worth hearing about. I’m talking real business-value-added problem solving. Not “the syntax is nicer”. If I was employing this author and read this article, I would feel like the migration from React to Vue had been a waste of company resources.

    1.  

      Well ultimately they are both Javascript frameworks, so what you can do in one you can do in another, the whole idea of a framework is the syntax in which you interact with it to the base language. As such, some things will be easier in framework X and other will be easier in framework Y. In my opinion you have the Angular way to solve JS “framework projects”, then the React way, Vue sits a bit in the middle (if not closer to React).

      1.  

        what you can do in one you can do in another

        If I’m already using a tool that can do what I need it to do, why would I invest in a new tool? And I don’t mean to reduce things to “it’s all JavaScript so you don’t need a library”. React, Angular, Ember, Vue, etc., are compelling to me to the degree that they enable a developer/organization to deliver useful software. But if React and Vue are compelling to the same degree, I’m not sure there’s anything to talk about.

    1. 2

      I never really understood the sabayon distribution, its Gentoo for people that can’t install it, or don’t want to spend the time to. For the people that just want to save time, that’s great, but usually Gentoo users, don’t want anything but the bare essentials there use flags have pulled in on there chosen packages. As an ex Gentoo user (probably around 2006-2008) I remember the forums and irc channels just being packed with sabayon users who had installed it, then running into to problems when emerging something else.

      I can’t applaud the installer enough as I remember it used to be very easy/efficient to use, however as an ex portage user I didn’t personally enjoy entropy. I would have thought it would have been better to just maintain a Gentoo installer and entropy package separately. I remember back in 2006(ish) Gentoo released a live CD installer (which was awful) and then Sabayon came out with one (I think either just before or just after) that worked perfectly.

      Anyway, it’s great to see this project is still around and doing well.

      1. 1

        It seems like a cop-out because the whole point of Gentoo is building the package to fit your system. Sabayon has a number of precompiled packages. Seems to defeat the purpose.

        1. 1

          There are people who would like to use perks that emerge/layman gives them (first class access to application’s source code, build process, etc), or would like to learn Gentoo, but don’t have knowledge or will to install it properly. I’ve used Gentoo in times of Penium4’s and I liked it very much, but the duration of revdep-rebuild was simply horrible, updating Firefox or OpenOffice was something that needed to be scheduled over night. So I understand that some people would like to have a system that’s prepared for them, and use Gentoo’s tools for the customization of software they are interested in customizing.

      1. 2

        I don’t mean to be rude, but python 3 has been around and the preferred python for Web development for some time, the fact that the migration needed to make a blog post is a bit over the top.

        I personally switched all my django projects to pyramid over 5 years ago now, mainly for as the post suggests, the ‘django’ method of development is heavily influenced by lots of third party plugins, which causes dependency hell come upgrade time. And (from my experience) you may only need 10% of the plugins capabilities in your application. And usually what would break these plugins wasn’t python, it was djangos framework code.

        For a company so reliant on a Web front end, I would have seriously considered swapping out third party libraries some time ago, but that’s just me.

        Anyway, the point to my rant is that python 2 - > 3 is in reality (for this use case, Web) a daily non trivial task. Hence why one year at PyCon everyone was talking about it (in angst of the upgrade) and next year no one was, (because, in most cases, even for large projects its only a day, or two, max).

        1. 0

          So this means whatever you write in python today, you will have to re-write it again in 8 years ?

          https://en.wikipedia.org/wiki/History_of_Python#Version_release_dates

          Maybe tools like 2to3 make it easier though…

          1. 8

            Guido has shared this article stating that no more breaking changes are expected in the future :

            a 4.0 will presumably still happen some day, and the premise of this article is expected to hold for that release: it will be held to the same backwards compatibility obligations as a Python 3.X to 3.X+1 update.

            1. 1

              This is a great news!

            2. 4

              Basically none of the Python community wants to experience the 3.0-style backwards compatability issues again (this includes core developers).

              Something that might get lost in the noise, but 3.0 in particular broke a huge amount and there was relatively little concern for having code that could run in 2+3. But after the feedback they had introduced stuff back into 3 (like allowing the no-op u'..') and made it easier to run both-version-compatible code. So 3.0 was especially broken.

              Guido has said that any compatability breakage nowadays would happen piecemeal, and with more care to this issue. Presumably it would have been something like “string literal changes” in one release, “urllib changes” in another release, etc. Instead of forcing all changes all at once.

              1. 4

                So this means whatever you write in python today, you will have to re-write it again in 8 years ?

                That’s a completely unfounded statement.

                1. 5

                  Ended with a question mark, I’d assume a legitimate question. Also the answer to it would be “not necessarily, and if you’re writing it in Python today, this might convince you to write it in Python 3”

                  1. 1

                    I am still new to python, so this is more of a clueless question than a statement like olivier wrote.

                    So as I understand it, it might have been the case 8 years ago, but as edudobay points out, what comes will be much better.

                    1. 4

                      When I migrated 8 projects from python 2.7 to 3.4 (few years ago now) it only took me about a day, it really wasn’t as painful as it was made out to be. Before any big changes are planned the documentation usually suggests ways to structure current code that won’t break future releases.

                      1. 1

                        Then I understand what lead me to thinking this: I have seen a quite large code base (glue between daemons and an API) wait till the latest minute (now I guess) before to switch from 2.5 to python 3.

                    2. 1

                      I understand what lead me to think this (as answered to crookey).

                    3. 2

                      I’d be suprised if they were to actually include a switch, which would any python2 interpreter just immediately quit whenever it’s started after 1/1/2020. But guessing that they won’t do that, I’d suppose that most people will be allowed to keep on using the interpreter, even if it isn’t maintained anymore.

                      1. 2

                        That’s my reading too.

                        In any case, there’s nothing stopping someone from forking the code, as Guido points out.

                    1. 2

                      The whole Python 2/3 debacle is why I gravitated to Ruby, which has its own set of warts.

                      So what are the lessons learned?

                      1. 2

                        Incidently, the reason I moved from Ruby was the 1.8 era where I think there was also a rails 2/3 upgrade at the same time, wasn’t fun. Lesson learned is the one of the biggest obstacles of our job is unsupported software, be it a library or a language, as long as it works and solves your problem, it’s not the end of the world.

                        And just because software is marked as unsupported, it doesn’t mean all the knowledge for X software projects also disappears over night.

                        Or we can just write everything in assembly.

                        1. 1

                          No matter what tools you choose to use there are going to be things you don’t like about them. And that’s okay, you just have to pick a set of warts you can live with.

                        1. 4

                          Interesting article, however to me this everything that is wrong with open source software, in the good old days (and still around 50% of the time now) open source software (and contributions) come around when people need to solve X problem, and opensourcng your work is a great way to help others, then usually if the code is found to be useful (or in demand) then contributors join in, and before you know it you have some code you wrote to help you out on a project, working for thousands of users in ways you never expected.

                          “Necessity is the mother of invention” is a very fitting statement for open source (in my opinion). Creating software for a problem you don’t have (or that doesn’t exist) seems very counter productive, this whole attitude of wanting to create an open source project for “Internet points” absolutely perplexes me. If you want to help the open source community there are thousands of projects that would love the help.

                          Marketing open source software? I mean put it on Github with a decent readme and a search engine will take your potential users there, however if you created some software for a problem that doesn’t exist, don’t expect too much traffic.

                          Testing is a good point, but usually in smaller scale open source projects (or single maintainers) you write the code to solve a problem you have, maybe there are a few tests, but to me if I found a piece of software that did what I wanted, and had no tests, I would just write my own tests, we have so many users of open source software now that just seem to moan or log issues when it doesn’t work for them, when in reality they should be sending pull requests (or diffs if you took your dinosaur to work) saying “hey, cool project, I used it but noticed you had no tests, I creating the following, hope this helps”. However, I can count on my hand the amount of times I have seen pulls/diffs like this.

                          I have gone off on a bit of a tangent, but hey.

                          1. 2

                            What part of the OP, exactly, implied that open source today is all about “Internet points”? Don’t you think that’s just a tad bit uncharitable of you?

                            I also think your thoughts on testing for small single maintainer projects are way off the mark. I wouldn’t be able to maintain the projects that I do if I didn’t have tests. There would just be no feasible way. I would probably need an army of clones of myself working in concert to do it.

                            I think basically everything else you said is off the mark too, speaking as someone that has been involved in open source since 2003 or so. I remember the “good old” days before Github, accessible CI, emphasis on docs and testing, etc., and frankly, we are in a much better state nowadays. I mean, those days sucked. Hard.

                            1. 1

                              Add testing, documentation, build, distribution, marketing…

                              Almost like they are building a product but without any plan for sustainability.

                              1. 1

                                Could you unpack that? All of those things seem beneficial with respect to sustainability.

                                1. 1

                                  Spend hundreds of hours building something polished, lots of users show up asking for support and then burnout happens. Who maintains the maintainers?

                                  1. 1

                                    If your goal is to release something that others use and to incorporate feedback from others, then testing, documentation, distribution and all that stuff improves the sustainability of the project.

                                    If you’re just looking to throw something over the wall and don’t care whether anyone uses it, then don’t polish it in the first place?

                                    Like, isn’t this whole thing trivially solved by just asking the simple question, “What problem are you trying to solve?” Instead, people seem intent on bantering about “Internet points.”

                                    1. 1

                                      If your goal is to release something that others use and to incorporate feedback from others, then testing, documentation, distribution and all that stuff improves the sustainability of the project.

                                      This is contrary to every small OSS project I’ve ever seen. I’m speaking mostly of single person projects. Perhaps you are thinking of large, multi-person projects, e.g. Rails, Rust, etc but those usually have full-time people paid to work on the project. That’s the key bit to sustain it: a paycheck.

                                      1. 2

                                        Perhaps you are thinking of large,

                                        Uh, no, I’m not. I’m speaking from my experience maintaining mostly small single person projects in my free time.

                                        1. 0

                                          Watch the “Uh”. It’s patronizing. Be kind.

                                          At this point I’m not sure what we are discussing anymore so I’ll leave it here. We are likely looking in the same direction but with different angles.

                              2. 0

                                wanting to create an open source project for “Internet points” absolutely perplexes me

                                I think it’s money that has entered the equation, and “internet points” are just an indirect means. An upside is that now there’s an additional incentive to make things. A downside is that now there also is an additional incentive to advertise.

                              1. 1

                                An interesting quote I stumbled upon last week “The ‘s’ in IoT stands for ‘secure’ “ - quite an apt comment I thought. The whole nature of “IoT” is connectivity no matter the costs, users for some reason see the benefit of having their fridge connected to their home WiFi, but the vendors (as a majority) never release a firmware patch or update in the wake of new vulnerabilities, this was apparent earlier this year with the findings of KRACK.

                                Vendors now are too interested in shipping a working product, as opposed to a well tested extendible product, because they want to force you to buy new products when yours gets old, or if they add a facetime feature so you can facetime your groceries from work. No wonder so many people struggle for money these days, people just get sucked in.

                                With regards to the article, TLS (and SSL) provide security between the connection origin and the destination, if your cheap device was rooted at another point, this becomes worthless.

                                1. 2

                                  I have always used an old school IBM mechanical keyboard, the latest trends seem to have keyboard layouts as shown in the article, does this actually improve comfort and feel better after 8hours of constant use? I was looking at trying one out, but none of my friends have one, and I don’t live anywhere near a place that would have one for demo. Thanks.

                                  1. 2

                                    For me, the split keyboard was the largest improvement.

                                    I blew out an arm on an IBM Model M, had to switch to kinesis, and now ergodox. The largest issue was that my wide shoulders meant my hands were turned outwards when on the keyboard, and that put strain on the inside of my wrists.

                                    With my current setup, the distance between my F and J keys is twenty three inches (just checked), allowing my arms and wrists to relax.

                                    1. 2

                                      This depends on your typing style, I think. For me the change to a columnar stagger and the change to using an fn layer for numbers and punctuation made a much bigger difference in comfort than going to a two-piece keyboard; I guess because of the reduced finger travel?

                                  1. 2

                                    I would love to run OpenBSD on my servers, for some of the reasons noted in this article, high code quality and the desire to run a clean system, however these same reasons also make it not such a great choice. When you administer a server, you unfortunately need to install an obscure package, or a library that doesn’t have an openbsd package, and then it just becomes a pain. At least with FreeBSD I never run into these issues, I can build everything from source, or if I need one program that I don’t want to build, I can just install a binary blob. I really admire the OpenBSD project for its principles and what it does for the open source community, but as am operating system I don’t personally get on with it.

                                    Also due to the scale in which FreeBSD is used commercially, as opposed to some of the other projects, you find more guides on line, so when you inevitably come across a ports build error (installing said obscure package) the solution is never far away.

                                    1. 1

                                      I just started writing JS for our internal CRM and other applications, and although it doesn’t really bother me, I do find it strange how npm install (some package) takes so long, like I can build packages from source in FreeBSD quicker than I can install one module in npm. If the code behind this ever makes it to a local application, it would certainly be a big improvement. It probably only works in development though, as when bundling your applications, you may need a file that turbo hasn’t fetched, and depending on your builder picking this up, it could cause a few headaches/problems debugging production runtime errors.

                                      Regardless of the above, the software engineering behind this sounds very impressive and it’s nice to see a startup actually solve a real world problem.

                                      1. 2

                                        If npm speed is bothering your, I highly recommend trying https://yarnpkg.com/ – it can pretty much be used as a drop-in replacement for npm that just makes everything faster (and takes up less of your drive space)

                                        1. 1

                                          Up until I read the post in this thread, I have never heard of yarn, I have only been writing JS for a few months now. I have just given it a quick whirl and it seems fairly decent,I will see how it fairs over the next few months and how it compares etc, thanks :-).

                                          1. 2

                                            I moved from yarn back to the official npm client when they released v5. npm currently also caches packages :)

                                      1. 1

                                        Very cool, and I need to do something very similar for an upcoming project, this helped a lot!

                                        1. 5

                                          I’m setting up my base station for amateur radio! I just got a power supply and antenna for my IC-7100, and I’ll be listening on the air soon.

                                          1. 1

                                            Nice, I always wanted to get into ham radio but never managed to make enough free time.

                                            1. 1

                                              It’s never too late! http://www.eham.net/newham/

                                              1. 1

                                                What discouraged me was the sheer amount of real estate a setup would take on my desk. I don’t have the luxury of having a free room to dedicate to the hobby, so my study would have to house all the extra kit, which I simply don’t think it would!

                                                1. 1

                                                  A handheld radio is not much bigger than a cell phone and it’s a good first radio to purchase. No need to buy a huge base station until you’ve gotten more familiar with the hobby!

                                          1. 0

                                            Isn’t the best practice not to use node for server side code?

                                            1. 1

                                              Works fine, modulo the edge cases of your business logic and its expression in JS.

                                              1. 1

                                                Hum… no. I’m far from being a fan of Node but I do understand the usage of it. This reads almost as a bare troll to me….

                                              1. 2

                                                I have just finished writing two Javascript Spa’s (my first time doing any JS work). These two applications save our business over 80man hours a week in what they can offer (opposed to our stock and expensive ERP solution). I have a third to write which will be replacing our old python/html powered CRM system with a full JS front end and separate backend (much like my recent creations) but I just need to decide whether to stay with the Python/Angular stack, or try another language on the backend and possibly Elm for the front end. The backend is 90% sql, so I really don’t see any immediate advantage moving from python (and sqlalchemy which makes maintenance and feature requests super easy)

                                                1. 1

                                                  You could connect to a public proxy and force all traffic through it, it will be slow as hell and very limiting on what services will work.

                                                  1. 2

                                                    I really wish there was a first class, stable/maintained docker port for FreeBSD. There are a few forks that are in various states. Last time I tried, I could get my containers running using the local docker client, but trying to connect to it remotely with a newer version of the docker client would fail.

                                                    Having a solid docker solution would be a big game changer in the FreeBSD world.

                                                    1. 13

                                                      Having a solid docker solution would be a big game changer in the FreeBSD world.

                                                      Perpetuating a level of mediocrity. How about going the other direction and organise things so you don’t need docker as a “solution” in your environment. That would be a far bigger game changer.

                                                      1. 5

                                                        +1 docker is an easy way to deploy applications for people with less sys admin experience, but docker more of a development tool, but in my eyes, not the beat deployment technique.

                                                        If you really want docker on FreeBSD fire up a bhyve instance of Linux on BSD, and run docker there. Emulating Linux on bsd works really well on bhyve, having docker and freebsd together just opens your solid architecture up to problems, run it in a vm and if it eats memory or crashes, it won’t affect the master host.

                                                        1. 2

                                                          Yeah, I have a feeling nix + jails would be a better solution overall than docker on freebsd and probably already works fine.

                                                      1. 10

                                                        This quote sums up perfectly why I run FreeBSD on all my commercial servers.

                                                        everything just worked neatly out of the box. I was amazed with the fact that after a few hours with FreeBSD, i had the whole stack running.

                                                        Solid, reliable and secure. Yes there are more solid choices, yes there are more secure choices, but for me FreeBSD is a perfect balance of both, coupled with expert documentation (which is not unique to FreeBSD, its more of a BSD thing in general). And it’s real documentation from the *BSD website, not stackoverflow answers or out of date third party tutorials.

                                                        1. 6

                                                          I have never felt/had the need to look at anything other than Nginx. For us it hasn’t failed in 6years (since we migrated from Apache), not once. Envoy does open up some cool possibilities (to solve problems I don’t yet have).

                                                          The additional protocol support looks good and it might be a time to re-engineer some of the current setups that we have, but for me, I’ll wait until the documentation expands a bit (and a few more stackoverflow.com questions appear).

                                                          1. 2

                                                            We’ve been considering replacing Nginx with something else recently, because we keep hitting situations where Nginx has marked all the upstreams as dead and is returning 502s, but doesn’t provide any information about which upstreams it marked as dead and when. Having more introspection into what’s happening would be nice. (I think the paid version does give you that, but unfortunately that’s a little out of our price range just for more info.)

                                                            1. 1

                                                              That’s interesting and also annoying they have solved the problem in a premium version and not allowed it into the free/open version (as technically it is a bug). Envoy does look really nice, maybe I should give it a whirl on an old BSD server and try and contribute something to the documentation, as if it does everything it claims, it’s going to be very popular.

                                                          1. 35

                                                            Startup mistakes are spending too much time thinking about data stores, and not enough time thinking about making money. Personally I believe that so many startups fail because they obsess and re-engineer their tech stack so much. Most startups (if they ever get to making money) change their initial product/offering so much by the time its out there, that the tech stack decisions they made in the early days aren’t as relevant to the problem they actually end up solving. Use a sane default then evaluate if you actually need anything else. So I whole heartedly agree with his statement just use Postgres, and you won’t regret it.

                                                            1. 3

                                                              I agree with you after reading lots of Hacker News and Barnacles. They should spend almost all their time marketing, listening to customers, building/testing features, and so on. That said, it’s still good to consider this stuff ahead of time to give them templates for what to go on that will reduce operational problems early on and/or in maintenance down the road. Like the OP and your Postgres recommendation. Also, like turnkey Postgres appliances for the cheap hosts they’ll probably be using.

                                                              1. 3

                                                                100%. I been in numerous failed startups. I’ve seen plenty more. Datastore wasn’t an issue even once…. I’ve seen plenty of startups build on amazing datastores and fail to have any sales and marketing. I’ve seen plenty fail from not having backups, from hiring poorly, from overreaching.

                                                                Datastores can hurt when you’re scaling up. But you’re scaling up now. Congratulations.

                                                                Agree that defaults make sense. However, equally it’s worth being aware that you’re going to have scale problems whatever you do. Every serious relational database I’ve seen is a beast. Comes with the territory.

                                                                1. 2

                                                                  Yup, going with Postgres at the beginning makes sense, because it gives to freedom to experiment and iterate on your domain in the beginning from a solid foundation. Alas the databases that are more geared towards scaling are currently trickier to work with in the face of changing requirements, so mistakes become magnified to quite a large degree. But you’ll eventually want to move to a different model once scaling becomes an issue.

                                                                  At the moment my thinking is that you use a RDBMS under the hood, but pretending it’s CQRS/ES, which maintains an nice separation of concerns between reading and writing and the persistence layer, then you are in a better position to switch to something more scalable in the future, whilst maintaining the advantages of in-place migrations in the beginning when requirements are still up in the air.

                                                                  1. 1

                                                                    I had never heard of CQRS before, it’s quite interesting. Could you elaborate a bit on ES?

                                                                    1. 1

                                                                      Event sourcing…

                                                                      And I’m with /u/brendan on this: focus on the “why” (design) of separating concerns, not the “how” (transport). It’s a long time between MVP and having load that demands Kafka, RabbitMQ, NSQ, NATS, etc. There are designs that need those early but I squint hard at that because they add a lot of complexity and operational overhead when you’re still figuring out how to solve other problems.

                                                                2. 3

                                                                  Startups don’t exist to make money- they exist to get bought. That’s their profit model: get bought out at a high valuation before your burn outpaces your investment.

                                                                  1. 5

                                                                    Startups don’t exist to make money- they exist to get bought.

                                                                    To be fair, their ability to get bought should depend on their ability to make money, and after these crazy bubble times are over, it will.

                                                                    That’s their profit model: get bought out at a high valuation before your burn outpaces your investment.

                                                                    That’s not a profit model though :) It’s a plan for making a return on the time, effort, and money the founders invested in the startup. It’s a gamble too!

                                                                1. 11

                                                                  I have tested today, its incredibly fast. Both with SPA Js applications, standard sites as well etc. The memory usage is much lower than chrome (as promised) so all round I’m a very happy camper. The default style out of the box is also very clean. A big improvement from previous versions.

                                                                  It will be interesting to see the Servo adoption from smaller browser projects.

                                                                  1. 2

                                                                    Seconding the lower memory usage! I’ve been thrilled since I switched over to the nightly and now rarely reach for chrome.